ComputeShared compute

Shared compute

Shared compute runs your replicas on pooled, multi-tenant nodes. You request an amount of CPU and memory per replica and are billed per second on exactly that, with no nodes to size or pay for. It's the default tenancy for new environments.

How shared compute works#

DevLyft operates a pool of nodes in each location. Replicas from many organisations are scheduled onto them, each isolated from its neighbours by container boundaries. You never see or manage the nodes themselves; you choose how much CPU and memory each replica gets.

A deploy uses shared compute when its Tenancy is Shared, or Inherit in an environment whose tenancy is Shared. Both show as a Shared badge.

Set it on the environment: ProjectsAdd environment, Tenancy: Shared.

Resource allocation#

Resources are set per replica on the build, and can be changed later from the deploy's Adjust resources drawer.

ResourceMinimumMaximumUnits
CPU0.125 (125m)4Cores. Fractions allowed, e.g. 0.25.
Memory256 MB8 GBStored as Mi/Gi, e.g. 512Mi.
Memory per vCPU1 GB4 GBMemory must fall in this band for the CPU you pick.

CPU#

CPU is the processing power your workload can use, in cores. 1 is one full core; 0.1 is a tenth. Small web apps and APIs often run well on 0.25–0.5.

Memory#

Memory is the RAM available to each replica. Workloads may restart if they run out of memory, so size it for your peak, not your average. The Restarts metric and Increase RAM nudge in Metrics help you spot this.

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.”).

Workloads bigger than 4 vCPU or 8 GB belong on isolated compute.

The Adjust resources drawer also offers presets:

PresetCPUMemory
Nano0.125256 MB
Small0.5512 MB
Medium11 GB
Large24 GB

Billing#

  • Per second, on what you request. You pay for the CPU and memory assigned to running replicas, not for measured utilisation.
  • Per replica. Two replicas cost twice one replica, and only for the seconds each one runs.
  • Stops when the workload stops. Take a workload down and billing for it stops immediately; bring it back and billing resumes.
  • No platform fee or reservation. Current rates and a calculator are on the pricing page.
Example
Build request    0.5 CPU · 512 MB per replica
Replicas         3
Billed while up  1.5 CPU · 1.5 GB, per second

Replica scheduling#

DevLyft places each replica on a node in the deploy's location with enough free capacity for its request. You choose the location and replica count; placement onto specific nodes is automatic. If a location has no room yet, placement stays pending and retries on its own.

Scale to zero#

DevLyft describes shared compute as scaling to zero when idle, so an idle workload's own compute cost can reach $0 while other workloads keep running.

Limits#

  • Per-replica CPU and memory must stay within the ranges above.
  • Node-level metrics aren't available on shared nodes, because a shared node's totals mix tenants. You get deploy and pod metrics instead.
  • More in Limits and quotas.

Typical use cases#

  • Marketing sites and landing pages
  • Web apps and admin panels
  • APIs with light or bursty traffic
  • Staging, preview and internal tools

Many teams run staging on shared compute and move production to isolated compute as traffic or compliance needs grow. You can change an environment's tenancy later.