Planning and Analysis

This section will guide you through the planning and analysis steps that you should follow before performing an off-host deployment of Posit Connect.

These steps include:

Analysis of existing content

Note

If your Connect installation is new, you can skip this step.

The information gathered as part of this step will be of use to you post-deployment.

Content Requirements

Connect uses images with Quarto to prepare and execute your content. These images must satisfy the existing R & Python content requirements as well as any system dependencies required for the content’s dependent packages or libraries.

Exact Quarto requirements are content dependent. For more information, see the table in the Building Images for use as Execution Environments section. If you are migrating from an existing Connect server, make sure the same version of Quarto is now available in your content images.

Note

If you are unsure which version of Quarto is running on your existing server, you can use this endpoint using the Connect API to find out.

Example recipes are available in the Cookbook.

Note

Posit has made a set of public container images available, which are used by the Helm Chart by default. We recommend performing your initial migration using these default images and then after confirming the default images are functional, proceed to configuring your custom images.

Identification of performance-critical and important content

During the post-deployment validation of your new Connect server, you have the opportunity to optimize first-time access of content previously deployed to your old server. You can also validate that any particularly important content items are executing successfully on your new server. These post-deployment validation steps require a list of relevant content GUIDs and access paths, which you should identify and record for later.

If you cannot easily identify important content items, the rsconnect content search tool included in the rsconnect-python package can perform usage analysis. This tool provides content query functionality which can be used to help identify important content items.

For further details on optimizing first-time content access, see the Server Management Runtime Cache Workflow.

Pull the Helm charts used in this guide

# Posit Connect
helm repo add rstudio https://helm.rstudio.com

# Pull the latest versions of the Helm charts
helm repo update

Network connectivity verification

Note

If you don’t have PostgreSQL or shared storage installations yet, don’t worry. We will create them in the next section.

  1. Verify that the Kubernetes cluster has connectivity to shared storage. If migrating, also confirm connectivity to the shared storage where the Connect data files are located.

  2. Verify that you can access the PostgreSQL server from within the cluster.

  3. Verify that the ports required for accessing the Connect server are not blocked (by default, 30000 - 32767 is the range expected).

Shared storage capacity verification

Before beginning the installation, ensure you have enough space in your shared storage. We recommend 100+ GB of storage in our Recommended system requirements. If you have an existing installation, we recommend you allocate two times the amount of space currently being used.

Posit Connect license validation

Note

If your Connect installation is new, you can skip this step.

If you plan to use an existing Connect license, confirm that your license allows additional activations. Check your license status using the steps outlined in the Licensing section.

If your existing license lacks additional activations or if you would like a separate evaluation license, speak to your dedicated Posit Customer Success contact or email Posit Sales (). Mention that you are trialing off-host execution.

Planning for downtime

Note

If your Connect installation is new, you can skip this step.

Coordinate with your stakeholders and warn users ahead of an upgrade with system messages. Your Connect server will be out-of-service during the migration.

The time required depends on the following factors:

  • Number of content bundles published to your server
  • The difference of GID / UID assignments between your existing files vs what is present on the runtime images
  • The amount of content migration optimization that you choose to perform

Once your planning is done, you can continue on to the Kubernetes Cluster Preparation steps.