Scaling, Capacity, and Observability

If apps hosted on Connect are getting slow, if the sessions are taking a long time to start, and if the support tickets from your users are increasing, it is probably time to evaluate the sizing of your infrastructure.

When to scale

The core question: do you scale the instance, or coach developers toward better practices (right-sized sessions, more efficient code, offloading compute to a database or cluster)? Often the answer is both.

Moving from SQLite to PostgreSQL is a common, high-impact step for growing or high-availability installs. It is also a prerequisite for load balancing in both Posit Connect and Posit Workbench, so it is worth doing before you need it, not after.

Cleanup is capacity management too:

• Connect: bundle and job reaping (Applications.BundleRetentionLimit, Jobs.MaxCompleted).
• Workbench: idle-session suspend and kill (session-timeout-minutes, session-timeout-kill-hours).
• Posit Package Manager: eviction schedules for cached packages.

Scaling pathways

• A bigger instance. The simplest lever, and the first one to consider.
• Off-host or Kubernetes execution: Connect Advanced for Connect; Workbench Launcher on Kubernetes or Slurm for Workbench. Pair Kubernetes with Karpenter for autoscaling.
• Snowflake auto-suspend for Workbench compute and Session Time outs so Workbench stops idle sessions.
• A persistent environment plus managed compute, for workflows that do not fit the patterns above.

See the sizing guides for instance and hardware recommendations:

• Workbench sizing guide
• Connect sizing guide
• Package Manager sizing guide

Observability

Monitoring matters. Make sure you monitor the health of your service. A few options are available depending on what you are looking to monitor:

• Health endpoints (to check that the service is up): /__ping__ (Connect and Package Manager), /health-check (Workbench).
• Prometheus metrics endpoints on each product.
• OpenTelemetry for tracing.

Common options: Posit Chronicle, OpenTelemetry, Datadog, Splunk, and app-layer telemetry (for example, Shiny apps instrumented with OpenTelemetry).

Note

This area is evolving. Treat this page as a starting map, and talk to the Solutions Engineering Team for a plan matched to your workloads.