Sandboxes

Daytona provides full composable computers — sandboxes — for AI agents. Sandboxes are isolated runtime environments you can manage programmatically to run code. Each sandbox runs in isolation, giving it a dedicated kernel, filesystem, network stack, and allocated vCPU, RAM, and disk. Agents and developers get access to a full composable computer where they can install packages, run servers, compile code, and manage processes.

Sandboxes run as Linux containers by default. Daytona also provides VM sandboxes with a dedicated Linux VM or Windows operating system, and GPU sandboxes with NVIDIA GPU acceleration for model inference, fine-tuning, and CUDA-accelerated compute.

Create sandboxes

Create a sandbox.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Click Create

from daytona import Daytona

daytona = Daytona()
sandbox = daytona.create()

Snapshots

Create a sandbox from a default snapshot.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Select a snapshot
4. Click Create

from daytona import Daytona, CreateSandboxFromSnapshotParams

daytona = Daytona()
sandbox = daytona.create(
    CreateSandboxFromSnapshotParams(
        snapshot="daytona-small",
    )
)

Resources

Create a sandbox with custom resources.

Sandboxes have 1 vCPU, 1GB RAM, and 3GiB disk by default. Organizations get a maximum sandbox resource limit of 4 vCPUs, 8GB RAM, and 10GB disk.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Enter a base Image (e.g. ubuntu:22.04) as the source for the sandbox
4. Set Resources (cpu, memory, disk) to the values within your organization's limits
5. Click Create

from daytona import Daytona, CreateSandboxFromImageParams, Image, Resources

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

Languages

Create a sandbox with a specific language runtime.

Daytona sandboxes support Python, TypeScript, and JavaScript programming language runtimes for direct code execution inside the sandbox. The language parameter controls which programming language runtime is used for the sandbox. If omitted, it defaults to python.

• python
• typescript
• javascript

from daytona import Daytona, CreateSandboxFromSnapshotParams

daytona = Daytona()

# Python runtime (default)
sandbox = daytona.create(CreateSandboxFromSnapshotParams(language="python"))
response = sandbox.process.code_run('print("Hello from Python")')
print(response.result)

# TypeScript runtime
sandbox = daytona.create(CreateSandboxFromSnapshotParams(language="typescript"))
response = sandbox.process.code_run('console.log("Hello from TypeScript")')
print(response.result)

# JavaScript runtime
sandbox = daytona.create(CreateSandboxFromSnapshotParams(language="javascript"))
response = sandbox.process.code_run('console.log("Hello from JavaScript")')
print(response.result)

Environment variables

Create a sandbox with environment variables. Use secrets for API keys, tokens, and passwords.

from daytona import Daytona, CreateSandboxFromSnapshotParams

daytona = Daytona()
sandbox = daytona.create(CreateSandboxFromSnapshotParams(
    env_vars={"DEBUG": "true", "LOG_LEVEL": "info"},
))

Regions

Create a sandbox in a specific region.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Set Region to the target region you want to create the sandbox in
4. Click Create

from daytona import Daytona, DaytonaConfig

daytona = Daytona(DaytonaConfig(target="us"))
sandbox = daytona.create()

VM sandboxes

Daytona provides VM sandboxes for workloads that require a full virtual machine with a dedicated Linux VM or Windows operating system.

VM sandboxes are distinct from container sandboxes and support VM-only capabilities:

• Fork sandboxes
• Pause and resume sandboxes
• Create snapshot from sandbox

from daytona import Daytona, CreateSandboxFromSnapshotParams

daytona = Daytona()
sandbox = daytona.create(CreateSandboxFromSnapshotParams(snapshot="daytona-vm-small"))

GPU sandboxes

Daytona provides GPU sandboxes for workloads that require NVIDIA GPU acceleration, such as model inference, fine-tuning, and CUDA-accelerated compute. GPU sandboxes are ephemeral and support up to 16 vCPUs, 192GB RAM, and 512GB disk. Supported GPU types:

• NVIDIA H100
• NVIDIA H200
• NVIDIA RTX Pro 6000
• NVIDIA RTX 4090
• NVIDIA RTX 5090

GPU sandboxes are on-demand. See spot GPU sandboxes for preemptible GPU capacity.

Due to possible events of temporary GPU scarcity, the target/region requested for GPU sandboxes is ignored by default. If you need access to a specific geographical location, contact us at support@daytona.io.

