CPU and memory

Resource requests#

A build carries two resource requests: CPU and Memory. Every replica of a deploy that runs that build reserves exactly that amount. The Deployments table shows it in the Resources column, marked /replica when the deploy has more than one replica.

Requests are per replica, so a deploy's total is the request multiplied by its replicas. Three replicas at 0.5 CPU · 512 MB reserve 1.5 CPU · 1.5 GB in total.

Units#

CPU

Measured in vCPU cores, shown as 0.5 CPU. The API accepts decimal cores ("0.5", "2") or millicores ("500m"). The dashboard always writes decimal cores.

Memory

Binary units, shown as 512 MB or 2 GB. The API uses Kubernetes quantities such as "512Mi" or "2Gi". The dashboard writes Mi, or Gi for whole gibibytes.

{
  "cpu_request": "0.5",
  "memory_request": "512Mi"
}

Bounds#

Shared instances also need 1–4 GB of memory per vCPU, so the memory you can pick depends on the CPU: 0.5 vCPU allows 512 MB–2 GB, 2 vCPU allows 2–8 GB. When you change CPU, the dashboard moves memory into the allowed range and tells you (for example “Memory raised to 1 GB: shared instances need 1–4 GB per vCPU.”).

The 0.125 vCPU / 256 MiB floor applies to every build, whatever its tenancy. Dedicated deploys have no per-vCPU memory rule; their ceiling is the machine's capacity. Bigger workloads than 4 vCPU / 8 GiB belong on a dedicated node.

A build isn't tied to an environment, so the New build form always offers the shared range. The Adjust resources drawer on a dedicated deploy caps the controls to that deploy's machine type and shows Maximum available for <machine> at the top of the range.

Setting values#

CPU and memory use a stepper control. − and + move through round values (CPU 0.125, 0.25, 0.5, 1, 2, 4… and memory 256 MB, 512 MB, 1 GB, 2 GB…). Click the value to type an exact amount. Anything out of range is clamped to the nearest bound. At an edge the control explains why, for example Shared instances top out at 4 CPU. Use a dedicated node for bigger workloads. A build or deploy saved before these rules that falls outside them is shown adjusted to the nearest valid size, with a note, until you save or apply it.

Only Admins and Managers can change resources. For other roles the controls show Only managers and admins can change resources.

Adjust resources#

To resize a running deploy, open Deployments→Adjust resources (the CPU icon in the row, or click the value in the Resources column).

1. Pick new values

   Use the CPU and Memory steppers, or a Quick presets option: Nano (0.125 CPU · 256 MB), Small (0.5 CPU · 512 MB), Medium (1 CPU · 1 GB) or Large (2 CPU · 4 GB). Presets are clamped to what the deploy's tenancy supports. The panel shows the value Per replica and the total across replicas.

2. Confirm the update

   Choose Update resources. The confirmation explains that DevLyft will create an updated build configuration and redeploy the workload, and that the workload may restart while the new allocation is applied.

3. DevLyft creates a new build and repoints the deploy

   A copy of the current build is created with the new requests and a versioned name (api → api-v2, api-v2 → api-v3). The deploy is then updated to run it. The original build is kept, so you can switch back from Edit.

When a workload needs more#

A workload that runs out of memory may be restarted. In View metrics, the CPU and Memory charts show usage against the current allocation, with Increase CPU and Increase RAM shortcuts that open the resources drawer already one step up. A climbing Restarts count (three or more) is flagged, but the dashboard doesn't claim to know the cause.

Billing#

On shared compute you're billed per second on the requested CPU and memory of every running replica. On dedicated nodes you're billed per node, and requests decide how many replicas fit on each node. See Usage and billing.