Skip to contents

Deploying the Web App

Source: vignettes/dev-deploy-app.Rmd
dev-deploy-app.Rmd

Current approach

The older info below is obsolete and is retained here just to document how deployment used to be done. However, these issues might still be relevant to deploying/hosting:

  1. See info on setting isPublic=T in Defaults and Custom Settings for the Web App. One way to improve this process would be to modify the isPublic toggle to be an environment variable. This would allow us to set the value once in each application server, and not have to change it each time we push updates. Moreover, it would make testing the app easier to handle in the GitHub actions (see shinytests vignette). Note that after mid-2025 the isPublic setting has been handled as explained in the article Defaults and Custom Settings for the Web App.

  2. See info on other parameters as well, in [Defaults and Custom Settings for the Web App](dev-app-settings.html.

  3. The EPA-hosted app used a Posit Connect server configured to re-publish the shiny app directly from github.com content whenever it saw changes in the specified repo and branch, and that same approach could be used by anyone else hosting the app.

  4. The notes below about updating the manifest.json file using a script like rsconnect_manifest_update.R might still be relevant to someone deploying/ hosting the app.

Older information

While the EPA servers hosting the EJAM web application are no longer up and running as of mid-2025, this document outlines the application deployment process that had been used. The process involved

  1. development work on an internal/private repo called EJAM that had been used to deploy an internal/expert version of the web app for staff, and

  2. a public repo called EJAM-open that had been used to share the latest version and publish it to host a public version of the web app for use in EJSCREEN (until early 2025).

Update EJAM Application

After updating the main branch in the public EJAM code repository (see Updating the Package as a New Release vignette) so that the public repo had the latest version…

  1. Sourced rsconnect_manifest_update.R, using the public repo as the repo specified in the remotes::install_github() command.

    1. In this way, we were updating the manifest.json file in the repo from which the web app was deployed, but with reference to the repo that was public (since those were not the same repo).
    2. It was important to use the public repo as this ensured the Posit Connect server for the hosted site could install the EJAM package as a dependency. (It did not necessarily have access to the private EJAM repo)

  2. Updated Staging + Production servers

    1. Merged the EJAM main branch into the PUBLIC-EJSCREEN branch (in the repo to be deployed from)
    2. Ensured isPublic parameter was set to TRUE in the call to the ejamapp() function in app.R
      1. The isPublic flag determined whether to show the public or internal/expert version of the web application.
    3. The branch PUBLIC-EJSCREEN was automatically connected to the public site, so changes to this branch were automatically pulled into the site.

  3. Updated Deploy Posit server

    1. Merged the EJAM main branch into the deploy-posit branch (in the repo to be deployed from)
    2. Ensured isPublic parameter was set to FALSE
    3. deploy-posit was automatically connected to the development/internal/expert version of the web app, so changes to this branch were automatically pulled into the site. In other words, the EPA-hosted app had a Posit Connect server configured to re-publish the shiny app directly from github.com content whenever it saw changes in the specified repo and branch.

  4. Merged main back into development so that development would have the updated manifest.json file. This ensured all branches were consistent.