Burstable vs Dedicated

Every sandbox is created in one of two resource modes, selected by the mode parameter. The modes answer a question every multi-tenant platform faces: should a sandbox be limited to exactly what it asked for, or should it be able to use idle capacity when available? Daytona lets you choose per sandbox — and defaults to the more flexible option.

Resource mode is one of three independent create-time axes — alongside durability and pricing tier. See Choosing sandbox options for how they combine.

The two modes

Burstable (the default) treats your resource request as a guaranteed floor, not a ceiling. The sandbox boots at the platform's burst-cap shape — 16 vCPU, 32 GiB RAM, 256 GiB disk — and can use any of that capacity whenever it is idle on the host. You are guaranteed at least what you asked for; everything above it is opportunistic. This means a sandbox with a cpu: 0.5 guarantee can still finish a pip install using many cores if the host has headroom.

Dedicated shapes the sandbox exactly as requested: the VM boots with ceil(cpu) vCPUs and precisely the memory and disk you specified. There is no bursting — performance is fully predictable and independent of what else runs on the host.

Any mode value other than "burstable" or "dedicated" is rejected with 400.

How burstable enforcement works

Burstable is not oversubscription roulette; the guarantees are real. Three rules define the behavior you will observe:

• Guarantees are admission-reserved. The platform reserves capacity for every sandbox's guarantee at placement time and never lets the sum of guarantees on a host exceed its capacity. Your floor is always physically available.
• Contention is fair-share. When multiple sandboxes on a host want more CPU than exists, each receives at least its guaranteed share, with the excess divided proportionally to the guarantees (fair-share weighting). A sandbox with a 2-core guarantee gets twice the contended share of one with a 1-core guarantee.
• Guarantees are capped at the burst shape. A burstable request whose guarantee exceeds the platform caps (16 vCPU / 32 GiB / 256 GiB) is rejected with 400. If you need a bigger guarantee than the caps allow, use dedicated.

The practical upshot: with burstable you pay for a small guarantee and usually get much more; the guarantee is your worst case, not your typical case.

Choosing a mode

A useful rule of thumb: if you would be annoyed that two runs of the same job took different amounts of time, use dedicated. Otherwise burstable is almost always the better deal.

Examples

A burstable sandbox with a fractional-CPU guarantee, and a dedicated sandbox shaped at exactly 4 vCPUs:

from rlp import Daytona, CreateSandboxFromImageParams, Resources
 
daytona = Daytona()
 
# Burstable (default): guaranteed 0.5 cores, can burst into idle capacity.
burstable = daytona.create(CreateSandboxFromImageParams(
    image="python:3.12-slim",
    resources=Resources(cpu=0.5),
))
 
# Dedicated: exactly 4 vCPUs, fully predictable.
dedicated = daytona.create(CreateSandboxFromImageParams(
    image="python:3.12-slim",
    mode="dedicated",
    resources=Resources(cpu=4),
))

import { Daytona } from '@rlp/sdk'
 
const daytona = new Daytona()
 
// Burstable (default): guaranteed 0.5 cores, can burst into idle capacity.
const burstable = await daytona.create({
  image: 'python:3.12-slim',
  resources: { cpu: 0.5 },
})
 
// Dedicated: exactly 4 vCPUs, fully predictable.
const dedicated = await daytona.create({
  image: 'python:3.12-slim',
  mode: 'dedicated',
  resources: { cpu: 4 },
})

# Burstable with a fractional guarantee and explicit memory/disk floors
curl -X POST https://api.rl.trydaytona.com/vms \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"image": "python:3.12-slim", "cpu": 0.5, "mem_mib": 2048}'
 
# Dedicated, shaped exactly as requested
curl -X POST https://api.rl.trydaytona.com/vms \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"image": "python:3.12-slim", "mode": "dedicated", "cpu": 4, "mem_mib": 8192}'

Note: In the SDKs only resources.cpu is applied by the API today; set memory and disk via the REST fields mem_mib / scratch_mib. See the parameter reference for defaults, minimum clamps, and the burstable caps.

Billing interaction

Billing is based on your guarantee — the floor you reserve — so a burstable sandbox with a small guarantee is billed for that small guarantee even when it bursts. This is what makes burstable the economical default for spiky workloads: your cost tracks the reservation, not the peaks. For details on charges and credits, see Spending, and for a further discount on interruption-tolerant work, see Spot sandboxes.