Scale

Daytona sandboxes are designed to be created and operated at high volume. A single sandbox scales up by resizing its reserved resources, a fleet scales out by running many sandboxes at once, and each sandbox runs multiple processes concurrently.

Unlike request-based execution environments, a sandbox is a long-lived computer: processes are not terminated after a request completes, so running services, open connections, and background workers persist until the sandbox stops.

Scale operates along three dimensions:

Sandbox scaling

Sandbox scaling changes the resources of a single sandbox: vCPU, memory, and disk. Resources are reserved when the sandbox is created and can be changed later by resizing.

Resources are set differently depending on how the sandbox is created:

• From an image: set resources on the create parameters
• From a snapshot: the sandbox inherits the resources defined on the snapshot

Resizing changes the allocation of an existing sandbox. On a running sandbox, CPU and memory can be increased without interruption. Decreasing CPU or memory, or increasing disk, requires the sandbox to be stopped first. Disk can only grow, and GPU allocation cannot be resized. Every allocation must stay within your organization’s per-sandbox limits.

from daytona import CreateSandboxFromImageParams, Daytona, Resources

daytona = Daytona()

# Reserve 2 vCPUs, 4GiB of RAM, and 8GiB of disk for the sandbox

sandbox = daytona.create(
    CreateSandboxFromImageParams(
        image="ubuntu:22.04",
        resources=Resources(cpu=2, memory=4, disk=8),
    )
)

import { Daytona, Image } from '@daytona/sdk'

const daytona = new Daytona()

// Reserve 2 vCPUs, 4GiB of RAM, and 8GiB of disk for the sandbox

const sandbox = await daytona.create({
  image: Image.base('ubuntu:22.04'),
  resources: { cpu: 2, memory: 4, disk: 8 },
})

require 'daytona'

daytona = Daytona::Daytona.new

# Reserve 2 vCPUs, 4GiB of RAM, and 8GiB of disk for the sandbox

sandbox = daytona.create(
  Daytona::CreateSandboxFromImageParams.new(
    image: Daytona::Image.base('ubuntu:22.04'),
    resources: Daytona::Resources.new(
      cpu: 2,
      memory: 4,
      disk: 8
    )
  )
)

package main

import (
  "context"
  "github.com/daytona/clients/sdk-go/pkg/daytona"
  "github.com/daytona/clients/sdk-go/pkg/types"
)

func main() {
  client, _ := daytona.NewClient()
  ctx := context.Background()

// Reserve 2 vCPUs, 4GiB of RAM, and 8GiB of disk for the sandbox
  sandbox, err := client.Create(ctx, types.ImageParams{
    Image: "ubuntu:22.04",
    Resources: &types.Resources{
      CPU:    2,
      Memory: 4,
      Disk:   8,
    },
  })
}

Fleet scaling

Fleet scaling raises the number of sandboxes running at the same time. The unit of scale is the sandbox itself: instead of packing unrelated workloads into one environment, create one sandbox per user, task, or agent.

Sandboxes are isolated from each other, so a fleet scales linearly: each new sandbox adds capacity without contention, and a failure in one sandbox does not affect the others.

The mechanisms differ in what state each new sandbox starts with:

Snapshot fan-out is the default pattern: prepare the environment once, capture it as a snapshot, and create any number of sandboxes from it. Each sandbox starts with the environment intact, with nothing to reinstall. Sandboxes created from a hot snapshot start with processes already running.

Workload concurrency

Workload concurrency runs multiple processes inside a single sandbox. A single sandbox can run an API server, a database, and background workers side by side: all processes share the sandbox’s filesystem and network, and exposed ports are reachable through previews.

A sandbox runs concurrent processes through sessions. Each session is an independent shell with its own state: working directory, environment variables, and command history.

Commands within a session run sequentially, so parallelism comes from running multiple sessions. Commands started with run_async return immediately and run in the background, and PTY sessions add interactive terminals.

Capacity and throughput

Fleet size and creation rate operate within your organization’s limits. Both are tier-based and raised by verification steps or by contacting support.

To scale beyond the shared compute pool, bring your own compute (BYOC) attaches your own runner nodes in custom regions, which have no concurrent resource usage limits.

Reclaiming capacity

The compute pool is shared by running sandboxes only: stopped, paused, and archived sandboxes free their reserved CPU and memory back to the pool. A fleet can therefore be much larger than the pool, as long as the concurrently running subset fits.

Reclamation runs automatically. Ephemeral sandboxes delete themselves on stop, and the auto-stop, auto-pause, and auto-delete intervals reclaim capacity from idle sandboxes without manual intervention.