Skip to content

Sandboxes

View as Markdown

Daytona provides full composable computerssandboxes — 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 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.

Sandboxes can use snapshots to capture a fully configured environment (base operating system, installed packages, dependencies and configuration) to create new 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()

Create a sandbox from a default snapshot.

SnapshotvCPUMemoryStorageGPUSandbox Class
daytona-small11GiB3GiBContainer
daytona-medium24GiB8GiBContainer
daytona-large48GiB10GiBContainer
daytona-gpu11GiB1GiB1GPU
daytona-vm-small11GiB3GiBLinux VM
daytona-vm-medium24GiB8GiBLinux VM
daytona-vm-large48GiB10GiBLinux VM
windows-small14GiB30GiBWindows
windows-medium28GiB50GiBWindows
windows-large416GiB50GiBWindows
  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",
)
)

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.

ResourceUnitDefaultMinimumMaximum
CPUvCPU114
MemoryGiB118
DiskGiB3110
  1. Go to Daytona Sandboxes ↗
  2. Click Create Sandbox
  3. Enter a base image
  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),
)
)

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)

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

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.

Create a GPU sandbox from a default snapshot.

  1. Go to Daytona Sandboxes ↗
  2. Click Create Sandbox
  3. Select a daytona-gpu snapshot
  4. Select ephemeral or set auto-delete interval to 0
  5. Click Create
from daytona import Daytona, CreateSandboxFromSnapshotParams
daytona = Daytona()
sandbox = daytona.create(
CreateSandboxFromSnapshotParams(
snapshot="daytona-gpu",
auto_delete_interval=0,
),
)

Daytona provides VM sandboxes for workloads that require a full virtual machine with a dedicated Linux or Windows operating system. VM sandboxes are distinct from container sandboxes and support VM-only capabilities:

Create a Linux VM sandbox.

Create a Linux VM sandbox from a default snapshot.

  1. Go to Daytona Sandboxes ↗

  2. Click Create Sandbox

  3. Select a Linux VM snapshot:

    • daytona-vm-small
    • daytona-vm-medium
    • daytona-vm-large
  4. Click Create

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

Create a Windows sandbox.

  1. Go to Daytona Sandboxes ↗

  2. Click Create Sandbox

  3. Select a Windows snapshot:

    • windows-small
    • windows-medium
    • windows-large
  4. Click Create

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

Create an ephemeral sandbox.

Ephemeral sandboxes are automatically deleted once they are stopped.

  1. Go to Daytona Sandboxes ↗
  2. Click Create Sandbox
  3. Set Ephemeral to True 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)

Create a linked sandbox.

Linked sandboxes are attached to an existing parent sandbox at creation time.

  • 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 a sandbox.

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

Get a sandbox by ID or name.

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

List sandboxes.

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

For container sandboxes, stopping terminates the running container. The filesystem is preserved, but memory state is not. Container sandboxes do not support pause; stop is the way to shut down a container sandbox when it is not in use.

For VM sandboxes (Linux and Windows), stopping shuts down the virtual machine while preserving the filesystem, and memory state is cleared. To preserve running process state without consuming CPU, use pause / resume instead.

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.

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

Archive moves a stopped container sandbox’s filesystem to object storage and free disk quota. Archive is supported for container sandboxes only.

VM sandboxes (Linux and Windows) do not support archive. Stopping a VM sandbox already offloads filesystem state and releases disk quota, so a separate archive step is not needed.

  1. Ensure the sandbox is stopped
  2. Archive the sandbox
  3. Wait for the sandbox to reach the archived state
  4. Start the sandbox again when you need to use it
sandbox.archive()

For container sandboxes, pause is not supported. The filesystem can be preserved on stop, but memory state is not. Use stop to shut down a container sandbox when it is not in use.

For VM sandboxes (Linux and Windows), pausing freezes the virtual machine. The filesystem and memory state are preserved, and CPU is no longer consumed.

  1. Ensure the VM sandbox is started
  2. Pause the VM sandbox
  3. Wait for the VM sandbox to reach the paused state
  4. Resume (start) the VM sandbox again when you need to resume it
sandbox.pause()

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()

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.

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

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 a sandbox.

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

A snapshot captures a point-in-time copy of a sandbox that you can use as a base to create new sandboxes, templating a known-good environment for reuse. The resulting snapshot inherits the source sandbox’s class and can only create sandboxes of that same class.

Container sandboxes capture filesystem state only (cold snapshot). VM sandboxes capture filesystem and memory state (hot snapshot) through the includeMemory parameter:

Snapshot typeInclude memorySnapshot contentsRequired sandbox state
Coldfalse (default)Filesystem onlyStopped
HottrueFilesystem and memoryStarted
# Cold snapshot (filesystem only, sandbox stopped)
sandbox._experimental_create_snapshot("my-snapshot")
# Hot snapshot (filesystem and memory, sandbox running)
sandbox._experimental_create_snapshot("my-vm-snapshot", include_memory=True)

Forking is supported for VM sandboxes only. Forking creates a duplicate of a sandbox’s filesystem and memory state in a new sandbox. The forked sandbox is fully independent: it can be started, stopped, and deleted without affecting the original.

Daytona tracks the parent-child relationship in a fork tree, so you can trace a fork’s lineage back to the sandbox it was created from. You can fork a fork to build branches. The parent sandbox cannot be deleted while it has active fork children.

  1. Go to Daytona Sandboxes ↗
  2. Click the three-dot menu () next to the started VM sandbox you want to fork
  3. Select Fork
