Selecting the Right Architecture for Posit Connect

The right architecture for your deployment of Posit Connect depends on your team and use case. Before you can decide on the right architecture, you must understand how your team uses or will use Connect, and how Connect fits into your existing patterns for deploying and maintaining applications.

Connect is a server based publishing platform that supports a wide variety of Python and R based content. It can be used to host and share information in dashboards and reports, as well as host APIs, data and ML models. Content hosted on Connect is deployed into sandboxed, virtual environments that run in isolation from one other.

Architecture considerations

Below, we’ll cover some of the factors you need to understand in order to choose the right architecture for your team.

Hardware sizing and performance

Connect functions as both a web server and an application server. This means that the hardware specifications for Connect depend on the number and type of applications, documents, and analysis running on the server. Additionally, the number of concurrent users and the runtime settings of the content they are viewing (where applicable) have an impact on performance.

The key factors that affect Connect performance are:

1. The number and types of content running on the server.
2. The number of concurrent users on the server.
3. The runtime settings of the content.

CPU requirements

Connect CPU utilization varies based on the type of content that is being viewed.

• Static content such as Quarto, R Markdown, or Jupyter notebooks requires very little CPU if it is pre-rendered before being published. The same documents, when published with source code, need additional computing resources when they execute in place (either when published or refreshed). At that time, Python or R code in the document will execute processes on the Connect server.
• APIs need processing power available when a request is made through them.
• Applications such as Shiny or Streamlit require CPU access while they are open during an interactive session. (Note that interactive content will continue to consume resources if the timeout settings are not properly set as well.)

In summary, CPU cores are needed for each of the following tasks:

• Execution of Python and R code contained in a notebook, R Markdown or Quarto document
• Requests made to a hosted API
• Interactive application or dashboard utilization
• Other processing tasks related to running the Connect server

The key consideration is what is running concurrently.

Connect CPU Rule-of-Thumb: (1 CPU per concurrent processing task) + (1 CPU for background tasks)

Parallelization Caveat: Connect is capable of executing nearly any Python or R code that has been uploaded to it. This includes code that is parallelized and utilizes multiple cores. Executing parallelized code can quickly reduce the available CPU for other tasks. A common example of this type of multi-CPU task would be training an ML model. If you plan to run parallelized code on your Connect server, we strongly recommend that you implement either cgroups to limit the resources that the code can use, or employ a horizontally-scaled architecture such as a load-balanced cluster or Kubernetes.

RAM requirements

Connect acts as both a web and application server, meaning that multiple users can be viewing or using very different content at the same time. This flexibility also means resource utilization on the server can be quite varied depending on the type of content and the number of concurrent users on the system at one time. It’s important to remember that RAM utilization for Connect is most directly tied to data being processed and loaded in the application. A static R Markdown document will tend to consume much less RAM than a Shiny application which is loading data into RAM for processing while being run. A rough guideline for sizing RAM is the following:

Connect RAM rule-of-thumb: (250 MB to 2 GB RAM) X number of concurrently open applications

The best way to determine how much RAM your Connect server requires is to profile the applications that you intend to deploy there.

Disk requirements

Connect uses disk space to host the built content caches of applications and reports that have been deployed to it, as well as for the on-disk SQLite database and other system related information. Thus, disk utilization can vary quite a bit depending on the number of deployed applications and the amount of data that accompanies each application. Additionally, when you publish updates to a piece of content, Connect will retain the old versions. The amount of retention is configurable per the Applications.BundleRetentionLimit.

In summary, the main utilization of disk space on Connect is for:

• Built content caches (both current and historic)
• Installed code for the Python, R, and Quarto implementations used by content

Given variability in content and how often it is published, it is difficult to predict a minimum disk size that is adequate for all teams. For that reason, we recommend no less than 100 GB of disk on the Connect server.

Connect Disk rule-of-thumb: 100 GB, minimum.

Stability of workflows

A team with long-established workflows is likely to have a stable set of OS system dependencies. On the other hand, a team that is rapidly iterating on new workflows or evolving the type of content they publish may require more frequent updates to system dependencies. Variable dependencies may lend toward an architecture that runs content external from the Connect host.

Expectation for uptime

Availability, or uptime, of the service informs architecture decisions and affects the buffer that you build in. It can also determine whether employing several nodes is preferable (i.e., if a piece of content can occupy all the resources on a given machine, other content can still utilize another machine).

Connect architectures

When you have a clear picture of your team’s use case and needs, you can start evaluating the best architecture for your team’s Connect deployment.

A single Posit Connect server is how many teams get started. This architecture is the simplest, without any requirements of external shared storage. If you do not require high availability, just increasing the server size of a single Connect server and scaling vertically is a great scaling strategy.

Below we show a matrix that provides a starting framework for thinking about which architecture best fits your needs. It is very likely that your organization has additional criteria that are critical to making this decision. For example, you may have specific software deployment patterns that you need to follow, like always deploying apps in a container.

In general, we recommend selecting the simplest possible architecture that meets your current and near-term needs, then growing the complexity and scale as needed.

	Single Server	Load-Balanced Cluster	Kubernetes
Workload size	small to medium	medium to large	large
Can support High Availability	no	yes	yes
Well-suited for variable workflows and/or scaling workloads	no	no	yes
Relevant admin skill required	Linux system administration	Linux system administration	Linux system administration Familiarity with Docker, Kubernetes, Helm