Architecture

Daytona platform is organized into multiple plane components, each serving a specific purpose:

• Interface plane provides client interfaces for interacting with Daytona
• Control plane accepts requests, stores state, and hands work to runners
• Compute plane runs sandboxes and serves sandbox traffic

Interface plane

The interface plane provides client interfaces for users and agents to interact with Daytona. The following components are part of the interface plane and available to all users and agents:

• SDK: Python, TypeScript. Each SDK discovers every region's API endpoint and sends each request to the region that owns the sandbox. Lifecycle and resource operations (sandboxes, images, snapshots, volumes) go to that region's API; data-plane calls into a running sandbox (file system, process execution, Git, PTY) go directly to that region's proxy
• Dashboard: web UI for sandboxes, images, snapshots, volumes, projects, and organization settings, with a terminal, file browser, desktop, SSH panel, and playground
• SSH: shell, scp/sftp, and port forwarding into sandboxes through the SSH gateway
• Preview URLs: HTTP and WebSocket access to services listening inside a sandbox

Control plane

The control plane is the central coordination layer of the Daytona platform. It receives all client requests, authenticates them, records the desired state, and publishes jobs that runners pick up. Runners report progress back as events, so no sandbox operation requires a synchronous round trip between the API and a runner. The control plane includes the following components:

• API handles authentication, tenancy, sandboxes, images, snapshots, volumes, and secrets
• Database and job queue persist platform state and carry work to runners

Every region runs its own control plane, job queue, proxy, and runner fleet. The home region also hosts the management plane: organizations, users, projects, API keys, and billing.

API

The API is a Rust-based RESTful service that serves as the primary entry point for all platform operations. Creating a sandbox writes a row, publishes a job to the region's queue, and returns; everything that follows happens on a runner and is reported back as events that the API applies to its state. The API also runs the maintenance loops that enforce automated sandbox lifecycle policies: the timeout and idle timeout of each sandbox.

The API authenticates the following credentials:

• Project API keys carry an explicit set of permissions and an optional expiry, and are the credential used by SDKs, the proxy, and the SSH gateway
• Organization API keys are managed by organization admins and limited to their endpoints
• Sandbox tokens are issued to each sandbox so it can stop, pause, or delete itself
• OIDC tokens authenticate dashboard sign-ins through the OpenID Connect provider

Access control follows organization and project boundaries: every sandbox, image, snapshot, volume, and secret belongs to a project, and project API keys see only their project.

To interact with sandboxes from the API, see the API and Toolbox API references.

Database and job queue

• PostgreSQL is the primary persistent store for organizations, projects, sandboxes, images, snapshots, volumes, and secrets. Each region keeps its own database; tenancy data is replicated read-only from the home region so API keys authenticate locally in every region
• NATS JetStream carries create, stop, and delete jobs from the API to runners and streams runner events back to the API and proxy. Runners pull jobs only from their region's queue
• Redis is optional and used for authentication rate limiting and signed preview URL state

Secrets are encrypted at rest with AES-256-GCM and sealed to each runner's key for delivery. Sandboxes see only placeholders; the host substitutes real values in outbound requests.

Compute plane

The compute plane is where sandboxes run and their traffic is served. Sandboxes run on runners, compute nodes that host multiple sandboxes with dedicated resources and scale horizontally across shared or dedicated regions. It includes the following components:

• Sandbox runners build images and boot sandboxes as microVMs
• Sandbox daemon provides code execution and environment access inside each sandbox
• Proxy routes Toolbox, SSH, preview, and VNC traffic straight to sandboxes
• Image store holds converted image layers shared by all runners in a region
• Sandbox storage holds ephemeral and persistent sandbox disks and VM snapshots
• Volumes provide persistent storage shared across sandboxes

Sandbox runners

Runners are the compute nodes of Daytona's compute plane. Each runner is a Go agent that pulls jobs from its region's queue and executes sandbox operations: building or pulling images, creating, starting, stopping, pausing, resuming, forking, resizing, and deleting sandboxes, and capturing snapshots. Runners accept no inbound connections from the control plane; they report state changes as events and stream sandbox usage to the metering pipeline that feeds billing.

Each sandbox runs as a hardware-isolated microVM with its own kernel and dedicated vCPU, RAM, and disk. Sandboxes run on Firecracker. Runners boot most sandboxes by resuming a pre-built memory snapshot of the image rather than cold-booting, which is what makes sub-second creation possible. Traffic between sandboxes is blocked on the host, and per-sandbox egress policies are enforced there as well. See isolation for details.

Sandbox daemon

The sandbox daemon is a Rust agent that runs as the init process inside each sandbox. It is injected by the runner as a read-only system layer, so it does not need to be part of your image. It exposes the Toolbox API, providing direct access to the sandbox environment: file system and Git operations, process and code execution, PTY and log streaming, language servers, and computer use. It also runs the SSH server that the SSH gateway connects to.

Proxy

The proxy is a stateless service serving the sandbox data plane. It authenticates each request, resolves the target sandbox to its address on the runner overlay network, and forwards the connection directly to the sandbox daemon or a port inside the sandbox, bypassing the API. It supports HTTP, WebSocket, and server-sent events, and exposes these endpoints:

Authenticated Toolbox, preview, and SSH traffic also resets the idle timeout.

Image store

Daytona does not run an internal image registry. When an image is pulled from a container registry or built from a Dockerfile, the runner converts each layer into a read-only, content-addressed filesystem image and stores it in a per-region shared store, together with a manifest that records the layer stack, entrypoint, environment, and working directory. Layers are keyed by content hash, so a layer shared by many images is converted and stored once per region, and sandboxes attach these layers read-only at boot without copying them. An image reaches another region automatically: that region fetches it from the global artifact store the first time a sandbox there uses it.

Sandbox storage

Sandbox writes go to a layer above the read-only image layers:

• Ephemeral sandboxes write to the runner's NVMe scratch disk, discarded on delete
• Persistent sandboxes write to a per-sandbox block image in a region-wide storage pool that any runner in the region can attach. This makes stop/start, pause/resume, and fork possible
• VM snapshots capture a sandbox's disk, and memory in full snapshots, for restore

Volumes

Volumes provide persistent storage that can be shared across sandboxes. Volume data lives in S3-compatible object storage as content-addressed blobs; a mounted volume is materialized inside the sandbox as a read-write directory, and changes are committed back periodically. Multiple sandboxes can mount the same volume simultaneously, allowing data to be shared across sandboxes and persist independently of the sandbox lifecycle.

Container registry

Container registries serve as the source for sandbox base images. When you pull an image, a runner fetches it from the external registry and converts it into the image store; for Dockerfile builds, parent images in FROM directives are pulled the same way. Credentials for private registries are stored per project as registries. Daytona supports any OCI-compatible registry:

• Docker Hub
• Google Artifact Registry
• GitHub Container Registry (GHCR)
• Amazon ECR
• Private registries: any OCI distribution registry that supports basic authentication