Coder is deployed onto Kubernetes clusters, and we recommend the following resource allocation minimums to ensure quality performance.
For basic control services, allocate at least 2 CPU cores, 4 GB of RAM, and 20 GB of storage.
For each active developer using Coder, allocate additional resources. The specific amount required per developer varies, though you can use the following to help you estimate:
- Development using a JetBrains IDE: 4 CPU cores, 8 GB of RAM, and 10 GB of storage per developer
- Development using VS Code with an SSH connection to Coder: 1 CPU core and 1 GB of RAM per developer
These estimates can vary based on actual usage within a workspace. We recommend starting with the amount of resources you'd allocate to a local workspace, then iterating as needed.
We also recommend monitoring your usage to determine whether you should change your resource allocation. Accepting a utilization of RAM of around 50% and CPU of around 70% is a good way to balance performance with cost.
We recommend the following throughput:
- Read: 3000 IOPS at 50 MB/s
- Write: 3000 IOPS at 50 MB/s
You must enable the following extensions on your K8 cluster (check whether you
have these extensions enabled by running
kubectl get apiservices):
Use an up-to-date browser to ensure that you can use all of Coder's features. We currently require the following versions or newer:
- Apple Safari 12.1
- Google Chrome 66
- Mozilla Firefox 57
- Microsoft Edge 79
If you're using Remote IDEs, allow pop-ups; Coder launches the Remote IDE in a pop-up window.
Coder requires the use of a persistent volume in your Kubernetes cluster to store workspaces data. More specifically, the persistent volume claim (PVC) requires the block storage type (the PVC is created when you create the workspace to mount the requested block storage).
Additionally, you must enable dynamic volume
so that Coder can mount the PVC to the workspace (if you're using a custom
StorageClass, be sure that it supports DVP. Otherwise, Coder cannot provision
Coder requires a PostgreSQL database to store metadata related to your deployment.
By default, Coder deploys a TimescaleDB internal to your Kubernetes cluster. This is included for evaluation purposes only, and it is not backed up. For production deployments, we recommend using a PostgreSQL database external to your cluster. You can connect Coder to your external database by modifying the Helm chart with information regarding your PostgreSQL instance.
Coder requires, at minimum, PostgreSQL 11 with the
contrib package installed.
Coder uses Kubernetes NetworkPolicies to enforce network segmentation and tenant isolation within your cluster.
Coder's network isolation policy blocks all ingress traffic to workspaces except traffic from the control plane (this ensures that you can audit all traffic). However, the control plane does not specify egress rules; by default, it allows outbound traffic. However, you can still enforce a more specific network policy.
Container network interface (CNI) plugins implement network segmentation and tenant isolation in the Kubernetes cluster. They enforce network boundaries between pods, preventing users from accessing other workspaces.
If your container network interface (CNI) plugin does not support NetworkPolicy enforcement, traffic between workspaces, and other containerized workloads within the same cluster will be permitted to communicate without restriction. Consider testing your container networking after installing Coder to ensure that the behavior is as expected.
If you're not sure which CNI plugin to use, we suggest Calico.
The use of Coder deployments requires a license that's emailed to you.
Deployments using the free trial of Coder:
- Must be able to reach and use an outbound internet connection (at minimum, your deployment must be able to access licensor.coder.com)
- Cannot be deployed in an air-gapped network
- Must use Coder v1.10.0 or later
The above requirements do not apply to potential customers engaged in our evaluation program.