Generic Architectures for Posit Connect

The architectures below represent general architectures for Posit Connect, providing a mental model for different deployment options and the requirements to support each variation.

Specific reference architectures organized by target environment are also detailed within this chapter of the Administration Guide, discoverable using the left navigation pane.

Target environments

Posit Connect can be deployed on-premises or within a cloud environment.

Connect on a Single Server

In this configuration, Connect is installed on a single Linux server and enables:

  • Multiple publishers and viewers to access Connect via a web browser

Generic architecture

The example diagram below shows four sample content types deployed to Connect. The content data bundles are stored on the Linux server, and the content processes run on the Linux server.

Linux Server

User

User

User

Browser

Browser

Browser

Connect

Quarto

FastAPI

Shiny App

Streamlit App

Connect as a load-balanced cluster

Enhanced Advanced

In this configuration, Connect is installed on two or more Linux servers and enables:

  • Multiple publishers and viewers to access Connect via a web browser
  • Load balancing to provide additional computational resources for applications and reports
  • High availability to provide redundancy

Requirements

  • Application data must be stored on an external shared file server (typically an NFS server)
  • Application metadata must be stored on an external PostgreSQL database server

Generic architecture

The example diagram below shows sample content types deployed to Connect. The content data bundles are stored on Shared Storage, metadata is stored in a Postgres database. The content processes run on the Linux servers and are distributed according to the Load Balancer rules.

Linux Server

Connect

Quarto

Plumber API

Streamlit App

Shiny App

Linux Server

Connect

R Markdown

Jupyter Notebook

FastAPI

Dash App

User

User

User

Browser

Browser

Browser

Load Balancer

Shared Storage

Postgres

Connect on Kubernetes

Advanced

In this configuration, Connect is installed in a Kubernetes cluster using a Posit-maintained Helm chart.

This enables:

  • Multiple publishers and viewers to access Connect via a web browser
  • Replica redundancy for multiple instances of the Connect service Pod
  • Execution of Python, R, and Quarto content in an isolated Kubernetes container external to Connect (instead of a local process)
  • Admins to define and customize the set of base images available for creating content build and execution containers
  • Publishers to target a specific base image for their content, or allow Connect to choose a best fit by comparing the available runtime version components

Requirements

  • Application data must be stored on a shared file server (can be inside or outside Kubernetes)
  • Application metadata must be stored on a PostgreSQL database server (can be inside or outside Kubernetes)

Generic architecture

The example diagram below shows sample content types deployed to Connect. The content data bundles are stored on Shared Storage, metadata is stored in a Postgres database. The content processes run as isolated pods on the Kubernetes cluster using either default or targeted base images.

Kubernetes Cluster

User

User

User

Browser

Browser

Browser

Connect
Launcher

Ingress Controller
nginx/nginx-ingress

Quarto
ghcr.io/example/content-base:r-40-py-3.11

Flask App
ghcr.io/example/content-base:py-3.10

Shiny App
ghcr.io/example/content-base:r-4.4

Dash App
ghcr.io/example/content-base:py-3.11

Postgres

Shared Files

FAQ

See the Architecture FAQs page for more information for the general FAQ.