App Recovery

ShinyProxy 2.6.0 introduced the App Recovery feature. When enabled, ShinyProxy does not stop apps on shutdown of ShinyProxy. When 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. It is important to know that changing the specification of running apps may cause incorrectly behaving applications. In principle, only the following properties of the app specification are evaluated when recovering apps:

    • port
    • target-path
    • websocket-reconnection-mode
    • max-instances
    • shiny-force-full-reload
    • hide-navbar-on-main-page-link

    ShinyProxy uses the updated value of any of these configuration options after a restart. If these options are incompatible, your existing apps may not work anymore. Since this can be a potential issue, you must explicitly tell ShinyProxy to recover apps which were started using a different configuration file (see below).

    Note: please have a look at the ShinyProxy Operator if you are looking for a way to have seamless updates of the configuration of ShinyProxy. The Operator is still our preferred way of solving the configuration problems (as it does not cause any downtime at all), the App Recovery feature is just meant for improving less complex deployments.


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.


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