ShinyProxy is the open source deployment server for containerised data science web apps, giving a team one authenticated URL that launches a private app session per user.
ShinyProxy is an open source deployment server for data science web applications. Instead of leaving an analytics app running on a shared port for anyone to reach, it puts a sign in page in front of your applications and starts a dedicated container for each user who opens one, then reverse proxies that container back through a single URL. When the user stops the app, or the session goes idle, the container is destroyed and its memory is returned to the machine.
Applications are declared in one configuration file: an identifier, a display name, the container image to run and the port it listens on. Because the unit of deployment is a container image, the same server publishes R Shiny apps, Python Dash and Streamlit apps, Jupyter notebooks and anything else that serves HTTP, side by side and each with its own dependencies. Per app access groups decide who sees what, an administration view shows which sessions are running, and per container memory and CPU limits stop one user's analysis from taking the machine down. It suits analytics, research and data teams that need to publish interactive work to colleagues or clients with real authentication and real isolation, rather than a link to an unprotected port.
cloudimg ships ShinyProxy as a working appliance rather than an empty server: a cloudimg written sample analytics app is baked into the image as a container, so signing in for the first time launches a real containerised session and renders a real dashboard instead of an empty app list. That sample image is built from scratch at image build time from cloudimg's own source, so no third party application image is redistributed with the product. The image carries no usable credential of any kind: the server configuration file does not exist until first boot writes it, with a unique administrator password generated on the instance itself into a root only file, so the demo accounts published in the upstream reference configuration exist nowhere and are proven to be rejected. Nothing is bound to the public port until that first boot completes. The Java runtime is given explicit heap and metaspace ceilings so the server, the container engine and a launched app all fit the recommended machine size comfortably, and the reverse proxy in front is already configured for the websocket connection interactive apps depend on. Every deployment is paired with a step by step deploy guide and backed by 24/7 cloudimg support.
Real screenshots taken while testing this image against its deployment guide.