Deploying to shinyapps.io

To deploy your Shiny app on shinyapps.io, first ensure you have an rsconnect account set up. Check existing accounts in RStudio using rsconnect::accounts(). If you need to set up a new account, visit the ShinyApps Dashboard. Here, you’ll find a pre-filled rsconnect::setAccountInfo() command. Execute this in RStudio to link your account. If deploying to the main account of our company, request the necessary credentials from the person managing it.

Deploying your Shiny app on shinyapps.io is straightforward if it doesn’t rely on private repository packages. Simply open your app script (app.R, server.R, or ui.R) and click the blue “Publish” button adjacent to the “Run App” button in RStudio. Alternatively, deploy using the rsconnect::deployApp() function. The shinyapps platform automatically creates an image reflecting your R environment, including the R version and CRAN package versions. However, in our practice, deploying apps that rely on packages from private repositories is more common and presents unique challenges. We’ll delve into this topic in the next chapter.

When your Shiny app includes packages from private repositories, rsconnect cannot determine how to install these packages based solely on your local library installations. In such cases, you need to initialize renv in your project.

With renv initialized in your project, shinyapps.io uses only the renv.lock file, not your library state, to build the deployment image. Ensure to update renv.lock regularly with renv::snapshot().

It’s important to note that shinyapps.io currently supports private packages only when they’re installed from GitHub. For this to work you need to:

1. Grant shinyapps.io access to your private GitHub repositories.
2. Ensure that your private packages are listed as installed from GitHub in the renv.lock file.

For the first requirement, refer to this guide. As for the second requirement, while we normally utilize an internal CRAN for package installations via install.packages() or other similar commands, this method won’t be applicable. Instead, use remotes::install_github(). For instance:

remotes::install_github(
  repo = "g6t/g6tr",
  subdir = "packages/g6tr.ui"
)

In our handbook, we recommend naming your GitHub token environment variable GH_PAT rather than GITHUB_PAT. However, in this situation, using GITHUB_PAT is advisable since remotes depends on it. While it’s possible to directly provide a GitHub token via the auth_token parameter, this token is not automatically applied to any private dependencies of that package. Instead, remotes::install_github() will revert to using the GITHUB_PAT environment variable for these dependencies. This is particularly relevant for g6tr packages, as they often have dependencies within the g6tr suite.

Lastly, in connection with the above point, it’s essential to install all necessary g6tr packages from GitHub for your application’s functionality, not just the ones directly used. For instance, if your application employs g6tr.brand functions, it inherently depends on g6tr.theme and g6tr.ui, which also need to be installed from GitHub. This leads to a general rule:

All g6tr packages mentioned in the renv.lock file must be installed from github.

An effective approach to identify all the g6tr packages required for your application is by using renv::lockfile_read(). This function reads the renv.lock file and organizes its contents into a structured object, making it more user-friendly than the raw textual format. Crucially, you can easily identify packages that are installed from GitHub in this object, as they will be marked with Source = "github".

When re-deploying a Shiny app after a period, you might face deployment errors with g6tr packages, even if the renv.lock file hasn’t changed. It is unclear why that happens, but the unconfirmed intuition is that rsconnect will only correctly handle records of packages installed from private GitHub repositories if they correspond to the most recent state of those repositories. If a clear solution to your issue isn’t immediately evident, it’s advisable to reinstall all necessary g6tr packages using remotes::install_github().

Sometimes after running renv::snapshot() you may be shown a message that looks similar to this:

# The following package(s) were installed from sources, but may be available from the following remotes:
#   
#   - aws.s3    [cloudyr/aws.s3]
# - cmdstanr  [stan-dev/cmdstanr]
# 
# Would you like to use these remote sources for these packages?
#   See 'snapshot.inference' in ?renv::config for more details.
# Otherwise, these packages will be recorded with an unknown source.

Don’t ever agree to that!

For this kind of deployment errors

# unable to satisfy package: StanHeaders (2.26.25)

Usually re-installing the mentioned package with renv::install() helps. Just don’t forget to renv::snapshot() afterwards.

# Error: Unhandled Exception: Child Task 1362818277 failed: Error parsing manifest: GithubSHA1 must be specified for GitHub package source
# Execution halted

This means that one of the packages installed from github lacks RemoteSha field in the corresponding renv.lock record. Try reinstalling with remotes::install_github().