Shiny without Boundaries

One App, Multiple Destinations

talk
r
shiny
devops
webassembly
wasm
shinylive
Author

James Balamuta

Published

April 19, 2025

Abstract

This guest lecture explored seven deployment pathways that enable R developers to deploy a single Shiny application across multiple environments. From traditional servers to cutting-edge WebAssembly solutions, the presentation demonstrated how to reach users regardless of their technical constraints, with special focus on shinylive / WebAssembly deployment.

On Wednesday evening, I had the pleasure of presenting a guest lecture at my alma mater for STAT 447 at University of Illinois Urbana-Champaign (UIUC) on deploying Shiny applications across multiple environments. The lecture explored how developers can create a single Shiny app and deploy it virtually anywhere to reach users where they are.

The Deployment Challenge

Shiny has revolutionized how R users create interactive web applications, but deployment remains a significant challenge. Users face diverse environment constraints, technical teams have different infrastructure preferences, and security requirements vary widely across organizations.

As I shared in the lecture, these challenges often lead to questions like:

  • How can we deploy Shiny apps in environments without internet access?
  • What options exist for users who can’t install R?
  • How can we scale Shiny apps for enterprise-wide deployment?

Seven Deployment Pathways

During the lecture, I covered seven different approaches to deploying Shiny applications:

1. On-Premise Servers

The traditional approach offers complete control over infrastructure with enhanced security and compliance capabilities. It’s ideal for organizations with strict data governance requirements, though it comes with infrastructure costs and maintenance burdens.

2. Cloud Services

Services like Posit Connect Cloud and shinyapps.io provide managed solutions that simplify deployment. They offer built-in security and easy scaling but require internet connectivity and subscription costs.

3. Docker Containers

Containerization provides environment consistency and portability across systems. I demonstrated how tools like shinydocker can simplify the containerization process, though this approach does have a learning curve.

4. Electron Desktop Applications

For offline capability with a native desktop experience, Electron allows packaging Shiny as standalone desktop applications. This approach works well for users who can’t access web servers but comes with larger application sizes.

5. WebAssembly Browser Solutions

Shinylive represents a breakthrough in Shiny deployment, allowing apps to run entirely in the browser without a compute server. During the lecture, I demonstrated how to:

  • Convert existing Shiny apps to Shinylive
  • Deploy apps to GitHub Pages
  • Integrate Shinylive with Quarto documents

This approach eliminates deployment costs and maintenance overhead while offering better scalability, though it does have package support limitations.

6. R Packages

Packaging Shiny apps provides reproducible installation and easy distribution to R users. This approach works seamlessly within existing R workflows but requires users to have R installed.

7. Quarto Integration

Embedding Shiny in Quarto documents is excellent for creating Shiny dashboards and has a learning curve for a standard shiny application. However, it does come with similar deployment considerations to normal Shiny apps.

Spotlight on Shinylive

A significant portion of the lecture focused on Shinylive, which represents a paradigm shift in how we deploy Shiny applications. By compiling R to WebAssembly, Shinylive allows Shiny apps to run entirely client-side.

Here’s a simple example of converting a Shiny app to Shinylive:

# Install the shinylive package
install.packages("shinylive")

# Convert a Shiny app to Shinylive
shinylive::export(".", "_site")

# View locally using httpuv
httpuv::runStaticServer("_site")

The converted app can then be deployed to GitHub Pages, Quarto Pub, or any static web host—eliminating the need for a dedicated R server.

Choosing the Right Deployment Path

Each deployment pathway has its advantages and considerations. The best choice depends on factors like:

  • User environment constraints
  • Technical infrastructure preferences
  • Security and compliance requirements
  • Need for offline vs. online access
  • Cost and maintenance considerations

As I emphasized in the lecture, the goal isn’t to choose a single deployment method, but rather to leverage multiple approaches to reach users where they are.

Resources for Further Learning

For those interested in exploring these deployment pathways further, here are some valuable resources:

The full presentation slides and resources are available on GitHub.

The presentation slides are licensed under CC BY-NC-ND 4.0

Final Thoughts

The landscape of Shiny deployment continues to evolve, with options like Shinylive opening up new possibilities for distribution. By understanding the various deployment pathways, developers can ensure their Shiny applications reach users regardless of environment constraints or technical preferences.

As we discussed in the Q&A session, the future of Shiny deployment likely involves a hybrid approach—leveraging different deployment methods to satisfy different use cases, all from a single codebase.