from daytona import Daytona, CreateSandboxFromSnapshotParams

daytona = Daytona()
sandbox = daytona.create(
    CreateSandboxFromSnapshotParams(
        snapshot="daytona-gpu",
        auto_delete_interval=0,
    ),
)

Spot GPU sandboxes

Spot GPU sandboxes are preemptible and run on GPU capacity that is not being used by reserved (on-demand) sandboxes. A spot GPU sandbox can be terminated at any time without notice when an on-demand GPU sandbox needs the capacity. Daytona does not send a preemption warning or a dedicated preemption webhook. Design workloads to tolerate immediate interruption.

When a spot GPU sandbox is destroyed, normal sandbox lifecycle state updates still apply. Daytona records when the preemption occurred with a spotEvictedAt timestamp to identify sandboxes destroyed by spot GPU preemption. Sandboxes destroyed by spot GPU preemption remain retrievable for 24 hours.

Spot GPU sandboxes do not count against the organization's GPU quota. Available GPU capacity is the only limit. If no spot GPU is available, create fails immediately.

from daytona import Daytona, CreateSandboxFromSnapshotParams

daytona = Daytona()
sandbox = daytona.create(
    CreateSandboxFromSnapshotParams(
        snapshot="daytona-gpu",
        auto_delete_interval=0,
        spot=True,
    ),
)

Ephemeral sandboxes

Create an ephemeral sandbox. Ephemeral sandboxes are automatically deleted when stopped.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Set Ephemeral or set the auto-delete interval to 0
4. Click Create

from daytona import Daytona, CreateSandboxFromSnapshotParams

daytona = Daytona()
params = CreateSandboxFromSnapshotParams(
    ephemeral=True,
    auto_stop_interval=5,
)
sandbox = daytona.create(params)

Linked sandboxes

Create a linked sandbox. Linked sandboxes attach ephemeral child sandboxes to a parent. Daytona schedules each child on the same runner as the parent and joins them into a shared link network so the group can communicate over local connections.

• Lifecycle

  Linked sandboxes are always ephemeral and cannot be persisted or resumed after stop. The auto-delete interval must be exactly 0 on create; this is enforced, not a default. The auto-stop interval sets the idle period in minutes after which the child sandbox stops. Once stopped, linked children are auto-deleted. Deleting the parent deletes all of its linked children (cascade). One parent may have many linked children (1:N).

• Networking

  Linked sandboxes share an internal link network. Connections work in both directions: the parent can reach each child and each child can reach the parent. Every sandbox on the link network is registered under its sandbox name and ID as DNS aliases, so either works as the host. For example: telnet LINKED_SANDBOX_ID 5555 from the parent reaches port 5555 on the linked child sandbox.

1. Create a parent sandbox
2. Create one or more child sandboxes that reference the parent's sandbox ID.

This records the relationship on the child sandbox as the linked sandbox ID. Omitting the linked sandbox parameter yields an unlinked sandbox.

from daytona import CreateSandboxFromSnapshotParams, Daytona

daytona = Daytona()

parent = daytona.create()

child = daytona.create(
    CreateSandboxFromSnapshotParams(
        linked_sandbox=parent.id,
        ephemeral=True,
    )
)

# The link network registers each sandbox under its name as a DNS alias
response = child.process.exec(f"curl http://{parent.name}:3000/")

Start sandboxes

Start a sandbox.

1. Go to Daytona Sandboxes ↗
2. Click the start icon (▶) next to the sandbox you want to start

sandbox.start()

Get sandbox

Get a sandbox by ID or name.

sandbox = daytona.get("my-sandbox-id-or-name")

List sandboxes

List sandboxes.

for sandbox in daytona.list():
    print(sandbox.id)

Stop sandboxes

Stop a sandbox. The sandbox moves to the stopped state when shutdown completes. While a stop is in progress, the sandbox is in the stopping state and does not accept new requests.

sandbox.stop()

Archive sandboxes

Archive a sandbox.

sandbox.archive()

Pause / resume sandboxes

Pause and resume a sandbox.

Recover sandboxes

Recover a sandbox.

1. Ensure the sandbox is in error state
2. Check that the sandbox is recoverable
3. Resolve any underlying issue that requires user intervention
4. Recover the sandbox and wait for it to be ready

