Developing a Shiny app is relatively straightforward, but deploying it to a production environment is a whole another set of challenges.

If you’re unfamiliar, R Shiny is a powerful web application framework for building interactive data visualizations, dashboards, and other data-driven applications. At Appsilon, we’re a big fan of it, and have used it to develop applications for Fortune 500, even Fortune 10 companies!

We know every challenge that comes with the deployment. In this article, we will explore the most common options for deploying a Shiny app and their pros and cons. By the end, you will understand the different deployment options and how to choose the best one for your needs.

We’ll compare all 5 options through 5 comparison points:

1. Authentication requirements
2. Security requirements
3. Scaling requirements
4. Operation management overhead tolerance
5. Investment

Let’s dig in!

Looking to get your software FDA/EMA approved? Make sure you’re following these 7 Good Software Engineering Practices (GSEP).

Table of contents:

• Option #1: Vanilla Shiny
• Option #2: Shinyapps.io
• Option #3: Shiny Server Open Source
• Option #4: Shiny Proxy
• Option #5: Posit Connect
• Summing up R Shiny Deployment

Option #1: Vanilla Shiny

Shiny has a functioning web server and can be run simply with a container or directly on a virtual machine.

Utilizing Docker (or other container technologies) is the most common path to containerize the application, and host it in any platform that allows the hosting of containers. You can even depend on the scaling ability of the platform to scale the number of instances running to serve clients.

This is the least friendly solution, as everything needed to run the application has to be covered – from the code being deployed, to resolving authentication, controlling access, and coordinating scaling.

Back to our 5 comparison points:

• Authentication requirements: This option has no authentication out of the box. It either has to be covered from the code itself, or through an external service. For example, hosting an application on Azure App Services allows it to leverage the authentication that exists for the service, but it has to be managed and configured from the App Service’s perspective.
• Security requirements: The security depends on the platform that is picked to host the application, and how robust it has been created.
• Scaling requirements: Scaling an application can be tricky, especially if the application is stateful or includes individual sessions that need to be managed. Some extra consideration has to be given to avoid the fringe effects of having multiple instances.
• Operation management overhead tolerance: This is the most complex solution for deploying an R Shiny application. It requires engaging people who understand the underlying infrastructure, maintenance, and it also has a long set-up period with quite a bit of overhead. It’s not a task you would expect a Data Scientist to accomplish.
• Investment: This is a custom solution, so there are no up-front costs. There’s a complexity associated with this option that would take longer to implement, depending on the requirements of the application. The investment necessary here is time and effort, and the cost of the underlying infrastructure used.

Hosting options

You have 3 hosting options for pure Shiny deployments:

1. Direct virtual machine deployment
2. Unmanaged containerized deployment
3. Managed containerized deployment

Direct virtual machine deployment

With this hosting option, you’re essentially utilizing a single virtual machine (or a group of virtual machines with horizontal scaling abilities) to host your applications.

It involves setting up all the necessary routing to the machine, configuring an image to host the applications, and maintaining the environment.

For this scenario, the overhead of managing and configuring the environment is quite big, scaling can be a challenge, and it’s the least preferred option, but still an option for simple use cases, or early adoption scenarios.

Unmanaged containerized deployment

With this option, you’re utilizing one of the most recommended strategies for application deployment. Containerizing a Shiny application is relatively simple, and you can then host it on a container hosting platform; be it a self-managed docker swarm cluster, a single virtual machine with docker, or even a Kubernetes cluster.

While this option eases up on a few concerns as the previous option, it’s still a heavily unmanaged solution, and despite scaling being simpler, there are still a couple of challenges.

It’s a preferred option for simple use cases, granted there is a team that can support the infrastructure.

Managed containerized deployment

Other options fall into a more managed scenario, e.g. utilizing AWS ECS with Fargate, utilizing Azure App Services, or other types of solutions that would give you a managed platform to host containers, with as little overhead as possible. Keep in mind that you’ll need to have some basic knowledge on how to configure these things in the cloud.

