shiny-server hosts R Shiny applications over the web
Host Shiny applications over the web.
At a glance
- What is it?
- Shiny Server is the server program that makes Shiny applications available over the web, hosting multiple applications each with its own URL and optionally letting any user on the system deploy their own. It is a Node and C++ application distributed with prebuilt installers for some Linux distributions and licensed under AGPLv3.
- Who is it for?
- Teams that need to publish R Shiny applications to colleagues or the public should adopt shiny-server, because it gives each application its own URL, ships prebuilt installers for the common Linux distributions and can be configured to let users deploy their own apps.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 48 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A server for one specific framework
Shiny Server is a server program that makes Shiny applications available over the web. The scope is exact and worth stating up front, because the name is general enough to mislead.
It is not a general purpose application server, and it does not host anything except Shiny applications, which are R applications built with the Shiny framework. The homepage for the product is rstudio.com/shiny/server, and the repository is under the rstudio organisation.
The feature list in the README sets out what it does. It can host multiple Shiny applications, each with its own URL. It can be configured to allow any user on the system to create and deploy their own Shiny applications. It supports non-websocket-capable browsers, with IE9 named as the example, which matters for organisations with old clients on an internal network. It is free and open source under the AGPLv3 licence, and there are pre-built installers for select Linux distributions.
The second feature is the one that changes the shape of an adoption. Shiny Server can act as a shared platform rather than a deployment target for one team, letting people on the system publish their own applications. That is a shift from a deployment pipeline to a hosting service, and it brings the questions that come with hosting: who can publish, where do the apps live, what happens to a broken one.
The repository is not archived and the last push was on 2026-09-09, and it publishes no GitHub releases, so the packaged installers rather than the repository tags are what a user actually installs.
Installers for two distribution families, source build for the rest
The installation section is explicit about what is supported and what the fallback is.
At this time, Shiny Server can be run on Linux servers with explicit support for Ubuntu 14.04 or greater, 64 bit, and CentOS/RHEL 6, 64 bit, or greater. If you are using one of these distributions, the README points at the pre-packaged installers from RStudio, and says these installers will provide a majority of the prerequisite software and will provision all the necessary directories for you.
If you are not using one of the explicitly supported distributions, you can still use Shiny Server by building it from source, with the instructions linked from the repository wiki.
That is the whole installation story, and it is worth reading closely for two reasons. The supported set is narrow and old, Ubuntu 14.04 and CentOS 6 are long past end of life, so the practical question is whether your distribution is close enough to one of them for the installer to work, and the answer for anything current is usually to build from source. And the build is not trivial, because the project is not a pure Node package, which the next section explains.
The README also points at two other installation routes implicitly. The configuration section mentions an alternate configuration file at /etc/shiny-server/shiny-server.conf, which is a path the installer creates, and the repository listing shows a docker directory and a vagrant directory, so container and virtual machine workflows exist in the tree even though the README does not document them as supported routes.
The default configuration is one directory and one port
Out of the box, Shiny Server has almost nothing to configure, and that is what makes it easy to evaluate.
Shiny Server will use the default configuration unless an alternate configuration is provided at /etc/shiny-server/shiny-server.conf. Using the default configuration, Shiny Server will look for Shiny apps in /srv/shiny-server/ and host them on port 3838.
Two decisions are baked into that, and both are reasonable defaults with one caveat each. The apps directory is under /srv, which is the conventional place for server data on a Linux system, and it means the server is looking at a fixed path rather than scanning for applications. The port is 3838, and the README notes the first thing to do if the browser cannot connect: configure your server's firewall to allow inbound TCP connections on port 3838.
The README is clear that the defaults are a starting point rather than the whole story. To customize any of the above, or to explore the other ways Shiny Server can host Shiny apps, it points at the Shiny Server Configuration Reference, and the Administrator's Guide is the more complete document for setup and management.
So the shape of the configuration is a small language of its own, and the two files in the repository's config directory are where you look at what it can express. The default configuration is a file in the repository, not a hidden set of compiled-in values, which means you can read the behaviour you are actually getting before you change it.
Deploying an app is a file copy, and the URL follows the name
The deployment step in the README is deliberately boring, and that is the point.
If you plan to host your apps in /srv/shiny-server/, you can copy an app you have already developed to that location:
sudo cp -R ~/MY-APP /srv/shiny-server/Or you can copy some or all of the examples provided with the Shiny package. The README is careful here, since the location of the R library varies from system to system, and it gives the command that prints the directory:
R -e ".libPaths()" --quietand then the copy itself, using the Ubuntu path as the example, cp -R /usr/local/lib/R/site-library/shiny/examples/* /srv/shiny-server/.
Once the files are in place, you start a web browser and point it to the application:
http://<hostname>:3838/APP_NAME/The URL structure is the part to notice. The application name in the path is the directory name, so the same directory that the app is developed in becomes its address. There is no manifest, no routing configuration and no deployment descriptor. You copy a directory and it is live.
That simplicity is also the limitation, and it is why the Configuration Reference is linked so prominently. The README's closing line says to customize any of the above, or to explore the other ways Shiny Server can host Shiny apps, see the Configuration Reference for details on the various ways Shiny Server can be configured. Everything past the default is configuration, and the documentation is where the real feature set lives.
A Node server with a native component and an R side
The repository layout explains why building Shiny Server from source is more involved than installing an npm package.
The package.json names the package shiny-server at version 1.5.24, with the entry point at ./lib/main.js, and the start script is node ./lib/main.js. So the server is a Node application, and the dependency list is the standard stack for a Node web server with websockets: express for routing, faye-websocket and sockjs for the socket layer, http-proxy-3 for proxying, handlebars for the templates, client-sessions for session handling, log4js and morgan for logging, and mime-types and compression for the HTTP plumbing. A few dependencies are pinned to GitHub commits rather than registry versions, including optimist, shiny-server-client and sockjs-client, which is a sign of a project that tracks upstream fixes by commit.
But there is more than Node here. The repository has a binding.gyp and a CMakeLists.txt, which is the node-gyp and native build combination, plus src and lib directories, an external directory for third-party sources, an upstream.txt file, and R and python directories, which hold the pieces that talk to the R and Python runtimes hosting the applications. The tests are run with mocha, there are separate unit, integration and R integration test targets, and the build is tsc for the TypeScript.
The infrastructure around it is a full product. There is a Jenkinsfile and a Jenkinsfile.internal for the build pipeline, a docker directory, a vagrant directory for local development environments, a packaging directory, a dev directory with the development configuration, a scripts directory, tools, templates, a lib directory for the shipped assets, and an R and python runtime layer.
The man pages and documentation tooling round it out, with a manual.test directory, a memory-bank directory and a .mocharc.json for the test runner.
AGPLv3, and the commercial product next to it
The licensing deserves a paragraph of its own, because it decides who can use this.
The README lists the project as free and open source under the AGPLv3 licence, linking the GNU AGPL version 3 text. The repository has a COPYING file and a NOTICE.md, and the package metadata is recorded as a licence GitHub cannot classify, so the COPYING file is the text to read.
The AGPL has a specific consequence that matters for a server: the copyleft reaches users who interact with the software over a network, not only people who receive the source. For an organisation hosting Shiny applications for internal use, the question is whether those users are being offered the corresponding source of the modified server. That is a question for a lawyer, not for a README, and the practical point for an adopter is that the terms are not the permissive MIT that many Node projects carry.
The README also names the alternative. Questions go to the Shiny Community discussion board, and if you are interested in Professional Support you should look at the commercial Shiny Server Pro product.
So the two options are the AGPLv3 server for organisations that are comfortable with it, and a commercial product with support behind it. The open source project is not going away, but the choice of how to run it is a licensing decision as much as an operational one.
The support routes are also specified. Questions to the community board, documentation in the Administrator's Guide and the Configuration Reference, and the source code and wiki for building from source.
Editorial conclusion
Teams that need to publish R Shiny applications to colleagues or the public should adopt shiny-server, because it gives each application its own URL, ships prebuilt installers for the common Linux distributions and can be configured to let users deploy their own apps. It is the wrong tool if your applications are not Shiny apps, and it is the wrong choice if the AGPLv3 licence does not fit your distribution model, since the commercial Shiny Server Pro product is the alternative the README points to. Before deploying, read the Shiny Server Configuration Reference for the hosting options beyond the defaults, and check that port 3838 is reachable from your users.
Frequently asked questions
Which Linux distributions does shiny-server support?
The README states explicit support for Ubuntu 14.04 or greater in 64 bit and CentOS/RHEL 6 in 64 bit or greater, with pre-packaged installers from RStudio for those. On any other distribution you can build Shiny Server from source using the instructions in the repository wiki.
Where does shiny-server look for Shiny applications by default?
With the default configuration, Shiny Server looks for Shiny apps in /srv/shiny-server/ and hosts them on port 3838. An alternate configuration can be provided at /etc/shiny-server/shiny-server.conf, and the Shiny Server Configuration Reference covers the other hosting options.
How do I publish a Shiny app with shiny-server?
Copy the application directory into /srv/shiny-server/, for example with sudo cp -R ~/MY-APP /srv/shiny-server/, then open http://<hostname>:3838/APP_NAME/ in a browser. The README also notes that you need to allow inbound TCP on port 3838 in the firewall if the browser cannot connect.
Can users of a shiny-server host deploy their own Shiny applications?
Yes, the server can be configured to allow any user on the system to create and deploy their own Shiny applications, alongside hosting multiple applications each with its own URL.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/rstudio-shiny-server)Was this useful?