How to size 3B for the single-server install and for Kubernetes (Helm) clusters. We describe what the machine needs in vCPU, memory, and storage rather than naming specific cloud instance types, since those change often. Any machine that meets the requirements will do.
3B deploys in two shapes, and each has its own sizing:
Single server is the
bootstrap.sh/setup.shinstall used for evaluations. Everything runs on one machine with no high availability, so if the server goes down, so does 3B.Kubernetes (Helm) is how you run 3B in production. Services run as pods you can scale independently.
Warning: 3B is built for amd64 / x86_64 only. Whether you are picking a VM for a single server or instances for Kubernetes node pools, make sure they use Intel or AMD processors. Arm-based instances such as AWS Graviton or OCI Ampere will not run 3B.
Single server
Pick a tier from the recommended sizes based on how hard you will push the evaluation, then choose the equivalent VM for your cloud and attach SSD-backed storage as described below.
Recommended sizes
These are starting points; monitor usage and scale up if you push harder.
Tier | vCPU | RAM | SSD storage | Good for |
Smoke test | 8 | 16 GB | 250 GB | A quick look with little headroom. |
Recommended POC | 8 | 32 GB | 500 GB | The default starting point for most evaluations. |
Heavier POC | 16 | 64 GB | 500 GB – 1 TB | Larger or more concurrent automation workloads. |
Why this much? 3B runs roughly a dozen services plus a Postgres database and per-job secure sandboxes (gVisor) on the same box. RAM is usually the first thing to run short; the sandboxes and database benefit from fast SSD storage.
Storage
In most clouds, disk is provisioned and billed separately from the VM. Recommendations:
Tier | Recommended SSD volume |
Smoke test | 250 GB |
Recommended POC | 500 GB |
Heavier POC | 500 GB – 1 TB |
Use SSD-backed storage. The database and sandbox runtimes are sensitive to disk latency, so choose your cloud’s general-purpose SSD volume type or better.
Storage holds the database, attachments, the blob store, and cached sandbox images. If you expect large attachments or many automations, lean toward the upper end.
How to choose
Start at the recommended POC tier (8 vCPU / 32 GB / 500 GB). It suits most evaluations.
Move to the heavier tier if you will run many automations at once, work with large data, or notice the server running hot.
Always pick an x86_64 instance (see the warning above) and SSD storage.
These are minimums for a responsive evaluation, not a ceiling. Monitor CPU, memory, and disk, and resize the VM if needed.
Kubernetes (Helm)
The Helm chart’s default values run one replica of every service and request about 4 vCPU and 9 GB of memory in total. The in-cluster Postgres and nginx run without requests on top of that, and the sandbox sidecar can burst to 4 GB, so give the cluster real headroom beyond the requests. Starting points:
What | Recommendation |
Cluster capacity | 8 vCPU and 32 GB of memory available to 3B |
Node size | At least 4 vCPU / 16 GB per node, x86_64 (amd64) only |
Persistent volumes | 50 GB blob store and 10 GB Postgres (the chart defaults), on an SSD-backed StorageClass |
To scale beyond the defaults:
To run more automations at once, raise
worker.replicas. Each worker pod and its sandbox sidecar request about 1.2 vCPU / 2.5 GB, making it the heaviest pod in the chart.To handle more UI and API traffic, raise
api.replicasandpublic.replicas.If you expect large attachments or many automations, raise
blobstore.storage.size. To use an external database instead of the in-cluster Postgres, see the Helm installation guide.