Sizing recommendations

Starting hardware specifications for Posit Workbench, Posit Connect, and Posit Package Manager.
Note

There is no single answer to I have X users, what resources do I need?

Resource needs depend on workload, not headcount. These recommendations are starting points. Monitor from day one and adjust based on observed usage.

This page provides starting hardware specifications for Posit Workbench, Posit Connect, and Posit Package Manager.

For detailed sizing formulas, monitoring guidance, and scaling strategies, see each product’s sizing and capacity planning guide:

Starting configurations

Install each product on a separate, dedicated server. Co-locating products on a single host causes resource contention that is difficult to diagnose.

The following are the most common supported deployment patterns, each with different resource needs and complexity. Choose the one that best matches your current workload and growth plans.

For information on selecting the right deployment architecture, see the reference architectures for each product.

These are recommended starting points for production deployments. If you do not know your workload yet, start here and adjust after 30 days of monitoring.

Product CPU RAM Disk
Workbench 56 cores 104 GB 20 GB + 10 GB per user
Connect 8 cores 32 GB 200 GB
Package Manager 4 cores 16 GB 500 GB

High availability (HA) distributes work across multiple nodes and requires an Enhanced license tier or higher for all three products. Deploy a minimum of 2 nodes per product.

In addition to per-node resources, HA requires:

  • Shared storage: Network File System (NFS) or equivalent
  • PostgreSQL database (see Database sizing below)
  • Load balancer
  • Network Time Protocol (NTP) clock sync across all nodes
Product Per-node cores Per-node RAM
Workbench 56 104 GB
Connect 8 32 GB
Package Manager 8 32 GB

Database sizing

Every HA deployment requires a PostgreSQL database. For all three products, that database requires at least 1 GB of storage. If you run several Posit products against one PostgreSQL instance, give each product its own database.

Workbench

Workbench can run sessions on a Slurm or Kubernetes cluster instead of on the Workbench server itself. In this mode, the Workbench node acts as a reverse proxy, and the number of concurrent connected users (not session compute) drives the node’s resource load. For proxy node sizing and per-user overhead, see the Workbench sizing guide.

For sessions running on a Kubernetes cluster, configure resource requests and limits per session pod using these starting points:

Resource Request (starting point) Limit (starting point)
CPU 1 core 4 cores
Memory 2 GB 8 GB

Adjust based on workload. Data science workloads that load large datasets or train models might need significantly more memory.

Connect

Connect can run content as pods on a Kubernetes cluster. Per-pod sizing minimums are not available. See the Connect Kubernetes reference architecture.

Package Manager

Package Manager can run on Kubernetes for orchestration and scaling. Sizing minimums for Kubernetes are not available. See the Package Manager Kubernetes reference architecture.

What drives resource needs

Each product’s resource needs depend on different factors:

  • Workbench: The number of concurrent IDE sessions, the CPU and memory each session consumes, and whether sessions run locally or off-host (Slurm or Kubernetes).
  • Connect: The mix of content types, the number of concurrent content processes, and runtime process settings.
  • Package Manager: Repository configuration, connectivity mode, package install volume, and binary or source serving.

Monitor from day one

Important

You cannot backfill metrics you did not record. Enable monitoring at install time.

Tracking resource usage from the start helps you identify problems early and adjust your infrastructure before users are affected. Each product has built-in monitoring options:

Posit Chronicle can collect and retain these metrics over time, so you can analyze usage trends for capacity planning. It is available for Workbench and Connect. See the Chronicle setup guides for Workbench and Connect.

When and how to scale

If your monitoring data shows signs of resource pressure, such as sustained CPU usage above 70%, memory usage above 80%, slow session startups, processes killed when the server runs out of memory, or failed package syncs, it is time to scale.

  1. Tune configuration first: many performance issues can be resolved without changing hardware. Adjusting session limits (Workbench), process counts and timeouts (Connect), or repository scope (Package Manager) often frees up enough headroom to restore normal performance.
  2. Scale vertically when tuning is not enough: if configuration changes do not resolve the issue, add more CPU, memory, or disk to the existing server.
  3. Move to HA when a single server hits its limits: if your workload has grown beyond what one node can serve at maximum resource allocation, or your team requires minimal downtime and needs a second server ready to take over if the primary one fails, it is time to distribute across multiple nodes.

For architecture options and scaling paths, see each product’s reference architectures:

Back to top