Single Server / Robust

Posit Connect can be configured to run on a single server, utilizing an external database and a networked file system. Use of these external components are optional for a single server implementation, but they present a more robust architecture in line with many organization’s best practices and existing processes. This architecture also offers flexibility to more easily scale Connect horizontally in the future without the complexity of migrating the database and application files.

Architectural overview

This implementation of Posit Connect includes the following components:

Architecture diagram

Architecture Diagram

Nodes

This architecture utilizes a single EC2 instance running Posit Connect. During our performance tests, we used a t3.2xlarge instance running Ubuntu 22.04.

Refer to the Posit Connect Admin Guide for detailed information on system requirements and installation steps.

Database

This architecture utilizes an RDS instance with PostgreSQL running on a db.m5.large instance, provisioned with a minumum of 15 GB of storage and running the latest minor version of PostgreSQL 15 (see supported versions). Both the instance type and the storage can be scaled up for more demanding workloads.

  • The RDS instance should be configured with an empty PostgreSQL database for the Connect metadata.

Shared file storage

This architecture utilizes an encrypted AWS Elastic File System (EFS). EFS does not require initial sizing as it autoscales with usage.

Performance

The Connect team conducts smoke and performance testing on this architecture. During our testing, we published a Python-based FastAPI and a R-based Plumber application (using jumpstart examples included in the product) to Connect, simulating a load of 1500 concurrent users.

Based on our performance test results, the system’s response times meet acceptable criteria for the majority of users. The system was able to handle the load without any issues, and the response times were within acceptable limits.

These tests demonstrate the capability of Connect to manage and serve applications to users. However, it is important to note that the computational footprint of the content used in testing was minimal. For most Connect installations, the majority of computational power is dedicated to the Python and R content that publisher-users deploy, rather than Connect itself. If your team is deploying lightweight apps, APIs, and jobs to Connect, our testing results are likely to be applicable. However, if your team is deploying APIs or apps that involve heavy-duty data processing, machine learning, or other computationally intensive tasks, or if your organization has high-availability requirements, you may want to consider one of our other architectures.