A few years ago, I mentored a developer who had spent three weeks crafting a stunning financial risk dashboard. He was convinced it was a masterpiece. When it was finished, he emailed the .R files and a CSV of the data to the CFO, thinking he was the hero of the quarter. Two hours later, he got a curt reply: "I don't know what a 'library' is, and I can't find the 'Run' button." It was a classic case of "it works on my machine." The CFO didn't want to install RStudio or manage dependencies; he just wanted a URL he could click on his iPad during a board meeting.

That's the fundamental gap we're closing today. Writing a great Shiny app is only half the battle; getting it into the hands of people who don't know R is where the real engineering happens. Depending on your budget and your infrastructure, you generally have two paths: the managed ease of shinyapps.io or the absolute control of Docker.

The Low-Friction Path via shinyapps.io

If you need a dashboard live in five minutes, shinyapps.io is your best friend. It's a Platform-as-a-Service (PaaS) hosted by Posit. You don't have to worry about server configuration, Linux updates, or firewall rules. You simply use the rsconnect package to "push" your app from your local environment to their servers.

I usually recommend this for prototypes or internal tools where you don't have a dedicated DevOps team. For example, if you've built a real-time air quality monitoring app that pulls from an API, you can deploy it with a few lines of code:

install.packages("rsconnect")
rsconnect::deployApp('path/to/your/air_quality_app')

The magic happens behind the scenes: rsconnect bundles your app, identifies every package you've called in your library() statements, and builds a remote environment that mirrors your local one. To be honest, it's a bit of a black box, which is great until it isn't. If your app requires a specific system-level dependency (like a weird C++ library) that isn't pre-installed on their servers, you'll hit a wall. That's when you need to move to the "heavy lifting" option.

Taking Full Control with Docker Containers

When I work on enterprise-grade apps—especially those handling sensitive healthcare or financial data—shinyapps.io usually isn't an option because the data cannot leave the company's private cloud. This is where Docker comes in. Think of a Docker container as a lightweight, standalone package that includes everything: the OS, the R version, the packages, and your code.

Instead of hoping the server has the right version of ggplot2, you define exactly what the server looks like in a Dockerfile. I almost always start with the rocker/shiny image, which is a community-maintained set of Docker images specifically for R. A basic Dockerfile for a professional deployment looks something like this:

FROM rocker/shiny:latest

# Install system dependencies for specific R packages
RUN apt-get update && apt-get install -y libcurl4-openssl-dev libssl-dev

# Install R packages
RUN R -e "install.packages(c('shiny', 'dplyr', 'plotly'))"

# Copy the app files into the image
COPY ./my_dashboard /srv/shiny-server/my_dashboard

EXPOSE 3838

CMD ["/usr/bin/shiny-server"]

Once you build this image, it will run exactly the same way on your laptop, a colleague's Mac, or an AWS EC2 instance. It removes the "it works on my machine" excuse entirely because the "machine" is now a portable file you've created. It's more overhead to set up, but it's the only way to ensure total reproducibility in a production environment.

📋 Practical Task

Exercise: Deploying a Global Temperature Anomaly Dashboard

You have been handed a completed Shiny app called temp_anomaly_app that visualizes global temperature shifts. Your goal is to prepare this app for a production environment. Perform the following tasks:

• Part A (Managed Path): Write the R code required to authenticate your account and deploy the temp_anomaly_app folder to shinyapps.io using the rsconnect package.
• Part B (Container Path): Create a Dockerfile for this app. The app requires the tidyverse and leaflet packages. Ensure your Dockerfile:
  • Starts from a rocker/shiny base image.
  • Installs the necessary system dependencies for leaflet (if any) and the R packages mentioned.
  • Copies the local temp_anomaly_app directory to the correct shiny-server path.
  • Exposes the default Shiny port.

Deliverable: Provide the R deployment script for Part A and the full text of the Dockerfile for Part B.