Examples of subjects that might utilize this architecture include medium-sized

tech startups, educational units, or small to mid-sized enterprises.

**Target load**: API: up to 180 RPS

**High Availability**: non-essential for small deployments

|Users| Node capacity| Replicas| GCP| AWS| Azure|

|-------------|---------------------|--------------------------|-----------------|------------|-------------------|

|Up to 1,000| 2 vCPU,8 GBmemory| 1-2 nodes, 1 coderd each|`n1-standard-2`|`m5.large`|`Standard_D2s_v3`|

|vCPU| Memory| Replicas|

|------|--------|----------|

|2|8 GB| 3|

**Footnotes**:

**Notes**:

- "General purpose" virtual machines, such as N4-series in GCP or M8-series in AWS work well.

- If deploying on Kubernetes:

- Set CPU request and limit to`2000m`

- Set Memory request and limit to`8Gi`

- Coderd does not typically benefit from high performance disks like SSDs (unless you are co-locating provisioners).

- For small deployments (ca. 100 users, 10 concurrent workspace builds), it is

acceptable to deploy provisioners on`coderd` nodes.

acceptable to deploy provisioners on`coderd` replicas.

- Coderd instances should be deployed in the same region as the database.

| vCPU| Memory| Replicas|

|------|--------|----------|

| 0.1| 256 MB| 60|

| Users| Node capacity| Replicas| GCP| AWS| Azure|

|-------------|----------------------|-------------------------------|------------------|--------------|-------------------|

| Up to 1,000| 8 vCPU, 32 GB memory| 2 nodes, 30 provisioners each|`t2d-standard-8`|`c5.2xlarge`|`Standard_D8s_v3`|

**Notes**:

- "General purpose" virtual machines, such as N4-series in GCP or M8-series in AWS work well.

- If deploying on Kubernetes:

- Set CPU request and limit to`100m`

- Set Memory request and limit to`256MB`

- If deploying on virtual machines, stack up to 30 provisioners per machine with a cummensurate amount of memory and CPU.

- Provisioners benefit from high performance disks like SSDs.

- For small deployments (ca. 100 users, 10 concurrent workspace builds), it is

acceptable to deploy provisioners on`coderd` nodes.

- If deploying workspaces to multiple clouds or multiple Kubernetes clusters, divide the provisioner replicas among the

clouds or clusters according to expected usage.

- An external provisioner is deployed as Kubernetes pod.

| vCPU| Memory| Replicas|

|------|--------|----------|

| 8| 30 GB| 1|

| Users| Node capacity| Replicas| GCP| AWS| Azure|

|-------------|----------------------|------------------------------|------------------|--------------|-------------------|

| Up to 1,000| 8 vCPU, 32 GB memory| 64 nodes, 16 workspaces each|`t2d-standard-8`|`m5.2xlarge`|`Standard_D8s_v3`|

- "General purpose" virtual machines, such as the M8-series in AWS work well.

- Deploy in the same region as`coderd`

- Assumed that a workspace user needs at minimum 2 GB memory to perform. We

recommend against over-provisioning memory for developer workloads, as this my

lead to OOMKiller invocations.

- Maximum number of Kubernetes workspace pods per node: 256

Workspace sizing depends very heavily on the exact use case, even down to project size and programming language for

development use cases.

The following resource requirements are for the Coder Workspace Agent, which runs alongside your end users work, and as

such should be interpreted as the_bare minimum_ requirements for a Coder workspace.

|-------------|---------------------|----------|---------|--------------------|---------------|-------------------|

|------|--------|

**Footnotes for AWS instance types**:

- For production deployments, we recommend using non-burstable instance types,

such as`m5` or`c5`, instead of burstable instances, such as`t3`.