graph LR u1(User) u2(User) u3(User) b1(Browser) b2(Browser) b3(Browser) connect(Connect) qmd(Quarto) fastapi(FastAPI) shiny(Shiny App) streamlit(Streamlit App) u1---b1 u2---b2 u3---b3 b1---connect b2---connect b3---connect subgraph server[Linux Server] connect---qmd connect---fastapi connect---shiny connect---streamlit end classDef server fill:#FAEEE9,stroke:#ab4d26 classDef product fill:#447099,stroke:#213D4F,color:#F2F2F2 classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F classDef element fill:#C2C2C4,stroke:#213D4F class server server class connect product class qmd,fastapi,shiny,streamlit session class u1,u2,u3,b1,b2,b3 element
Connect Architectures
Using 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
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.
Using Connect as a cluster
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 to support this architecture:
- 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
The example diagram below shows sample content types deployed to Connect. The content data bundles are stored on Shared Storage, metadata is in a Postgres database. The content processes run on the Linux servers and are distributed according to the Load Balancer rules.
flowchart LR u1(User) u2(User) u3(User) b1(Browser) b2(Browser) b3(Browser) lb(Load Balancer) connect1(Connect) connect2(Connect) rmd(R Markdown) jupyter(Jupyter Notebook) qmd(Quarto) plumber(Plumber API) fastapi(FastAPI) shiny(Shiny App) streamlit(Streamlit App) dash(Dash App) nfs(Shared Storage) pg(Postgres) u1---b1 u2---b2 u3---b3 b1---lb b2---lb b3---lb subgraph server1 [Linux Server] direction LR connect1---rmd connect1---jupyter connect1---fastapi connect1---dash end subgraph server2 [Linux Server] direction LR connect2---qmd connect2---plumber connect2---streamlit connect2---shiny end lb---server1 lb---server2 server1-.-nfs server2-.-nfs server1-.-pg server2-.-pg classDef server fill:#FAEEE9,stroke:#ab4d26 classDef product fill:#447099,stroke:#213D4F,color:#F2F2F2 classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F classDef element fill:#C2C2C4,stroke:#213D4F classDef req fill:#72994E,stroke:#1F4F4F class server1,server2 server class connect1,connect2 product class rmd,jupyter,qmd,plumber,fastapi,streamlit,dash,shiny session class u1,u2,u3,b1,b2,b3,lb element class pg,nfs req
Using Connect with Off-host Content Execution
This architecture is GA starting in Posit Connect v2023.05.0. It requires an enterprise license subscription to enable.
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 R, Python, 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 to support this architecture:
- 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)
The example diagram below shows sample content types deployed to Connect. The content data bundles are stored on Shared Storage, metadata is in a Postgres database. The content processes run as isolated pods on the Kubernetes cluster using either default or targeted base images.
flowchart LR u1(User) u2(User) u3(User) b1(Browser) b2(Browser) b3(Browser) connect(Connect <br/> Launcher) ingress(Ingress Controller<br/>nginx/nginx-ingress) qmd(Quarto<br/>ghcr.io/rstudio/content-base:r-40-py-3.8) flask(Flask App<br/>ghcr.io/rstudio/content-base:py-3.8) shiny(Shiny App<br/>ghcr.io/rstudio/content-base:r-4.0) dash(Dash App<br/>ghcr.io/rstudio/content-base:py-3.8) pg(Postgres) nfs(Shared Files) u1---b1 u2---b2 u3---b3 b1---ingress b2---ingress b3---ingress subgraph k8s [Kubernetes Cluster] ingress---connect connect---qmd connect---flask connect---shiny connect---dash end k8s-..-nfs k8s-..-pg classDef server fill:#FAEEE9,stroke:#ab4d26 classDef product fill:#447099,stroke:#213D4F,color:#F2F2F2 classDef session fill:#7494B1,color:#F2F2F2,stroke:#213D4F classDef element fill:#C2C2C4,stroke:#213D4F classDef req fill:#72994E,stroke:#1F4F4F class k8s server class connect product class ingress,qmd,flask,shiny,dash session class u1,u2,u3,b1,b2,b3,lb element class pg,nfs req