Sizing & scaling
How big a server you need, and how the stack grows.
The Proliferate server is deliberately light: agent sessions run either on your users' own machines (local workspaces) or as sandboxes on E2B, the cloud sandbox provider, so your server handles API traffic and the database, not workloads. A small host goes a long way.
What runs on the host
The standard Docker Compose stack is four services on one host:
- caddy: HTTPS termination with automatic certificates
- db: Postgres 16, the only stateful service
- migrate: a one-shot migration container (runs during bootstrap and updates, then exits)
- api: the Proliferate server itself
If you turn on the model gateway,
two more services join the stack: litellm (the proxy itself) and
litellm-db (its own small Postgres instance for keys and spend records).
Both are lightweight and idle unless agents are actively calling models
through the gateway; they do not change the sizing table below. If you point
the gateway at a LiteLLM instance you run elsewhere instead, size that host
independently.
Sizing
| Deployment | Users | Recommended host | Example instance |
|---|---|---|---|
| Evaluation / trial | 1-20 | 2 vCPU / 2 GB | AWS t4g.small, GCP e2-small |
| Starter team | 1-20 | 2 vCPU / 4 GB | AWS t4g.medium |
| Mid-size org | 20-200 | 2 vCPU / 4 GB | AWS t4g.medium |
The 2 vCPU / 2 GB shapes are what the one-click cloud templates default to and are fine for evaluation and small teams. The same 2 vCPU / 4 GB baseline covers a mid-size organization because the heavy lifting (agent sessions, builds, checkouts) happens on user machines or in sandboxes, never on the server.
Disk. Postgres stores metadata (organizations, users, sessions, invites),
not repository contents or build artifacts, so it grows slowly. The AWS
one-click template ships a 20 GB root volume, which is fine to start; plan to
resize it (or start at 40 GB+) if you expect years of uptime, since the main
thing that grows over time is old Docker images accumulating after updates.
docker image prune reclaims those.
What actually scales with headcount
Session capacity, not the server:
- Local workspaces run on each user's own machine and add no server load beyond API calls.
- Cloud sandboxes run in your own E2B team. As usage grows, concurrent sandbox count and cost grow on the E2B side (their plan sets your concurrency limits); the Proliferate server only orchestrates them.
- The server itself sees API requests and database writes, which grow slowly and roughly linearly with active users.
What is not on the server yet
Two honest scoping notes for capacity planning:
- No worker tier. Self-hosted v1 has no background worker service, so automations and background jobs are not available on self-hosted deployments yet. When the worker tier ships, it will come with its own sizing guidance.
- No web app. Self-hosted v1 is desktop-only, so the server serves an API, not a web frontend. There is no page-serving load to size for.
When to resize
You rarely will, but the signals are ordinary ones: sustained CPU saturation
on the api container, Postgres memory pressure, or the disk filling up.
Because all state lives in named Docker volumes, moving to a bigger host is a
snapshot-and-restore of the volumes (see
Data retention & backups),
not a reinstall.
Scale-out
Running the server across multiple instances (for deployments beyond 200 users) is on the roadmap, gated on the worker tier. If you're planning a deployment at that scale today, get in touch.