# Check if the sandbox is recoverable
if sandbox.recoverable:
    sandbox.recover()

sandbox.recover()

Resize sandboxes

Resizing updates the sandbox resource allocation (cpu, memory, and disk) for that sandbox. CPU and memory control compute capacity for running workloads, while disk controls persistent filesystem capacity.

On a running sandbox, you can increase CPU and memory without interruption. To decrease CPU or memory, or to increase disk capacity, stop the sandbox first. Disk size can only be increased and cannot be decreased.

1. Choose the new CPU, memory, and disk values within your organization's limits
2. Ensure the sandbox is stopped if you need to decrease CPU or memory, or increase disk
3. Resize the sandbox with the new resource values
4. Start the sandbox

# Resize a started sandbox (CPU and memory can be increased)
sandbox.resize(Resources(cpu=2, memory=4))

# Resize a stopped sandbox (CPU and memory can change, disk can only increase)
sandbox.stop()
sandbox.resize(Resources(cpu=4, memory=8, disk=20))
sandbox.start()

To verify CPU and memory limits inside the sandbox after resizing, read cgroup values directly. Tools such as nproc, free, top, htop, /proc/cpuinfo, and /proc/meminfo read host-level values and do not reflect sandbox resource limits.

cat /sys/fs/cgroup/cpu.max      # "<quota> <period>" (cores = quota / period)
cat /sys/fs/cgroup/memory.max   # bytes
df -h /                         # disk

Label sandboxes

Set sandbox labels.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Click Add Labels
4. Enter the labels in key-value pairs

sandbox.set_labels({
    "team": "platform",
    "env": "staging",
})

Delete sandboxes

Delete a sandbox.

By default delete is fire-and-forget: it returns as soon as the API accepts the deletion request, without waiting for the sandbox to be destroyed. Pass the wait flag to block until the sandbox reaches the destroyed state.

1. Go to Daytona Sandboxes ↗
2. Click Delete next to the sandbox you want to delete.

sandbox.delete()

# Block until the sandbox is destroyed
sandbox.delete(timeout=60, wait=True)

Create snapshot from sandbox

Create a snapshot from a running or stopped sandbox.

sandbox._experimental_create_snapshot("my-snapshot")

Fork sandboxes

Fork a sandbox.

Sandbox lifecycle

Every sandbox moves through a lifecycle. A sandbox can have several different states. Each state reflects the status of your sandbox. A sandbox transitions between states in response to user actions, or through automated lifecycle management based on inactivity intervals. Available lifecycle features depend on the sandbox class.

The diagram demonstrates the states and possible transitions between them.

State transitions

A sandbox can transition between states in response to various actions. The following table lists the initial state, target state, and trigger for the transition.

Automated lifecycle management

Sandboxes can be managed automatically based on user-defined deadlines. Inactivity and stopped-time intervals stop, pause, archive, or delete a sandbox when it is idle. Wall-clock TTL destroys a sandbox after a fixed deadline regardless of state.

• Auto-stop interval: stop a sandbox after a specified period of inactivity
• Auto-pause interval: pause a VM sandbox after a specified period of inactivity
• Auto-archive interval: archive a sandbox after a specified period of inactivity
• Auto-delete interval: delete a sandbox after a specified period of inactivity
• Wall-clock TTL: destroy a sandbox after a fixed wall-clock deadline, regardless of state
• Update sandbox last activity: signal activity to reset the inactivity timer
• Running indefinitely: run a sandbox indefinitely

Auto-stop interval

The auto-stop interval sets the amount of time after which a running sandbox is automatically stopped. The auto-stop triggers even if there are internal processes running in the sandbox.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Set auto-stop interval to the desired value in minutes
   • 0: disables the auto-stop functionality, allowing the sandbox to run indefinitely
   • if not set, the default interval of 15 minutes is used
4. Click Create

sandbox = daytona.create(CreateSandboxFromSnapshotParams(
    snapshot="my-snapshot",
    # Disables the auto-stop feature - default is 15 minutes
    auto_stop_interval=0,
))

The system differentiates between "internal processes" and "active user interaction". Merely having a script or background task running is not sufficient to keep the sandbox alive.

What resets the timer

The inactivity timer resets only for specific external interactions:

• Updates to sandbox lifecycle states
• Network requests through sandbox previews
• Active SSH connections
• API requests to the Daytona Toolbox SDK

What does not reset the timer

