ShinyProxy 3.1.0

Last year we released a major update of ShinyProxy, bringing High Availability, Scaling, App parameters, improved integration with Kubernetes and much more. Today’s release goes even further, brining Pre-Initialization, Container sharing and even a new container backend. Along with these major features, the release is packed with numerous small improvements. ShinyProxy is a novel, open source platform to deploy Shiny apps for the enterprise or larger organizations. Nevertheless, ShinyProxy is also an excellent choice for deploying a handful of apps in smaller organizations. While ShinyProxy is generally used to host Shiny applications, it has always been designed with the idea to host any application that can be packaged into a Docker container. For example, ShinyProxy is used more and more to host complete development environments. This blog post covers some major improvements of this release. All changes in this version can be found in the release notes.

Pre-initialization and Container Sharing

For as long as ShinyProxy exists, ShinyProxy starts a new container every time a user starts an application. This container is dedicated to this user and is never used by other users. This has worked great for many years and gives the possibility of using ShinyProxy for hosting IDE’s and development tools, since each container can be customized for this specific user and session. Furthermore, as every container is started on-demand, it allows to host a big set of applications, without the need for all these applications to run all the time. While this approach has many advantages, it also has the consequence that a user has to wait for both the container and application to start up and that it requires more (CPU and memory) resources when more users are using ShinyProxy. ShinyProxy 3.1.0 introduces the concept of container pre-initialization and container sharing. For every app, you can specify a number of seats ShinyProxy has to pre-initialize (e.g. X seats). When ShinyProxy starts up, it will start X containers. As soon as a user wants to use an application, ShinyProxy assigns a container (seat) to the user. Therefore, the user has almost no waiting time for the container to start up. As soon as a seat gets claimed, ShinyProxy will scale up the number of containers, such that there are again X seats ready to be used by new users. Similarly, when a user stops using an app, the seat is released and ShinyProxy will scale-down the pool of available seats (and thus the number of containers). In addition, you can specify how many seats can be run on a single container, therefore allowing to share a single container among multiple users.

Enabling pre-initialization for an app is very easy, just add the property minimum-seats-available: X to your app specification. With this option, ShinyProxy will ensure there are always X pre-initialized containers. New users will be immediately assigned to a pre-initialized container. Adding the property seats-per-container: Y, allows a single container to be used by Y people at the same time. ShinyProxy takes both numbers into account, in order to determine the number of underlying containers. It is possible to use these new features with every container backend.

In many cases, an app hosted on ShinyProxy needs to know the username (and groups) of the current user. Therefore, ShinyProxy adds the username (and groups) as environment variables to the container. However, this would not work when the container is created up-front or used by multiple users (environment variables cannot be updated after the container has started). Instead, ShinyProxy can now send the username and groups as HTTP headers to the app. It is even possible to send custom headers!

The monitoring stack contains a new set of dashboards, providing the same level of monitoring for pre-initialized and shared containers as for regular apps.

We believe this feature is a big improvement for ShinyProxy. Together with the various performance improvements made in this release, this makes it easier to use ShinyProxy for public apps, which are used by a large amount of users. Check out the full documentation to start using it.

AWS ECS Backend

Up to now ShinyProxy supported three container backends: Docker, Docker Swarm and Kubernetes. The Docker backend is very easy to set up, but does not provide the same scalability and flexibility as the Kubernetes backend. ShinyProxy 3.1.0 now supports AWS ECS as a new backend, allowing to deploy ShinyProxy without managing servers or complex setups, but with greater scalability. The backend uses AWS Fargate and supports most of the ECS features: integration with CloudWatch, Task role support (e.g. to access S3) and EFS volumes. We provide a ready to use and fully documented Terraform deployment example. A downside of AWS ECS is that in most cases it takes more time to start the container compared to the other backends. But of course it can be used together with the pre-initialized container feature, reducing the startup time to less than a second. The architecture of ShinyProxy, allows to easily add new container backends.

Custom container names

This release streamlines the names of the containers created by ShinyProxy. Every backend now uses the id of the app as part of the name, making it easier to find which container corresponds to which app. For example, when using Docker, the name of the container is sp-container-#{proxy.id}-0, where #{proxy.id} is replaced by the id of the app. It’s even possible to change the name by providing a SpEL expression.

Up to date Docker library

As with every release, all dependencies (including Spring Boot) have been updated. Furthermore, ShinyProxy now uses a better maintained Docker client library. This new library no longer relies on old dependencies and fixes the compatibility of ShinyProxy with recent Docker releases.

Limitation on the number of users

When making applications available to a broad audience, you sometimes want to limit the total number of apps running on your server or cloud infrastructure. It’s now possible to specify such a limit, both on a global and per-app level. The container sharing feature is aware of this limit and uses it to determine the maximum number of containers it can create.

Documentation and Demos

In addition to all the improvements to the ShinyProxy code, a lot of time was invested to improve the ShinyProxy documentation. First of all, we now have an overview of how to write ShinyProxy configuration (e.g. how to use lists or environment variables in the config). The configuration of apps has been divided into smaller sections, making it more clear which properties belong together. All sections in the documentation are now numbered, and together with improvements to the ToC, this makes it easier to browse through the always growing number of configuration properties. The OpenID documentation has been rewritten, to better explain the process of configuring it, while we also extended the provider specific examples. Finally, we regularly add new demos, showing how to deploy many kinds of apps in ShinyProxy.

Full release notes can be found on the downloads page and updated documentation can be found on https://shinyproxy.io. As always community support on this new release is available at

https://support.openanalytics.eu

Don’t hesitate to send in questions or suggestions and have fun with ShinyProxy!