Migrating to Posit Connect from Shiny Server Pro

Relative to Shiny Server (Pro), Posit (formerly RStudio) Connect automates much of the administrative load and gives users the ability to better manage their own apps. For admins used to Shiny Server (Pro), migrating to Connect requires thinking about app management somewhat differently. This article points out the most substantial changes.

In addition to the administrative changes, Posit Connect supports a much richer set of content types than Shiny Server (Pro), giving your team more flexibility for larger projects, more diverse outputs, and easier automation. For more information on which product is the right choice for your team, please see this article.

For specifics on how to map server settings in Shiny Server (Pro) to Posit Connect settings and how to migrate apps, please see this article.

Differences Between Posit Connect and Shiny Server (Pro)

More Types of Users

In Shiny Server (Pro), a Server Admin must SSH into the server for all administrative tasks. Apps are managed by manually installing components and editing server-wide config files. The only other option for server access is to be a Viewer, who can only view apps.

Connect adds two new roles to allow users to administer apps without needing to SSH to the server itself. Publishers can deploy and manage individual pieces of content, and Administrators can make changes within the Connect UI like managing users and content (see here for complete list of administrator rights); they may or may not be Server Admins with SSH access.

Multiple Versions of R and Per-App Package Libraries

In Shiny Server (Pro), a server admin installs R and required R packages. Because there is only one package library per version of R, all apps must use the same package versions. When new packages or package versions are needed, the service requires a restart to find the new packages.

This paradigm is completely different in Posit Connect. Server Admins must install versions of R, but do not manage R packages at all. Instead, Connect automatically manages a per-app package library. 

In most cases this is completely automatic. When an app is deployed, Connect captures the app’s development R version and R packages, matches the version of R, and re-creates the app environment on the server. Connect will use a previously cached version of packages if available or will install the packages from CRAN, RStudio Package Manager, a git repo, or elsewhere as needed.

More Flexibility in Deployment

Posit Connect’s deployments are much more automated and flexible than in Shiny Server (Pro). 

The biggest change is that Connect manages app file locations instead of a Server Admin and does not reveal the directory structure to end-users. 

In Connect, the absolute file paths of the apps themselves are not easily findable and should not be used in R code. Shiny apps that make use of the absolute path of the directory on Shiny Server (Pro) should be updated to access data in a way suitable for Connect.

The deployment method itself is also much more flexible in Connect. Deploying an app to Shiny Server (Pro) must be done by a Server Admin, who uploads the Shiny apps and manually configures dependencies like R and Python packages as well as app access, environment variables, app URLs, and app runtime settings.

In Connect, there are three supported deployment methods: push-button, git-backed, or via API. An app’s publisher can choose any of the three support deployment methods for each piece of content. App publishers can individually manage who can view and edit their app, environment variables, app URLs, and runtime settings via the dashboard for each app in Posit Connect. 

Python Support

Shiny Server (Pro) has no direct support for Python. Shiny apps can use Python via R’s reticulate package, but Python content cannot be deployed on its own. 

Posit Connect supports several types of Python content, including Jupyter Notebooks, Flask and Bottle APIs, Dash apps, and more. For this content to be deployed, a server admin must configure one or more versions of Python. When a piece of content is deployed, the Python version will be matched and the set of required packages restored automatically. virtualenv is used to create content-specific environments and pip is used to install Python packages.