Deployment

Introduction

This page provides an overview of the different ways to deploy ShinyProxy. It is advised to first read the Getting Started guide in order to understand the basics of ShinyProxy first.

ShinyProxy supports many deployment options:

JAR
Debian based systems
Red Hat based systems
Docker
Docker Swarm
Kubernetes
AWS ECS

Supported Docker versions

In order to use the Docker or Docker Swarm backends, Docker must be installed on the server running ShinyProxy. It’s recommended to use the Docker binaries provided by the Docker website and not by your Linux distribution. When using Ubuntu, make sure to not use the Docker snap as this can cause problems as well. Finally, at the time of writing ShinyProxy is incompatible with Podman, however, it’s possible to use the Docker binaries on Red Hat based systems.

JAR file

See the Getting Started page for detailed instructions

The most simple way to run ShinyProxy is to use the JAR file. For simple testing or demonstration purposes it is sufficient to use

java -jar shinyproxy-3.1.1.jar

which will run ShinyProxy on port 8080.

It is possible to use nohup to let ShinyProxy running when you log out of a system, but it is advisable to use alternatives e.g. the .deb or .rpm packages or the containerized ShinyProxy to have it defined as a proper service.

.deb package

Use the following steps to set up and configure ShinyProxy on Debian and Ubuntu systems:

install Docker on Debian or install Docker on Ubuntu

install or upgrade the .deb package of ShinyProxy:

wget https://www.shinyproxy.io/downloads/shinyproxy_3.1.1_amd64.deb
sudo apt install ./shinyproxy_3.1.1_amd64.deb

To see whether the service is up and running, use:

sudo systemctl status shinyproxy

To check the log, use:

sudo journalctl -u shinyproxy

allow the shinyproxy user to access the Docker daemon:

sudo usermod -a -G docker shinyproxy
sudo systemctl restart shinyproxy

permanently enable the service so ShinyProxy is automatically started after a reboot:
```
sudo systemctl enable shinyproxy
```

adapt the default configuration to your needs:

sudo nano /etc/shinyproxy/application.yml
sudo systemctl restart shinyproxy

After following these steps, you an access ShinyProxy on port 8080 of your server. The default configuration allows to login using the following credentials:

username: jack and password: password
username: jeff and password: password

In order to secure ShinyProxy (or put it behind a loadbalancer or reverse proxy) check the Security page.

.rpm package

Use the following steps to set up and configure ShinyProxy on Red Hat based systems (e.g. Red Hat Enterprise Linux, Alma Linux, Rocky Linux, CentOS Stream etc):

Note: we currently do not officially support using Podman instead of Docker. Please vote on this issue in case you are interested in it. However, ShinyProxy works with Docker installed on a Red Hat based system.

install Docker on CentOS

install or upgrade the .deb package of ShinyProxy:

curl -O https://www.shinyproxy.io/downloads/shinyproxy_3.1.1_x86_64.rpm
sudo dnf install ./shinyproxy_3.1.1_x86_64.rpm

To see whether the service is up and running, use:

sudo systemctl status shinyproxy

To check the log, use:

sudo journalctl -u shinyproxy

allow the shinyproxy user to access the Docker daemon:

sudo usermod -a -G docker shinyproxy
sudo systemctl restart shinyproxy

permanently enable the service so ShinyProxy is automatically started after a reboot:
```
sudo systemctl enable shinyproxy
sudo systemctl enable docker
```

adapt the default configuration to your needs:

sudo nano /etc/shinyproxy/application.yml
sudo systemctl restart shinyproxy

After following these steps, you an access ShinyProxy on port 8080 of your server. The default configuration allows to login using the following credentials:

username: jack and password: password
username: jeff and password: password

In order to secure ShinyProxy (or put it behind a loadbalancer or reverse proxy) check the Security page.

Containerized ShinyProxy

Why?

ShinyProxy uses containers to achieve scalability and security when launching multiple Shiny apps for multiple users. Each user runs a Shiny app in an isolated container, and there is no risk of apps interfering with each other, or users getting hold of other users’ data.

From an infrastructure point of view, there are also great advantages to be gained. Containers are much easier to manage and scale than a series of system processes or services.

So if ShinyProxy uses containers to run Shiny apps, why not run ShinyProxy itself in a container? This would offer several additional advantages:

No need to install a Java runtime on the host. The docker image will take care of that.
Many container managers can be set up to automatically restart crashed containers. If the ShinyProxy container crashes, it can recover without requiring manual intervention.
It becomes much easier to deploy multiple ShinyProxy containers, and many clustered container managers (such as Kubernetes) allow you to deploy load balancers in front of those containers.
If you have multiple ShinyProxy containers and want to put a new configuration online, you can perform a ‘rolling update’ without causing any downtime for your users.

Configuration

See the complete example for running ShinyProxy in Docker.

To run ShinyProxy in a container, several steps must be taken:

A docker image must be built, containing ShinyProxy, an application.yml configuration file, and a Java runtime. We advise you to build upon our official Docker image. This image is optimized to have a small footprint and to be secure (by running ShinyProxy as a non-root user). An example on using this image can be found here.
Since ShinyProxy is now listening on a container address and port, an additional mapping must be made to ensure that ShinyProxy is also accessible on an external interface. This is done differently for different container managers:
- For docker, the port must be published, which means the host will allocate a port that forwards traffic to the container port.
- For docker swarm, you can define a service that publishes a port on the ingress overlay network to make it accessible from any node.
- For Kubernetes, the port can also be published via a service that automatically allocates the port on all nodes and takes care of routing the traffic to the appropriate pod.
If ShinyProxy is running inside the same container manager as the Shiny containers it launches, it also becomes easier to communicate with those containers:
- It is no longer necessary for each Shiny container to publish a port on the host using port-range-start: simply exposing the Shiny port (3838) on the container is enough.
- Instead of constructing a URL from the docker hostname, ShinyProxy can now use the container ID to access it. For this to work, a setting must be enabled in the application.yml file: shiny.proxy.docker.internal-networking: true or shiny.proxy.kubernetes.internal-networking: true. In addition it is necessary to use a separate Docker network, as explained in our example.

Docker Swarm

See the complete example for running ShinyProxy on a Docker Swarm cluster.

ShinyProxy Operator on Kubernetes

The ShinyProxy Operator should be used for deploying ShinyProxy on Kubernetes, providing scalability, zero-downtime updates, high availability, multi-tenancy and more!

AWS ECS

ShinyProxy supports running apps on AWS ECS using the ECS backend. At the same time, ShinyProxy itself can also run on ECS. This is a scalable way to run ShinyProxy, without having to maintain servers or Kubernetes clusters.

See the full Terraform deployment example.