ShinyProxy is one the most popular open-source Shiny hosting options. You can use it to host multiple applications, apps other than Shiny, and it comes with built-in enterprise features, like authentication and authorization.

Open Analytics, the Belgian company behindShinyProxy, just announced the 3.1.0 release. Head over to the ShinyProxy release notes for all the details. I go over my favourite highlights here.

Pre-initialization and container sharing

From its inception, ShinyProxy provided exactly 1 app instance per user. Later it introduced >1 replicas. Such a setup provides complete isolation for the user sessions, making it very hard to leak sensitive information. Containers started on-demand, making it unnecessary for all apps to run constantly.

Sharing an app among multiple users was not possible in ShinyProxy. This is very similar to how Shinyapps or Shiny Server operates, a single instance can allow many user sessions. Sharing the same instance also reduces wait time, i.e. if a user is already using the app, the next user can join without waiting.

With the recent change, this is now possible with 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.

See the announcement blog post for a screen capture that shows the reduced wait time due to container sharing.

This new feature is easy to turn on, but of course, there are some gotchas. For example, some environment variables cannot be passed to the container as before and the container cannot be customized for a specific user, because we don't know yet who the new user might be. Instead, we need to use HTTP headers to get the user name and user group variables. See the docs for the details.

New backend: AWS ECS

This new backend is a very exciting and potentially transformative addition. It allows scalability without having to manage servers or dive into the complexities of Kubernetes. As explained in the announcement blog post:

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.

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.

There is a starter example here.

Improvements for OpenID providers

Some providers that use the OpenID Connect (OIDC) standard for user authentication, provide important information (so-called claims) as part of the access token.

Decoding the access token was previously possible inside the apps, but it was not available as part of the Spring Expressions (SpEL) used by ShinyProxy. Therefore, authorization was not possible immediately after login, i.e. the app is listed but the user might not be authorized to use that. Read more about the background in this GitHub issue.

With the recent change, we can now use the decoded OpenID access token in SpEL. This will open doors for some OIDC providers where group-based authorization was not possible before.

Smaller improvements

• 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.
• Limit the total number of apps running on a server or cloud infrastructure: set limits at a global and per-app level.
• An option to show notification (a.k.a message of the day) to all users

1-click app updates

The DigitalOcean 1-click app is being updated to pack ShinyProxy 3.1.0. Apart from adding the new version of ShinyProxy and testing the machine image, the new version of the ShinyProxy 1-click app on DigitalOcean ships with a setup script on the 1st SSH login: you will be prompted to set up TLS certificate via Let's Encrypt to serve the ShinyProxy over HTTPS. You'll need a domain name with a DNS A record pointing to the Droplet IP address, and an email address.

ShinyProxy 1-click App

ShinyProxy is a great way to deploy containerized Shiny apps to production and it is only 1 click away.

Hosting Data AppsPeter Solymos

ShinyProxy – Hosting Data Apps

ShinyProxy is the quickest way to deploy containerized apps in an enterprise context with built-in authentication and authorization, securing, and without limits on concurrent usage

Hosting Data AppsPeter Solymos