Sandboxes

A sandbox is a hardware-isolated virtual machine with its own kernel, filesystem, network stack, and allocated vCPU, RAM, and disk, with isolation enforced by the hypervisor.

Sandboxes run as Linux (default), Windows, macOS, or GPU-accelerated virtual machines. Every sandbox moves through a lifecycle and can have several different states. While the sandbox is running, it exposes a toolbox for code, command, and process execution, sessions, filesystem and git operations, computer use, language server protocol support, and log streaming.

Use sandboxes to run code written by an agent, build and test software, train or serve a model on a dedicated GPU, drive desktop through screenshots and input events, or spin up thousands of identical environments for autonomous, evaluation, and reinforcement learning workflows.

Create sandboxes

Daytona provides methods to create sandboxes from the dashboard or programmatically.

1. Go to Daytona Sandboxes ↗
2. Click Create
3. Select Linux sandbox, Windows sandbox, GPU sandbox, or macOS sandbox
4. Click Create

from daytona import Daytona

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

Linux sandboxes

Linux sandboxes are Firecracker microVMs that run their own Linux kernel, and they are the default sandbox type. A Linux sandbox boots from an image that you import from a container registry, build from a Dockerfile, or capture from another sandbox. It can also start from a snapshot of another Linux sandbox. Each sandbox runs on an amd64 or arm64 CPU.

from daytona import Daytona

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

Windows sandboxes

Windows sandboxes are virtual machines running Windows Server 2022. A Windows sandbox starts from a prepared Windows base image, or from an image captured from another Windows sandbox. Commands run in PowerShell, and the desktop is reached over the remote desktop protocol.

macOS sandboxes

macOS sandboxes are virtual machines running macOS on Apple silicon Mac computers. A macOS sandbox starts from a macOS image. A create can set the sandbox's cores, memory and disk, up to the whole Mac. By default it gets half of the Mac's cores, memory and sandbox disk, so two sandboxes can share one Mac.

GPU sandboxes

GPU sandboxes have one or more dedicated NVIDIA or AMD GPUs attached for workloads that require GPU acceleration, model inference, training, fine-tuning, and reinforcement learning. A GPU sandbox is ephemeral and can be saved as a checkpoint that includes its processes, memory, and GPU memory, and resumed in a new GPU sandbox.

• NVIDIA H100
• NVIDIA H200
• NVIDIA B200
• NVIDIA B300
• NVIDIA RTX Pro 6000
• NVIDIA RTX 4090
• NVIDIA RTX 5090
• NVIDIA L40S
• AMD Instinct MI355X

Resources

Linux sandboxes have 0.5 cores, 1024MiB memory, and 512MiB disk by default. A Linux sandbox may guarantee at most 16 cores, 32GiB memory, and 256GiB disk. A macOS sandbox takes its size from its Mac reservation.

CPU is measured and billed in cores, from fractions of a core up to many cores. One core is 2 vCPUs where simultaneous multithreading (SMT, also called hyperthreading) is available and enabled, and 1 vCPU otherwise. Each resource has a guarantee and a limit. A sandbox can always use its guarantee and takes more as its workload needs it, up to the limit, with no manual resize.

The guarantee is the CPU, memory, and disk that Daytona reserves for the sandbox on its host. It is billed as a minimum, whether the sandbox uses it or not. The CPU guarantee is at least 1 core for every 8GiB of guaranteed memory. When a create guarantees more memory than its CPU guarantee covers, Daytona raises the CPU guarantee to that floor, so a sandbox that guarantees 16GiB memory reserves and is billed for at least 2 cores.

The limit is the most the sandbox can use. You set it when you create the sandbox. When a create sets no limit, the limit is the platform maximum or the cap of the organization's plan, whichever is lower. A limit equal to its guarantee gives the sandbox a fixed size that does not grow.

from daytona import Daytona
from daytona.v2 import Resources

daytona = Daytona()
sandbox = daytona.v2.create(
    # memory and disk are GiB: 2 maps to memory_mib=2048, 20 to disk_mib=20480
    resources=Resources(cpu=1, memory=2, disk=20, cpu_max=2, memory_max=4, disk_max=40),
)

Regions

Every sandbox runs in a region, a geographic or logical group of compute infrastructure. A create request can name a region, and Daytona places the sandbox on available capacity inside it.

