The Hosting Data Apps website recently celebrated its 6-months anniversary. During this time I have written 40 posts, almost all about Shiny hosting options. Some of these posts reviewed particular hosting options, such as Shinyapps.io, Shiny Server, Heroku, and ShinyProxy.

A lot has been said about the hosting options themselves, but what about the needs of the developers and the users? The goal of this post is to address this shortcoming by summarizing the reviews.

How not to do a review

You might have seen various websites listing comparisons titled "A vs. B". I was wondering if doing something like that would make sense for the Hosting Data site. Think like "Which is better: Shinyapps or Heroku?".

This would instantly give me 36 more articles to write. Plenty of ammunition for the next 9 months by recycling the previous content. Easy-peasy, if all I wanted was to boost the page ranking.

Instead, I decided that these A vs. B posts are useless. They fail to ask the most important question: "which option is better for what"? This is where developers and the users of the app come into the picture with their specific needs and constraints.

You could say, for example, that "I want to host my portfolio for free and I don't care about a custom domain name". Or a nonprofit might say, "we want to host our apps at low cost, we want custom domains, and we want to be able to handle surge traffic, but we don't want to maintain any servers".

These are really specific criteria, and if you ask me, I might say Shinyapps.io is best for you and Heroku with a Docker-based deployment is best for this organization. But how would you or I make such a decision?

The 3 step process to make the decision

If you have been developing Shiny apps, you might already have your preferred way of deployment. But as your needs evolve, you will identify additional requirements and might find that your go-to option is not the best anymore. Then you'll do some research and find the next option.

If you are not yet familiar with Shiny hosting options, you still need to make an informed choice at some point, so that you are not wasting your time and effort on something that will not serve you well over the long run. Here is the 3 step process that you can follow to help you with this decision.

Before you begin take a piece of paper.

1. Start with the why

Why do you want the app or apps deployed? Are you building a portfolio to boost your career? Are you deploying useful apps for stakeholders or clients of your organization? Are you trying to sell an app as a software-as-a-service (SaaS) offering?

Write down your answer.

Getting clear on the why is the most important question. You might even realize that you don't need to host your Shiny app. For example, your app might be used on a laptop as a GUI to analyze data by non-specialists in the field without internet or cell coverage. In this case, no need to move on to step 2, because all you need is to run Shiny locally.

However, if your answer makes it clear to you that your users will be accessing the app over the Internet, move on to step 2.

2. List your requirements

Answering the Why question will probably reveal important details about your motivations, your audience, the number of apps you are going to host, etc. The answer will also bring you closer to identifying the requirements that you'll need.

For example, do you need a custom domain, how many users are you expecting, do you need authentication or app-level authorization? Do you want to host a single app or do you need to host many apps? Will you host non-Shiny apps?

Write these down too.

The following table lists the important features for many different Shiny hosting options. The table lists tiers offered by the same company as a separate option. Use this table to find the options that meet your requirements. For now, just ignore the columns inside the blue rectangle.

If you crave a more interactive experience, I made a filterable version:

Here is the link to the page where you can filter the options:

Shiny Hosting Options

Pick the right hosting option for your Shiny app

Hosting Data Apps

Once you filter the table according to your requirements, you'll see a list of your ideal hosting options. Put these in the file or onto the paper too.

3. Identify your constraints

The last step involves identifying your constraints:

• What is your budget?
• What is your current skill level?
• How much time do you have time?

Recognizing these constraints will guide you toward an optimal solution. This is the point where the columns inside the blue rectangle come in.

The "Total Cost" of ownership (USD/year) covers licensing fees and operating costs for the "Number of Apps" listed in the table. Prices range quite a bit from free to the tens of thousands. Price increases with performance and with the availability of enterprise features, such as custom domains and authentication.

PaaS means platform-as-a-service, i.e. it is a fully managed system without you having to worry about the underlying infrastructure. This also means less control over the infrastructure, i.e. when it comes to choosing the data region where your app is served from.

Unlimited app hours are more common for self-hosted options or paid PaaS plans including a single app. The need to host multiple apps will involve some compromises. The ability to host non-Shiny apps (Dahs, Streamlit, etc.) is a feature for RStudio Connect and the Docker-based options (Shinyapps and Shiny Server can host Shiny for Python).

Time as a constraint will depend on how far your current skill level is from the level needed for a specific hosting option. You also have to consider that some options are fully managed PaaS offerings, others you have to manage, or learn how to use Docker.

If you have to develop new skills, it might take longer. If you have to manage your servers, it will take more time to get started and then you are on the hook for maintaining your setup.

Make your selections inside the columns within the blue area.

You are done!

After the 3-step process, you should see only a few or a single option left. Click on the name of the hosting option and the link will take you to the relevant tag page on the Hosting Data Apps website:

• Follow the instructions in the tutorials to get started
• At the end of each post, you'll find a Further reading section listing additional resources

If there is no option left in the table, then you might need to be more realistic about your expectations or relax some of your constraints. For example, to keep costs low, you could spend more time and invest in skill development. But if you have more room in your budget, you might choose a different path. You can also revise your requirements until you find an acceptable solution.

Options at a glance

The following diagram gives an intuitive overview of the different options. The vertical axis represents the total cost from the table above: free, low, and high cost. The horizontal axis shows a range of skills you need to set up and manage your hosting solution. It can be as simple as pushing a button, or as complex as managing servers or cloud clusters.