# Fork sandbox through the Sandbox instance
forked = sandbox._experimental_fork(name="my-forked-sandbox")
Lifecycle featureContainerLinux VMWindowsGPU
Start sandboxes
Stop sandboxes
Pause / resume sandboxes
Archive sandboxes
Fork sandboxes
Snapshot from sandbox
(filesystem only)
Snapshot from sandbox
(filesystem + memory)

A sandbox can have several different states. Each state reflects the status of your sandbox.

Sandbox states
StateDescription
CreatingThe sandbox is provisioning and will be ready to use.
Pulling SnapshotThe sandbox is pulling a snapshot to provide a base environment.
Building SnapshotThe sandbox is building a snapshot to provide a base environment.
Pending BuildThe sandbox build is pending and will start shortly.
Build FailedThe sandbox build failed and needs to be retried.
StartingThe sandbox is starting and will be ready to use.
StartedThe sandbox has started and is ready to use.
StoppingThe sandbox is stopping and will no longer accept requests.
StoppedThe sandbox has stopped and is no longer running. Container sandboxes keep their filesystem on the runner. VM sandboxes offload filesystem state to nearby storage.
PausingThe VM sandbox is pausing while its filesystem and memory state are preserved.
PausedThe VM sandbox is paused with filesystem and memory state preserved. State is offloaded to nearby storage.
ResumingThe VM sandbox is resuming from a paused state and will be ready to use.
ArchivingThe container sandbox filesystem is being moved to object storage.
ArchivedThe container sandbox filesystem is stored in object storage.
RestoringThe sandbox is being restored and will be ready to use shortly.
ResizingThe sandbox is being resized to a new set of resources.
SnapshottingThe sandbox is creating a snapshot of its filesystem and memory.
ForkingThe sandbox is being forked into a new independent sandbox.
DeletingThe sandbox is deleting and will be removed.
DeletedThe sandbox has been deleted and no longer exists.
ErrorThe sandbox is in an error state and needs to be recovered.
UnknownThe default sandbox state before it is created.

The diagram demonstrates the states and possible transitions between them.

Sandbox lifecycle diagram

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.

State transitions
Initial stateTarget stateTrigger
UnknownPulling SnapshotThe base snapshot is being pulled to provide the sandbox environment.
UnknownBuilding SnapshotThe sandbox uses a declarative image build, which begins building.
Pending BuildBuilding SnapshotThe queued image build starts.
Building SnapshotBuild FailedThe image build fails or times out.
Pulling SnapshotCreatingThe snapshot is available and the sandbox container is created.
Building SnapshotCreatingThe snapshot finishes building and the sandbox container is created.
CreatingStartedThe sandbox container finishes initializing and is running.
StoppedStartingA start is requested and the sandbox boots.
StoppedRestoringA start is requested and the sandbox is restored from a backup.
ArchivedRestoringA start is requested and the archived filesystem is restored from object storage.
RestoringStartedThe restore completes and the sandbox is running.
StartingStartedThe sandbox is running and ready to accept requests.
StartedStoppingA stop is requested, or the auto-stop interval is exceeded.
StoppingStoppedThe sandbox process exits and its memory state is cleared.
StartedPausingA pause is requested.
PausingPausedThe filesystem and memory state are preserved.
PausedResumingA start is requested on a paused sandbox.
PausedStoppingA stop is requested on a paused sandbox.
ResumingStartedThe sandbox resumes from memory and is running.
StoppedArchivingAn archive is requested, or the auto-archive interval is exceeded.
ArchivingArchivedThe backup completes and the filesystem is moved to object storage.
StartedResizingCPU or memory is increased on a running sandbox.
StoppedResizingResources are changed on a stopped sandbox.
ResizingStartedThe running sandbox returns to service after resizing.
ResizingStoppedThe stopped sandbox completes resizing.
StartedSnapshottingA snapshot of the filesystem and memory is created.
StoppedSnapshottingA snapshot of the filesystem is created.
SnapshottingStartedThe snapshot completes and the sandbox returns to service.
SnapshottingStoppedThe snapshot completes and the sandbox remains stopped.
StartedForkingThe sandbox is forked into a new independent sandbox.
ForkingStartedThe fork completes and the sandbox returns to service.
StartedDeletingA delete is requested, or the auto-delete interval is exceeded.
StoppedDeletingA delete is requested.
ArchivedDeletedAn archived sandbox is deleted directly without being restored.
DeletingDeletedThe sandbox is removed and its resources are released.
StartedErrorAn operation fails or times out.
ErrorRestoringA recover is requested for a recoverable error and the sandbox is restored.
ErrorArchivingAn errored sandbox with a completed backup is archived to preserve its state.

Sandboxes can be automatically stopped, archived, and deleted based on user-defined intervals. The intervals act as a TTL (time-to-live) mechanism for the sandbox. You can also refresh the last activity timestamp to explicitly signal activity when lifecycle behavior depends on inactivity intervals.

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()

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-name",
# 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.

The inactivity timer resets only for specific external interactions:

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.

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-name",
# Auto-archive after a sandbox has been stopped for 1 hour
auto_archive_interval=60,
))

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-name",
# 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)

Run sandboxes indefinitely.

By default, Daytona sandboxes auto-stop after 15 minutes of inactivity. To keep a sandbox running without interruption, set the auto-stop interval to 0 when creating a new sandbox.

  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,
))