ComputeIsolated compute

Isolated compute

Isolated compute runs your replicas on a dedicated node: a whole machine of a fixed size, leased for your organisation alone. In the dashboard it's the Isolated option on environments and the Dedicated tenancy on deploys and badges. You pay for the node while it's provisioned, however much of it you use.

The dedicated node model#

“Isolated compute” and “dedicated nodes” are the same thing: isolated compute is the tenancy, and a dedicated node is the machine it runs on. No other tenant's workloads share that node, so there are no noisy neighbours and performance stays predictable as traffic grows.

A deploy uses isolated compute when its Tenancy is Dedicated, or Inherit in an environment whose tenancy is Dedicated.

Environment or deployTenancy: DedicatedPick a machine type
→
DevLyftLeases a nodeIn the deploy's location
→
DeployReplicas scheduledOnto your node only

Set up isolated compute#

For a whole environment#

  1. ProjectsAdd environment, or Edit an existing environment.
  2. Under Tenancy, choose Isolated.
  3. Choose a Machine type. “Deploys that inherit this environment run on this machine type.”
  4. Choose Create environment or Save.

For one deploy#

In DeploymentsNew deploy (or Edit), set Tenancy to Dedicated and pick a Machine type. It must be offered by a cluster in the deploy's location.

Node sizes#

The Machine type list is loaded live from DevLyft, so new sizes appear without a dashboard change. Each option shows a name and its capacity, for example Balanced 2 — 2 vCPU · … GiB. Today dedicated nodes come in 2 or 4 vCPU sizes, with larger sizes planned.

API
GET /v1/instance-types
→ {"instance_types": [{"instance_type": "devlyft-amd-balanced-2", "cpu": 2, "memory": "…"}]}

Capacity#

On a dedicated node, a replica's CPU and memory request is capped to what the machine can fit. The Adjust resources drawer uses the machine's capacity as its maximum and says so (“Maximum available for Balanced 2.”), and notes that requests are capped to what the machine can fit.

  • Plan for your replicas' combined requests: three replicas at 1 CPU need 3 CPU of dedicated capacity.
  • When your workloads request more than one node has, DevLyft leases another node automatically, and releases it when it's no longer needed.

Scheduling workloads onto the node#

Replicas of deploys using the same dedicated machine type in the same location are scheduled onto your organisation's nodes of that type. You don't pick a node by name; you pick the machine type and location, and DevLyft places replicas where there's room.

Provisioning and deprovisioning#

  • Provisioning is self-service: creating a dedicated deploy, or a deploy inheriting a dedicated environment, leases the node it needs.
  • Deprovisioning happens when nothing needs the node any more. Remove everything running on it and the node is released.

Billing#

  • Per node, not per request. You pay one fixed price per node, the same however much you deploy to it.
  • Per second while leased. Each node is billed per second while it's provisioned, regardless of utilisation.
  • Stops when released. Deprovision everything on the node and billing for it stops; provision again and it resumes.

Current node prices are on the pricing page under dedicated compute.

Node health#

Your dedicated nodes appear on Nodes with their location, architecture, CPU, memory, IP and a Status of Running (ready and schedulable) or Stopped. Dedicated nodes also have View metrics, which shows node-level totals; shared nodes don't. See Node health.

Failure and replacement#

Custom-domain hostnames keep working when DevLyft replaces the machine underneath a deploy, because the CNAME target isn't tied to a node.

Location availability#

A machine type must be offered by a cluster in the deploy's location. If the type you want isn't available where you deploy, pick another type or another location.

Typical use cases#

  • Production APIs and microservices at scale
  • High-traffic web apps
  • Compliance-sensitive workloads