App Recovery

The App Recovery feature has been much improved in ShinyProxy 3.0.0. With App Recovery enabled, ShinyProxy does not stop apps on shutdown of ShinyProxy. As soon as ShinyProxy (re)-starts it looks for existing (running) apps in the container-backend and restores them into the memory of ShinyProxy. In order to make this more clear, assume you have a ShinyProxy server running with some apps configured. At some point user Jack is using one of these apps, but for some reason the ShinyProxy server must be restarted (e.g. because of server maintenance). Without the App Recovery feature, the container of Jack would be stopped and removed. However, when the App Recovery feature is enabled, ShinyProxy does not stop the container which is running the app of Jack. Now when ShinyProxy restarts, it asks the container-backend (e.g. Docker), for a list of all running containers. It then recognizes the container as a ShinyProxy app and “recovers” this app into the currently running ShinyProxy server. In other words, it is again aware of this app after the restart. Except for the temporary downtime when ShinyProxy was restarting, the user can keep using their app.

This feature is designed for achieving two distinct goals:

  • allowing the ShinyProxy server to be restarted without losing the current running apps. One situation in which this can be useful is when the underlying operating system of the ShinyProxy server must be updated.
  • allowing to change the configuration of ShinyProxy. After changing the configuration, you still have to restart ShinyProxy in order for the changes to take effect. Since ShinyProxy 3.0.0, the original spec of a recovered application is no longer required as soon as the app has been started. Therefore, it is possible to modify or remove specs of applications, even if these apps are in-use.

Alternative solutions

ShinyProxy Operator

If you are using Kubernetes, please have a look at the ShinyProxy Operator. The operator provides for a way to have seamless updates of the configuration of ShinyProxy, in addition it provides High Availability out of the box. The Operator is still our preferred way of solving the configuration problem (as it does not cause any downtime at all), the App Recovery feature is meant for improving less complex deployments.

Redis

Since ShinyProxy 3.0.0, Redis can be used to store both active applications and (HTTP) session of users. The main goal is to achieve High Availability, but in fact there is no need to run multiple replicas to use this feature. If you are able to deploy Redis, this is the preferred solution to App Recovery. When using App Recovery, users are logged out when the ShinyProxy servers restart. This is not the case when using Redis. See the docs on how to enable this.

Configuration

App Recovery can be enabled using the following configuration properties:

  • proxy.stop-proxies-on-shutdown: should be set to false
  • proxy.recover-running-proxies: should be set to true
  • proxy.recover-running-proxies-from-different-config: controls whether ShinyProxy recovers apps which were started with a different configuration file (see above). Note: this option still requires the proxy.recover-running-proxies option to be set to true before it has an effect.

Example:

proxy:
    stop-proxies-on-shutdown: false
    recover-running-proxies: true
    recover-running-proxies-from-different-config: true