The following do not reset the timer:

• SDK requests that are not toolbox actions
• Background scripts (e.g., npm run dev run as a fire-and-forget command)
• Long-running tasks without external interaction
• Processes that don't involve active monitoring

If you run a long-running task like LLM inference that takes more than 15 minutes to complete without any external interaction, the sandbox may auto-stop mid-process because the process itself doesn't count as "activity", therefore the timer is not reset.

Auto-pause interval

The auto-pause interval sets the amount of time after which an idle VM sandbox is automatically paused. Auto-pause applies only to VM sandboxes and is mutually exclusive with the auto-stop interval: at most one of the two intervals may be non-zero. Ephemeral sandboxes cannot have auto-pause enabled.

The interval is set in minutes:

• 0: disables the auto-pause functionality
• if neither auto-pause nor auto-stop is set, non-ephemeral sandbox classes that support pausing default to an auto-pause interval of 60 minutes with auto-stop disabled

The sandbox pauses after no new events occur for the specified interval. Events include sandbox state changes and interactions with the sandbox through the SDK. Interactions through sandbox previews do not reset the timer.

Auto-archive interval

The auto-archive interval sets the amount of time after which a continuously stopped sandbox is automatically archived. Auto-archive applies only to container sandboxes. VM sandboxes are excluded.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Set auto-archive interval to the desired value in minutes
   • 0: the maximum interval of 30 days is used
   • if not set, the default interval of 7 days is used
4. Click Create

sandbox = daytona.create(CreateSandboxFromSnapshotParams(
    snapshot="my-snapshot",
    # Auto-archive after a sandbox has been stopped for 1 hour
    auto_archive_interval=60,
))

Auto-delete interval

The auto-delete interval sets the amount of time after which a continuously stopped sandbox is automatically deleted.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Set auto-delete to the desired value in minutes
   • -1: disables the auto-delete functionality
   • 0: the sandbox is deleted immediately after it is stopped
   • if not set, the sandbox is not deleted automatically
4. Click Create

sandbox = daytona.create(CreateSandboxFromSnapshotParams(
    snapshot="my-snapshot",
    # Auto-delete after a sandbox has been stopped for 1 hour
    auto_delete_interval=60,
))

# Delete the sandbox immediately after it has been stopped
sandbox.set_auto_delete_interval(0)

# Disable auto-deletion
sandbox.set_auto_delete_interval(-1)

Wall-clock TTL

The wall-clock TTL (time-to-live) sets a hard upper bound on how long a sandbox may exist. Unlike the auto-delete interval, which counts time only while the sandbox is stopped, TTL runs as wall-clock time from creation (or from the moment you last set it) and destroys the sandbox in any state: started, stopped, paused, or archived.

Set ttl_minutes when creating a sandbox, or update it later. The value is in minutes:

• 0: disables the TTL
• if not set, the sandbox has no TTL deadline

Calling set_ttl after creation resets the deadline from the current moment. Use wall-clock TTL for agent sessions, CI jobs, and any sandbox that must not outlive a fixed deadline.

sandbox = daytona.create(CreateSandboxFromSnapshotParams(
    snapshot="my-snapshot",
    # Destroy the sandbox 2 hours after creation, regardless of state
    ttl_minutes=120,
))

# Reset the deadline to 1 hour from now
sandbox.set_ttl(60)

# Disable the TTL
sandbox.set_ttl(0)

Update sandbox last activity

Update a sandbox's last activity timestamp.

This updates the sandbox's recorded activity time without changing its runtime state. It is useful when your workflow is driven by external systems or background orchestration that may not reset inactivity tracking.

sandbox.refresh_activity()

Running indefinitely

Run sandboxes indefinitely.

By default, Daytona sandboxes auto-stop after 15 minutes of inactivity. To keep a sandbox running without interruption from inactivity, set the auto-stop interval to 0 when creating a new sandbox. Disabling auto-stop does not disable wall-clock TTL: if ttl_minutes is set, the sandbox is still destroyed when that deadline elapses.

1. Go to Daytona Sandboxes ↗
2. Click Create Sandbox
3. Set auto-stop to 0
4. Click Create

sandbox = daytona.create(CreateSandboxFromSnapshotParams(
    snapshot="my_awesome_snapshot",
    # Disables the auto-stop feature - default is 15 minutes
    auto_stop_interval=0,
))