The hosting options in this diagram are not separated by tiers but rather shown as spanning over a range. The fill colours identify Docker and non-Docker-based options, the stroke styling indicates the PaaS solutions.

What is next

If you followed the 3-step process to collect all the information you need, it is likely that you have found an option that is best for your needs. Now go ahead and learn more about that option, deploy, and start hosting your app.

Shiny is a very popular interactive data application framework. As a result, new hosting options are popping up every time. As the number of these hosting options grows in the future, I might update this post by adding the new contenders to the table.

If you know a Shiny hosting option that is not listed in the table, add that to this form so that I can include it next time!

I introduced the DigitalOcean App Platform in a previous post and described how to deploy Shiny apps from existing Docker images using the control panel or the command line.

This post continues the App Platform discussion by looking at how to integrate the App Platform with GitHub and set up continuous integration and deployment (CICD).

Prerequisites

If you have not done so before, go to the App Platform landing page and sign up for a DigitalOcean account. Log into your account and go to your dashboard. In the left drawer, click on 'Apps'.

For the analythium/app-platform-shiny repository because you will have to give permissions to access the repo.

GitHub - analythium/app-platform-shiny: DigitalOcean App Platform Example for Shiny

DigitalOcean App Platform Example for Shiny. Contribute to analythium/app-platform-shiny development by creating an account on GitHub.

GitHubanalythium

Here is what's inside the repo:

.
├── .do
│   ├── app.yaml
│   └── deploy.template.yaml
├── app
│   ├── global.R
│   ├── server.R
│   └── ui.R
├── .gitignore
├── Dockerfile
├── LICENSE
├── README.md
└── renv.lock

The .do folder contains a template file that is needed if you want to deploy the Shiny app template from the button in the README file. The app specification (app.yaml) that was introduced before, but it is largely simplified:

name: app-platform-shiny
services:
- dockerfile_path: Dockerfile
  github:
    branch: main
    deploy_on_push: true
    repo: analythium/app-platform-shiny
  name: app-platform-shiny

The app folder contains multiple files for the Shiny app. The Dockerfile uses the renv package to handle the dependencies specified in the renv.lock file.

The app itself, as you will see, is a relatively simple example with some range slider, a dependency that does not require building from source. It also has a file upload button – I use the upload functionality to test when a large file upload is required. Large file upload is often restricted, Shiny itself has a 5 Mb file size limit.

GitHub integration

Let's set up the GitHub integration. Go to the DigitalOcean control panel In your control panel. Click on 'Launch New App' under the 'App' item in the left side menu:

When you are asked to choose a source, click on the GitHub icon:

Follow the prompts and install the GitHub app for your personal account or the organization of your choice. Select 'All repositories' or 'Only select repositories' as appropriate. Finally, click 'Save':

Deploy from GitHub repository

Now go back to the Apps control panel. Select the repository from the dropdown menu, specify the branch you wish to deploy. If you want to deploy both a development and a production version of the same repository, you can create multiple apps with the same repo but using different branches.

Leave 'autodeploy' checked if you want to trigger new deployments when the code changes, then click 'Next':

Review the app settings inferred from the Dockerfile, i.e. the HTTP port, etc.:

Type in the name of the service, select the data region, then click 'Next:

The final step lets you define the performance of the app and the corresponding pricing. Here I use the smallest size under the 'Basic' plan for $5 US per month:

After a few minutes, you should see the green checks besides the build and deployment log entries. Building the image might take some time, depending on the number of dependencies in your app:

Follow the app URL from the control panel to see the app online served over HTTPS:

Add a custom domain

Adding a custom domain is done via the control panel. Click 'Add Domain':

Follow the prompts and copy the app URL:

Add a CNAME record in your DNS settings on your DNS providers page (Google Domains shown here), make it point to a domain or subdomain of yours:

You will see the custom domain listed in the app settings:

Click on your new custom domain link and check. You might have to wait a bit if your record has not propagated through the name servers:

Auto deploy updates

Next, we will make some changes to the Shiny app and see the app magically update via git. Do it in your forged repo. The small change I made was to edit the app title. Here is the change:

Once you commit the changes and push to GitHub, it triggers the web-flow pipeline. The new deployment is then listed in the deployment history of your app:

Visit the custom URL and see the new version deployed:

Don't forget to delete the app and the CNAME record if you don't need them anymore to avoid accruing hosting charges. Dynamic app hosting is not free on DigitalOcean.

Testing before deployment

One potential issue with this GitHub integration is it does not depend on passing tests before deployment. If you want to test your changes before deployment, here are the steps to follow:

1. push changes to the development branch,
2. run automated tests for the development branch, e.g. using GitHub actions,
3. set up the production branch as a protected branch, so that merging pull requests require passing tests.

Conclusions

When we deployed an exiting Docker image, the image was pulled to the App Platform from Docker Hub. In this case, an immutable image was pushed and pulled.

The GitHub integration described here takes a different approach. It builds the Docker image after changes are pushed to a pre-defined branch in the GitHub repository. The image is built and stored in the DigitalOcean Container Registry.

With this approach, you get a new deployment on every git push event. You can debate how much this automated deployment (CD) can be considered continuous integration and deployment (CICD) without actually having the CI part.

Testing the app before deployment requires additional steps as part of your git workflow. To achieve full CICD experience, you can use the doctl command-line utility in GitHub Actions. As it turns out, this route is a bit more involved and there are several gotchas to address. Thus, I will explain it in a follow-up post.

Further reading

• App Platform documentation
• Deploy app from a monorepo
• Troubleshoot your app