Features

Why?

Deploying and managing ShinyProxy can get complex when many apps are used, especially when the configuration of ShinyProxy is often updated.

When restarting a running ShinyProxy instance (in order to update its configuration), users will face a disconnect from their running apps. The only solution to guarantee that users don’t lose their connection to running apps, is to keep the current instance alive when updating ShinyProxy’s configuration. However, manually keeping track of these instances would be too cumbersome and should therefore be automated.

The ShinyProxy Operator is able to manage multiple ShinyProxy instances and their configuration.

Example

Assume we’ve some ShinyProxy configuration config1 which contains one app called app1. When the operator starts working, it checks whether a ShinyProxy instance exists with that configuration. If not, it starts a ShinyProxy instance and all other required configuration. Users can now start using app1 on this instance.

Some time later, the need for a second app arises. Therefore, the administrator adapts the configuration of ShinyProxy to include a second app app2.

However, some users are still using app1 on the old instance. These apps may have some state, which shouldn’t be lost. Therefore, the operator starts a second ShinyProxy instance using configuration config2. The operator doesn’t modify the original ShinyProxy server, therefore the existing apps continue to work (even if they’re using WebSocket connections).

All new HTTP (and WebSocket) connections are forwarded to the new server, i.e. any new connection is handled by the new server. Therefore, if users go to the main ShinyProxy page, they will see that a new app is available. Every user (also those still using the old app) can start the new app. The operator stops and removes the old server as soon as it has finished handling any existing ( WebSocket) connections.

Flavours

The operator was originally developed for Kubernetes. Since version 2.2.0 support for pure Docker hosts is added, fully automating a production-grade ShinyProxy server, without the complexity of Kubernetes.

The operator is implemented as a single Docker image, supporting both Docker and Kubernetes. Most of the logic is shared between the two implementations. Nevertheless, the two implementations have slightly different feature set:

Supported versions

This table lists which versions of ShinyProxy and the operator can be combined.