This option builds on the previous one and comes down to having less overhead in terms of managing the deployments and maintaining the platform.

It’s still good for simple use cases. Advanced scenarios could run into some overhead of customizing the solution.

Summing up

Pursuing this solution is a viable option. We have successfully developed custom applications for custom deployments multiple times in cases with limited workloads and a limited number of users.

This is a long-term solution, and we can justify this investment in the long term, especially if there is a team that can maintain and develop the environment for the applications, and adjust the applications to fit into the environment.

Go with this route if the use cases for your application are simple with non-demanding scaling, a few users, and a reduced number of applications.

Option #2: Shinyapps.io

Shinyapps.io is a platform that hosts shiny applications. It has several platform tiers, including a free one.
It’s a cost-effective solution offered by Posit, but has a couple of security concerns, and limited scaling potential. It’s optimal for testing simple, not sensitive, and small-scale use cases.

This solution might be a good fit if you can answer the following 4 questions positively, from Posit themselves:

1. Are you okay with your application being outside your firewall?
2. Are you okay with the data the application is pulling from being accessible to our cloud?
   (You have to open up a hole in your firewall if the data is behind the firewall today)
3. Are you okay with your end client creating a user account on shinyapps.io (if using authentication?)
4. Are you okay with a shared computation platform for your analyses? (for example, we don’t have any SLAs today on performance)

The limitations are quite serious, but Shinyapps.io still has its place. Let’s compare it through are set of 5 points next:

• Authentication requirements: Shinyapps.io allows authentication out of the box, but it can’t connect to external systems.
• Security requirements: It is a shared platform. There are security guarantees from the platform itself, but for some scenarios with sensitive data, it might not fit into the compliance requirements for application development. The data has to flow outside of your infrastructure to reach the platform, the code is deployed outside of it as well, and the access from the internet is less restricted.
• Scaling requirements: Scaling is based on the number of hours utilized in the platform, and it always has a limit, including being on the professional tier (10.000 hours of active runtime). The limit can be surpassed in the paying tiers but with an additional overcharge.
• Operation management overhead tolerance: Simple to deploy, simple to use. No major operational management is necessary.
• Investment: This is a hosting platform for Shiny applications. There is a cost based on the tier selected, and it is relatively simple to deploy and configure applications on the platform.

Authentication starts only at the Standard Tier.

With ShinyApps.io, we can’t compare different hosting options like we did for Vanilla Shiny, for obvious reasons.

Summing up

Shinyapps.io is a good solution for your application deployments when you need an out of the box solution, but may not be the best choice if your app will be used heavily, will be critical to users and has high compliance requirements.

Appsilon can help set up and consult on the best scenario for this implementation, and help you decide if this is the right solution for you. Feel free to reach out.

Option #3: Shiny Server Open Source

Shiny Server Open Source is maintained by Posit, and it’s a solution that can be hosted in a dedicated VM or can be containerized but has to be self-hosted. It can run multiple apps, but only a single process per application.

Here are our thoughts on the 5 comparison points:

• Authentication requirements: This solution isn’t shipped with authentication options. The authentication has to either be managed with external resources or be developed from the code itself.
• Security requirements: This is a self-hosted solution, meaning that the security requirements are transferred to how Shiny Server Open Source is hosted and used.
• Scaling requirements: There is no scaling provided out of the box. It’s only possible to host one instance per application, and the number of users on the application can be limited. The solution can limit the amount of sessions per application, but it can’t automatically scale. The more users in an application, the slower the response time will be.
• Operation management overhead tolerance: The overhead necessary to maintain this solution is dependent on how it’s hosted. It is an easier framework to work with than hosting a Shiny application directly in a container, but there’s still some overhead in maintaining the application.
• Investment: This solution is open-source and the investment in terms of time to set this up can be relatively small, depending on the chosen platform. So the costs associated with this solution are solely in terms of time, effort, and hosting price.

