Compute overview
Every deploy gets its CPU and memory from one of two compute models: shared compute, pooled capacity you pay for per second of what you request, or isolated compute, dedicated nodes leased in a fixed size and billed per node.
Two compute models#
You choose the compute model with the Tenancy setting. In the dashboard it has these options:
- Shared
- Shared compute. Your replicas run on pooled, multi-tenant nodes alongside other organisations' workloads, separated by container boundaries. This is the default.
- Dedicated
- Isolated compute. Your replicas run on a dedicated node, a whole machine of a fixed Machine type that only your workloads use.
- Inherit
- Only on deploys. The deploy uses its environment's tenancy, and its machine type too if the environment is dedicated.
"Isolated compute" and "dedicated nodes" are one concept. Isolated compute is the model, and a dedicated node is the machine it runs on. The dashboard labels the option Dedicated, and the Nodes page lists the dedicated nodes your workloads are on.
Where tenancy is set#
- On the environment. Projects→Add environment or Edit on an existing environment. Choose Shared or Isolated. For Isolated, also pick a Machine type. Deploys that inherit run on it.
- On the deploy. Deployments→New deploy or Edit. Tenancy defaults to Inherit. Choose Shared or Dedicated to override the environment for that one deploy. A dedicated deploy pins its own machine type.
You aren't locked in. You can change an environment's tenancy later, or mix models, for example shared for staging and dedicated for production.
Comparison#
| Shared compute | Isolated compute | |
|---|---|---|
| Infrastructure model | Pooled, multi-tenant nodes. Workloads are isolated by container boundaries. | A dedicated node of a fixed machine type, used only by your organisation's workloads. |
| Billing model | Per second, on the CPU and memory each running replica requests. | Per second, for each whole node while it is leased, however much of it you use. |
| Capacity planning | None. Request CPU and memory per replica, from 0.125 to 4 vCPU and 256 MiB to 8 GiB, with 1–4 GiB of memory per vCPU. | Pick a machine type. Requests are capped to what that machine can fit. When workloads need more than a node has, another node is leased and released when no longer needed. |
| Isolation | Container boundaries on shared machines. | No other tenants on the node. |
| Scale-to-zero | Described as scaling to zero when idle. Stopping a workload stops its billing. | The node is billed while leased. Removing everything from it stops billing. |
| Node metrics | Not available, because a shared node's totals mix tenants. | Available per node from the Nodes page. |
| Typical workloads | Marketing sites, web apps, admin panels, APIs with light or bursty traffic, staging and preview environments, internal tools. | Production APIs and microservices at scale, databases and other stateful services, high-traffic web apps, compliance-sensitive workloads. |
Choosing a model#
Most teams start every environment on shared compute and move specific environments to dedicated nodes as traffic, performance predictability or compliance needs grow. For a side-by-side decision guide, see Shared vs isolated compute.