daytona

Daytona provisions ephemeral, containerized execution environments using a Docker-based runner system with a warm pool of pre-initialized sandboxes for sub-second startup. The system uses a runner adapter pattern to abstract container orchestration, enabling multi-region deployment with health monitoring and automatic runner selection based on resource availability and latency. Sandboxes are created from snapshots (pre-built images) or from scratch, with configurable CPU, memory, and storage allocations managed through a state reconciliation engine.

Daytona implements a snapshot system that captures sandbox state (filesystem, installed packages, configuration) as immutable images that can be versioned, published, and distributed across regions. The snapshot manager handles creation, lifecycle management, and propagation using an event-driven architecture (snapshot-activated.event.ts) that triggers distribution to regional runners. Snapshots support incremental updates and can be used as base images for new sandboxes, enabling reproducible execution environments and fast sandbox cloning.

Daytona uses an event-driven architecture (event-driven architecture section) where state changes in sandboxes, snapshots, and runners trigger events that are processed asynchronously. The system maintains eventual consistency between the control plane and runner nodes through periodic reconciliation jobs that compare desired state (in database) with actual state (on runners). Events are stored in the database and processed by event handlers that update related entities.

Daytona uses a multi-database storage strategy (multi-database storage strategy section) where different data types are stored in different backends optimized for their access patterns. The configuration management system (configuration.ts, typed-config.service.ts) provides centralized configuration with environment variable overrides and type-safe access. The system supports migrations (TypeORM migrations) for schema evolution and supports multiple database backends (PostgreSQL, MySQL, etc.).

Daytona monitors runner node health through periodic health checks and tracks metrics (CPU, memory, disk usage, container count). The runner selection algorithm (runner selection and health monitoring section) uses these metrics to choose the best runner for new sandboxes, considering resource availability, latency, and region preference. Unhealthy runners are automatically marked as unavailable and excluded from selection. The system supports multiple runner versions through the runner adapter pattern.

Daytona integrates OpenTelemetry for distributed tracing, metrics collection, and logging. The observability system (observability and telemetry section) exports traces to compatible backends (Jaeger, Datadog, etc.) and metrics to time-series databases. Audit logging captures all user actions (create, read, update, delete) with actor, timestamp, and resource information. The system provides built-in dashboards for monitoring sandbox lifecycle, resource usage, and API performance.

Daytona provides organization-level isolation with role-based access control (RBAC) and resource quotas enforced at the API layer. Organizations can have multiple members with granular permissions (create, read, update, delete sandboxes; manage snapshots; configure organization settings). The system supports organization suspension, member invitations, and audit logging of all actions. Authentication uses API keys with scoped permissions and JWT tokens for session-based access, managed through combined-auth.guard.ts.

Daytona manages sandbox state transitions (created, running, stopped, archived, destroyed) through a state machine implemented in sandbox.manager.ts with action handlers (sandbox-start.action.ts, sandbox-stop.action.ts, sandbox-archive.action.ts, sandbox-destroy.action.ts). Auto-management policies can automatically stop idle sandboxes after a configurable duration or destroy sandboxes after expiration. The system uses event-driven state reconciliation to ensure consistency between the control plane and runner nodes, with background jobs (cron system) periodically checking for policy violations.

Daytona provides persistent storage volumes that can be attached to sandboxes, surviving sandbox stop/start cycles but destroyed when the sandbox is deleted. Volumes support configurable size, mount paths, and can be backed up through the backup manager. The system tracks volume usage and enforces storage quotas at the organization level. Volumes are implemented as Docker volumes on runner nodes with optional cloud storage backends for durability.

Daytona provides network isolation for sandboxes with configurable inbound/outbound rules enforced at the runner level. The proxy system (proxy architecture and request flow) intercepts HTTP requests to preview URLs and routes them to sandbox services, with built-in caching strategy and authentication flow. Preview URLs are publicly accessible but can be protected with authentication tokens. The system supports custom preview proxy deployment for on-premises installations.

Daytona provides SDKs for Python, TypeScript, and Go that abstract the REST API into language-native interfaces. The SDK architecture (SDK architecture section) uses a common error handling and timeout strategy across all SDKs, with automatic retry logic and exponential backoff. SDKs support both synchronous and asynchronous operations, with streaming support for long-running tasks. Generated API clients are available for additional languages via OpenAPI specification.

Daytona provides multiple access methods to sandboxes: web-based terminal accessible through the dashboard, SSH access with key-based authentication, and programmatic access via SDKs. The proxy authentication flow (proxy-auth.flow) handles session management for web terminal access. SSH access uses standard OpenSSH with Daytona-managed keys. All access is logged for audit purposes and can be restricted by organization-level policies.

Daytona exposes a comprehensive REST API documented via OpenAPI specification, with auto-generated API clients for multiple languages. The API service architecture (API service architecture section) uses NestJS with controller-based routing (sandbox.controller.ts, job.controller.ts) and dependency injection for modularity. API endpoints support standard HTTP methods (GET, POST, PUT, DELETE) with JSON request/response bodies. The API is versioned and supports pagination, filtering, and sorting on list endpoints.

Daytona implements a background job system (background jobs and cron system section) that executes scheduled tasks on the control plane, such as evaluating auto-management policies, propagating snapshots to regions, and reconciling sandbox state. Jobs are stored in the database and executed by a scheduler that runs on the API service. The system supports cron expressions for periodic jobs and one-time jobs with retry logic and exponential backoff.