Hosting options

Hosting Shiny Server Open Source is similar to Vanilla Shiny. The major difference is that you get less overhead from configuring and managing an environment since you’re utilizing a framework that allows hosting multiple Shiny apps.

These are your options:

1. Direct virtual machine deployment
2. Containerized deployment

Direct virtual machine deployment

Opposed to Vanilla Shiny hosting, this is a preferable way to host applications. You can utilize resources more efficiently if you deploy multiple applications, and Shiny Server helps with the routing and application configuration.

There’s still some overhead with managing virtual machines, but it’s easier for simple use cases.

Dynamically scaling could be a challenge here, but scaling up a single instance is relatively easy.

Containerized deployments

This deployment option doesn’t support the use of containers, but the solution itself could be containerized.

It’s not a recommended pattern, as this deployment technology is more meant to be run directly on virtual machines, with fewer resources and environment constraints.

Wrapping up

Shiny Server Open Source is a viable solution that mostly fits simple application scenarios. If apps are complex and need extensive resources, it would affect the performance for the rest of the users as there is only one instance per application.

It fits best for non-complex applications, with non-intensive workloads, and a low number of users, without having complicated authentication schemes.

For this scenario, Shiny Server Open Source is one of the best solutions, and Appsilon has worked extensively with applications that fall into these requirements.

Option #4: Shiny Proxy

Shiny Proxy is an open-source solution maintained and developed by OpenAnalytics.

It’s a simple service that allows scalability for applications, leverages container technology and provides authentication out of the box. It can be resource-heavy, though. It can host other applications that are not R-centric.

Here’s our breakdown of the 5 key points:

• Authentication requirements: Shiny Proxy provides authentication out of the box.
• Security requirements: This is a self-hosted solution, meaning that the security requirements are transferred to how Shiny Proxy is hosted and utilized.
• Scaling requirements: Scaling is provided out of the box, every user that accesses an application, is assigned a container for running that application.
• Operation management overhead tolerance: The overhead necessary to maintain this solution is dependent on how it’s hosted. It is an easier framework to work with than hosting a Shiny application directly in a container and provides easier scaling. However, there’s some overhead in managing the solution, and it can quickly deplete the allocated resources if a lot of users are interacting with the platform simultaneously.
• Investment: This application is open-source and the investment in terms of time to set this up is relatively small, depending on the chosen platform. The costs associated are solely in terms of time, effort, and hosting price. Depending on the number of users, and the consumption of resources of the applications themselves, the hosting costs could be higher than in the other options, as it would consume more resources due to the design of one user per container.

Hosting options

Shiny-Proxy is a scalable solution from the get-go, and you have a couple of options to deploy applications:

1. Direct virtual machine deployment
2. Containerized deployment

Direct virtual machine deployment

The solution uses Docker as its backend for spawning containers (with apps). Therefore Docker has to be installed on the virtual machine. Shiny-Proxy itself can be run in a container or as a regular Java program.

As this option creates one container per user, it can quickly deplete the resources available for a virtual machine, so for a high number of users, it is not recommended to host it directly in a single VM.

There’s some potential to utilize multiple virtual machines, but this is counterproductive when Shiny-Proxy can take advantage of container technologies directly.

Containerized deployment

This is the scenario for which Shiny-Proxy is more adequate. You can utilize a Docker Swarm or Kubernetes platform to host the spawned containers, and Shiny-Proxy itself could also be containerized.

For small to medium user bases, with multiple applications, this scenario is a good fit. However, further consideration has to be given to the extra resources necessary to run a container per user.

Wrapping up

Shiny Proxy allows for more complex setups and guarantees some level of scalability for the applications hosted with it. The limitation of one user per container is by design, and it’s great for small to medium utilization. It allows for complex setups with authentication and can work with other types of applications.

If the number of applications that need to be deployed is high or the application has a medium to big user base, it can easily consume a lot of resources. It still has some overhead in setting up, managing, and monitoring.

We conducted a benchmark test comparing ShinyProxy and Posit Connect. Check out the outcome in this blog post.

Option #5: Posit Connect

Posit Connect is the new iteration of hosting solutions from Posit, following Shiny Server Pro, the enterprise version of Shiny Server Open Source, offered by Posit.

This is the most battle-tested and efficient solution in terms of resource usage. It works well with complex scenarios.

This is our overview of the 5 comparison points:

• Authentication requirements: Posit Connect has the biggest support for authentication scenarios and the most comprehensive permissions setup.
• Security requirements: This is a self-hosted solution, meaning that the security requirements are transferred to how Posit Connect is hosted and utilized.
• Scaling requirements: Scaling is provided out of the box. Posit Connect isolates processes for each application, permitting multiple users per process, and can launch more processes as required to serve users. It has a great economy of resource utilization with little overhead due to this isolation.
• Operation management overhead tolerance: The overhead necessary to maintain this solution is dependent on how it’s hosted. It is developed so that it is easy to maintain and use.
• Investment: This solution has a licensing cost. This is based on the number of server activations and users. While there’s some overhead in installing and maintaining, it is by far the simplest solution.

First time using Posit Connect? Explore our beginner’s guide to help you get started.

Hosting options

Posit Connect is a solution optimized for all kinds of deployment complexities. We’ll explore:

1. Direct virtual machine deployments
2. Containerized deployments

Direct virtual machine deployments

Posit Connect can be hosted directly on virtual machines, be it in a cluster configuration or single server configuration. Having cluster configuration means that each Connect can communicate with each other, and coordinate resources between each other. It is possible to set up auto-scaling in this scenario with scaling sets of virtual machines.

This is the traditional path to install Posit Connect and it’s a stable setup. With little more overhead in comparison to managing virtual machines.

Containerized deployments

Posit Connect has one capability called “off-host execution” in which currently it is supported to have processes for applications being launched on a Kubernetes Cluster, in containers.

This allows for a much more scalable solution in the long run, but it also provides some overhead in managing a Kubernetes Cluster. It’s ideal for complex deployments, and heavy usage, and recommended if there is already a Kubernetes Cluster deployed and being used in other contexts.

Wrapping up

Posit Connect is the enterprise battleship for hosting Shiny (and now also Python) applications. It is the easiest solution to maintain long term, but that comes as a premium with its licensing costs. It serves well small use cases, and excels with complex and demanding workloads.

It is developed to be easily maintained and used, and integrates seamlessly with other Posit Products.

As a Posit Partner, Appsilon has extensive experience hosting, managing and optimizing this solution for small to big use cases.

Summing up R Shiny Deployment Options

To conclude, there are numerous ways to deploy an R Shiny application.

Some options leverage open source technologies, others come with licensing costs. Some are tailored to simple scenarios where you have to do everything from scratch, others offer everything but a kitchen sink. In other words, you have options.

For simple scenarios, we recommend going with Shiny Server Open Source or a self-hosted Vanilla Shiny application. For more complex scenarios, Shiny Proxy and Posit Connect would be more appropriate, being that Posit Connect is the most effective solution for every scenario, but has bigger upfront costs due to its licensing.

In terms of deployment options, it heavily depends on the capabilities to maintain the solution long-term, and the scaling requirements, being that Posit Connect is more managed and has better resource efficiency.

We also recommend going with containers everywhere it could be possible, for almost all the scenarios, as it’s the most effective solution in the long run.

Appsilon has experience with all of these scenarios and technologies, so don’t hesitate to reach out. We’re a video call away to help you decide which option fits best your use case.

Speaking of containers, you should really try Docker for R. Follow our guide to containerize your first R script.

This article was co-authored by Dario Radečić.

The post appeared first on appsilon.com/blog/.