コンテンツにスキップ

Architecture

View as Markdown

このコンテンツはまだ日本語訳がありません。

Daytona provides full composable computers — sandboxes — for AI agents. Daytona platform is organized into multiple plane components, each serving a specific purpose:

Daytona architecture diagram

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, Ruby, and Go for programmatic sandbox management
  • CLI: command-line interface for direct sandbox operations
  • Dashboard: web interface for visual sandbox management and monitoring
  • MCP: Model Context Protocol server for AI tool integration
  • SSH: secure shell access to running sandboxes

Control plane

The control plane is the central coordination layer of the Daytona platform. It receives all client requests, manages the full sandbox lifecycle, schedules sandboxes onto runners, and continuously reconciles states across the infrastructure. The control plane includes the following components:

  • API handles authentication, sandbox lifecycle management, and resource allocation
  • Proxy routes external traffic to sandboxes, enabling direct access to services
  • Snapshot builder builds and manages sandbox snapshots
  • Sandbox manager handles sandbox lifecycle management and state reconciliation

API

The API is a NestJS-based RESTful service that serves as the primary entry point for all platform operations, managing authentication, sandbox lifecycle, snapshots, volumes, and resource allocation. The snapshot builder and sandbox manager run as internal processes within the API. The API integrates the following internal services and components:

  • Redis provides caching, session management, and distributed locking
  • PostgreSQL serves as the primary persistent store for metadata and configuration
  • Auth0/OIDC provider authenticates users and services via OpenID Connect. The API enforces organization-level multi-tenancy, where each sandbox, snapshot, and volume belongs to an organization, and access control is applied at the organization boundary
  • SMTP server handles email delivery for organization invitations, account notifications, and alert messages
  • Sandbox manager schedules sandboxes onto runners, reconciles states, and enforces sandbox lifecycle management policies
  • PostHog collects platform analytics and usage metrics for monitoring and improvement

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

Proxy

The proxy is a dedicated HTTP proxy that routes external traffic to the correct sandbox using host-based routing. Each sandbox is reachable at {port}-{sandboxId}.{proxy-domain}, where the port maps to a service running inside the sandbox. The proxy resolves the target runner for a given sandbox, injects authentication headers, and forwards the request. It supports both HTTP and WebSocket protocols.

Snapshot builder

The snapshot builder is part of the API process and orchestrates the creation of sandbox snapshots from a Dockerfile or a pre-built image from a container registry. It coordinates with runners to build or pull images, which are then pushed to an internal snapshot registry that implements the OCI distribution specification.

Sandbox manager

The sandbox manager is part of the API process and schedules sandboxes onto runners, reconciles states, and enforces sandbox lifecycle management policies.

Compute plane

The compute plane is the infrastructure layer where sandboxes run. Sandboxes run on runners, compute nodes that host multiple sandboxes with dedicated resources and scale horizontally across shared or dedicated regions. The compute plane consists of the following components:

Sandbox runners

Runners are compute nodes that power Daytona’s compute plane, providing the underlying infrastructure for running sandbox workloads. Each runner polls the control plane API for jobs and executes sandbox operations: creating, starting, stopping, destroying, resizing, and backing up sandboxes. Runners interact with S3-compatible object storage for snapshot and volume data, and with the internal snapshot registry.

Each sandbox runs as an isolated instance with its own Linux namespaces for processes, network, filesystem mounts, and inter-process communication. Each runner allocates dedicated vCPU, RAM, and disk resources per sandbox.

Sandbox daemon

The sandbox daemon is a code execution agent that runs inside each sandbox. It exposes the Toolbox API, providing direct access to the sandbox environment: file system and Git operations, process and code execution, computer use, log streaming, and terminal sessions.

Snapshot store

The snapshot store is an internal OCI-compliant registry that stores sandbox snapshot images using the OCI distribution specification. Runners pull snapshot images from this store when creating new sandboxes. The store uses S3-compatible object storage as its backend.

Volumes

Volumes provide persistent storage that can be shared across sandboxes. Each volume is backed by S3-compatible object storage and mounted into sandboxes as a read-write directory. 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 creating a snapshot, the snapshot builder pulls the specified image from an external registry, and pushes it to the internal snapshot registry for use by runners. For Dockerfile-based snapshots, parent images referenced in FROM directives are also pulled from the configured source registries during the build. Daytona supports any OCI-compatible registry: