ShinyProxy: an open source front door for Shiny and data science apps

An enterprise front door rather than another data science app

ShinyProxy is described as an open source enterprise deployment for Shiny and data science apps, and the README heading for the project is an open source enterprise deployment for data science apps. That framing is the whole point of the project. An interactive data science application, a Shiny server in particular, is a long-lived process that holds a connection open and expects a specific way of being reached. Running several of them means several ports, several ways of starting and stopping, and no single place where authentication happens. ShinyProxy is the layer that sits in front of that, and the repository is a Java application, with the topic tags naming containers, docker, docker-swarm, kubernetes, spring-boot and shiny. The audience is a platform or operations team that has to hand a set of internal analytics applications to other people, and the alternative it is meant to replace is a directory of individually started processes with ad-hoc access rules.

Building from source produces one jar and nothing else

The build instructions are two lines of prose and one command. You clone the repository and run:

mvn -U clean install

The result is a single .jar file made available in the target directory. That is the entire build contract, and it is worth pausing on, because it tells you what kind of artefact you are deploying. There is no application server to install and no container image to pull from a registry in the repository, no separate frontend to build, and no configuration file to hand-edit before the thing starts. The project uses Maven, with the pom.xml at the root of the repository, and the source lives under src. There is also a JenkinsfileSCM for the project's own continuous integration, a .pre-commit-config.yaml, an .editorconfig and a LICENSE_HEADER file, which is the standard hygiene set for a Java project that expects contributions. The single-jar output is the reason the deployment story below is short, and it is also the reason the application is easy to lift into whatever environment you already run.

Running the jar, and the credentials that come with it

Running the application is equally direct:

java -jar shinyproxy-3.2.4.jar

You then navigate to http://localhost:8080 to reach it, and the README states the credentials for logging in: the username jack and the password password. That is a local development convenience, and the README is explicit that it is for that purpose, but it is the kind of detail that gets copied into a deployment ticket. The version in the command matches the current release, which means the command is rewritten with every upgrade, since the jar is named after the release. The port is the default 8080. The point of this section is not the credentials but the shape of the operation: there is no separate configuration step documented here, no certificate to point at and no directory to create, so anything that needs those things is configured somewhere the README does not show you, which is the documentation website rather than this file.

Deployment assets in the tree, and the documentation you actually need

The repository carries two files that tell you about the deployment surface. kubernetesPod.yaml is a pod specification, and the topic tags name docker, docker-swarm and kubernetes alongside containers, which together with the single jar output point at a container-first deployment model in which the same artefact is packaged once and scheduled wherever the cluster is. The other file is owasp-suppression.xml, which is a suppression file for a static analysis tool, and its presence says that the project runs OWASP checks as part of its build and records the findings it has decided not to act on. Everything else about configuration is elsewhere. The README is explicit that all documentation is on the website, shinyproxy.io, and that support is handled through the support page on the same site, with announcements about new releases and features published on a community forum. That is a reasonable split for a project whose configuration surface is a per-application description rather than a single file, but it does mean the repository on its own is not enough to deploy anything beyond the default local run.

Who maintains it and under what terms

The copyright line in the README is dated and specific: (c) Copyright Open Analytics NV, 2016-2026, under the Apache License 2.0, and the repository metadata agrees with the Apache-2.0 licence identifier. The project also carries both a LICENSE file and a separate LICENSE_HEADER file, the second being the notice applied to individual source files, which is a common convention for Java projects that want every file to carry its own attribution. Open Analytics is the company behind the project, and the website, the support path and the announcement forum are all first-party or company-run, so this is a commercial organisation publishing an Apache-2.0 product rather than a community project with an ad hoc maintainer. That matters for procurement and for support expectations, and it is the opposite profile from a personal project, where the risk is that one person stops answering issues.

Version 3.2.x, and a maintenance picture you can read off the tags

The release history is short and regular. v3.2.2 was published on 2025-11-12, v3.2.3 on 2026-01-15 and v3.2.4 on 2026-04-30, and the last push to the repository was on 2026-09-08. The pattern is a patch line with releases roughly every two months, which is what you would expect from a product with a support contract behind it rather than a hobby release train, and the numbering makes the upgrade cost legible since the jar name changes with each patch. The README also routes you to the community forum specifically for announcements about new releases and features, which is the channel to watch if you want to know what a given upgrade brings before you pull it. What the repository does not do is describe a release process, a changelog location or a compatibility statement between the proxy and the Shiny versions it fronts, so for those questions the announcements forum is the source the project points you to.

Editorial conclusion

ShinyProxy fits a team that has several Shiny or data science applications to expose and wants a single place for authentication, routing and deployment rather than running each app on its own port. It does not fit a single-app user, who can start Shiny directly with no proxy in front, and it does not fit a team that needs the authentication and routing features documented elsewhere rather than here. Before deploying, read the documentation on the project website, replace the default credentials that the README gives for a local run, and check the container and Kubernetes assets in the repository against the environment you actually have.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openanalytics/shinyproxy on GitHub
3. Project website
4. README
5. Releases