from daytona import Daytona

daytona = Daytona()
sandbox = daytona.v2.create(region="earth")

Hardware virtualization

Server processors include instructions for running virtual machines directly on the hardware. A virtual machine monitor uses these instructions to create a guest with its own virtual processors, memory, and devices. The processor rejects any access from a guest to host memory or to another guest's memory. Linux, Windows, and macOS sandboxes run as virtual machines, each on the virtual machine monitor that its operating system needs.

Linux exposes the processor's virtualization through the Kernel-based Virtual Machine (KVM). Linux sandboxes run on Firecracker, a virtual machine monitor built to run many small, short-lived virtual machines on one host. Firecracker provides only the devices a server needs: virtual disks, a network card, and a serial console. Each Linux sandbox runs as one Firecracker process on a host, in its own network namespace, with its own virtual processors and memory.

Windows sandboxes also use KVM, but Firecracker does not support Windows guests. Windows sandboxes run on Cloud Hypervisor, a virtual machine monitor that also keeps its device model small but can start an operating system from firmware. Each Windows sandbox runs as one Cloud Hypervisor process on a host, in its own network namespace, with its own virtual processors and memory.

Cloud Hypervisor provides each Windows sandbox with the following:

• UEFI firmware, which loads the Windows boot manager from the sandbox's disk
• Hyper-V enlightenments: interfaces Windows uses to run efficiently as a guest
• Virtual disks and a virtual network card, for which the base image carries Windows drivers
• A serial console for management, and no graphics card

macOS sandboxes run on Macs, because Apple's license allows macOS virtual machines only on Apple hardware. Apple silicon includes hardware support for virtual machines, which macOS exposes through Apple's Virtualization framework. Each macOS sandbox runs as its own virtual machine on its Mac, with its own virtual processors, memory, disk, and network card.

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 automatically when one of its timeouts elapses.

See the lifecycle of Linux, Windows, GPU, and macOS sandboxes.

The following tables list the states of a Linux sandbox and the transitions between them. The SDKs report the states in the State column. The CLI and API report the more detailed status in the API status column.

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.

Sandbox operations

Daytona provides methods to manage existing sandboxes. Sandbox operations find sandboxes, read their current state and configuration, and update their metadata. They do not change the state of a sandbox or touch anything running inside it. To stop, pause, fork, or delete a sandbox, see lifecycle. To run commands or work with files inside a sandbox, use the toolbox.

List sandboxes

List sandboxes in the project, page by page. Unfiltered lists read the region-local database, so new sandboxes appear at once. To filter by name, state, labels, or resources, use search.

from daytona import Daytona

daytona = Daytona()
page = daytona.v2.list()
for sandbox in page.items:
    print(sandbox.id, sandbox.name, sandbox.state)

Iterate over all sandboxes

Iterate over every sandbox in the project without handling page cursors. The iterator fetches the next page when the current one is exhausted and stops when the server returns no cursor.

from daytona import Daytona

daytona = Daytona()
for sandbox in daytona.v2.iter():
    print(sandbox.id, sandbox.name, sandbox.state)

Search sandboxes

Search sandboxes across every region. Search reads a central index that is eventually consistent: a create, update, or delete becomes searchable about 2 to 3 seconds after it is committed, so a sandbox created a moment ago may be missing. To read your own writes, use list without filters or get. Filters combine with AND, and deleted sandboxes are left out of the results.

from daytona import Daytona

daytona = Daytona()

# Free text over name and image, or an exact sandbox id
page = daytona.v2.search(q="my-sandbox")
for sandbox in page.items:
    print(sandbox.id, sandbox.name, sandbox.state)

Get a sandbox

Get a sandbox by its ID. The response includes the current state, resources, labels, and lifecycle settings. Get reads the control plane directly, so it reflects changes immediately, unlike search.

from daytona import Daytona

daytona = Daytona()

# Fetch the sandbox from the control plane
sandbox = daytona.v2.get("{sandboxId}")
print(sandbox.state, sandbox.cpu, sandbox.memory, sandbox.disk)

# Store the sandbox data as JSON; it carries no URL or credential
saved = sandbox.to_json()  # {"sandboxId": "...", "name": "...", "state": "...", ...}

# Later, get the sandbox again by its ID
sandbox = daytona.v2.get(saved["sandboxId"])

Refresh a sandbox

Refresh a sandbox object with its current data. A sandbox object keeps the fields from the request that returned it, so its state, resources, and labels can be out of date after a change made by another client. Refresh reads the sandbox from the control plane and updates the object in place. Lifecycle operations such as start and stop refresh the object when they finish.

# Re-read the sandbox from the control plane
sandbox.refresh_data()
print(sandbox.state, sandbox.labels)

Find sandboxes by name

Find sandboxes by the name they were created with. Names are not unique, so the result is a list, newest first, and it is empty when no sandbox matches. The lookup reads the search index, so a sandbox created a moment ago can be missing.

The name is stored as the name label. Replacing a sandbox's labels without it removes the sandbox from name lookups.

from daytona import Daytona

daytona = Daytona()

# Reuse a named sandbox, or create it when none exists
found = daytona.v2.find_by_name("my-sandbox")
sandbox = found[0] if found else daytona.v2.create(name="my-sandbox")

Create an access token

Create a short-lived access token for one sandbox. The token reaches the sandbox toolbox, SSH, desktop, and private preview ports, and can stop, pause, or delete the sandbox, limited to the operations and ports you grant. Give it to a collaborator, a CI job, or a browser instead of a project API key.

The token lasts one hour by default and at most 24 hours. It cannot be refreshed, revoked, or used to create other credentials. Create a new token when it expires.

# Grant file system and SSH access for 15 minutes
token = sandbox.create_access_token(operations=["toolbox:fs", "ssh"], ttl_seconds=900)
print(token.access_token, token.expires_at)

Label sandboxes

Update a sandbox's labels. Labels are key-value strings for organizing sandboxes, and you can filter by them when you list or search. An update replaces the full label set; omitted labels are removed. A sandbox holds at most 100 labels, each key and value at most 512 bytes.

from daytona import Daytona

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

# Replace the full label set
labels = sandbox.set_labels({"team": "research"})
print(labels)

Metrics

Read the current CPU, memory, and disk usage of a running sandbox. The toolbox measures each value inside the sandbox and returns one snapshot per request. Memory in use excludes memory the operating system can reclaim on demand, such as the file cache. Disk usage is measured on the filesystem that holds the sandbox working directory.

CPU utilization is the share of total CPU capacity in use across all CPUs since the previous metrics request to the sandbox, from any client. The first request after the toolbox starts measures over about 100 milliseconds.

metrics = sandbox.metrics()
print(metrics.cpu_utilization, metrics.memory_usage_bytes, metrics.disk_usage_bytes)

Logs

Read the serial console log of a sandbox. For a running sandbox the log is read live from its runner; for a sandbox in any other state the persisted log is returned.

# Serial console log of the microVM
daytona sandbox logs {sandboxId}

Entrypoint logs

Read the log of the sandbox entrypoint process as text. For a running sandbox the log is read live; for a sandbox in any other state the persisted log is returned. To page through the log or follow it, read the entrypoint process through the toolbox.

print(sandbox.entrypoint_logs())

Build logs

Read the output of the image build behind a sandbox. A sandbox has a build log when its image is built from a Dockerfile, including a build that failed before the sandbox was placed; a sandbox created from a registry image has none. When the sandbox reuses an image built earlier, the log is the output of that original build.

Following the log streams output while the build runs and ends when the build finishes. Stopping the reader does not stop the build. To read the log of an image without a sandbox, see image build logs.

from daytona import Daytona
from daytona.v2 import ImageBuilder

daytona = Daytona()
sandbox = daytona.v2.create_from_build(ImageBuilder.from_dockerfile("FROM python:3.12-slim"))

# Output retained so far, as text
print(sandbox.build_logs())

# Stream output until the build finishes
result = sandbox.follow_build_logs(on_logs=lambda chunk: print(chunk, end=""))
print(result.status, result.reason)

Permissions

Sandboxes are scoped to a project. An API key reaches only the sandboxes of its own project. Access is governed by three permissions, which you can grant to an organization role or an API key.

Setting, changing, or clearing a delete action in a lifecycle policy also requires the permission to delete sandboxes, and so does creating an access token that can delete the sandbox. Attaching secrets when creating a sandbox requires the permission to read secrets. The audit logs record sandbox creates, lifecycle changes, deletes, and access token creation.