Skip to content
/
Tier A A9 Sandbox substrate

Daytona

daytona · daytonaio/daytona · ★ 72k · last commit 2026-05-26

Primitive shape 1 total
MCP tools 1
00

Summary

Daytona — Summary

Daytona is a secure, elastic infrastructure platform for running AI-generated code, providing isolated "sandbox" environments — full composable computers with dedicated kernel, filesystem, network stack, and allocated vCPU/RAM/disk — that spin up in under 90ms. It offers multi-language SDKs (Python, TypeScript, Go, Ruby, Java), a REST API, and a CLI (daytona) so AI agents and developers can programmatically create, manage, and execute code inside sandboxes. The platform is OCI/Docker-compatible, supports snapshot-based persistence, includes computer-use capabilities (VNC, SSH access), and exposes an MCP server interface. Daytona operates as a hosted managed service (app.daytona.io) or as a self-hosted open-source stack (Docker Compose), and supports customer-managed compute (runners on user infrastructure). Like E2B and microsandbox in this batch, Daytona sits below the agent loop as an execution substrate — none of the 11 seed frameworks (superpowers, claude-flow, BMAD, etc.) operate at this layer; they augment agent behavior via skills/hooks/personas while Daytona provides the isolated compute environment those agents run inside.

01

Overview

Daytona — Overview

Origin

Daytona (daytonaio/daytona) began as a development environment management tool and evolved into a secure execution platform for AI-generated code. As of May 2026 it has 72,455 stars — by far the most prominent project in this batch. It is licensed AGPL-3.0, maintained by Daytona (company), and actively developed with contributions from 77+ contributors.

Philosophy

From the README: "Daytona is a secure and elastic infrastructure runtime for AI-generated code execution and agent workflows. Our open-source platform provides sandboxes, full composable computers with complete isolation, a dedicated kernel, filesystem, network stack, and allocated vCPU, RAM, and disk."

Key design priorities:

  • Under 90ms cold start: OCI/Docker-compatible base images, snapshot-based warm pool
  • Elastic and parallel: Massive parallelization; sandboxes are disposable and stateless by default
  • Agent-programmable: Sandboxes are consumed via SDK/API/CLI by agent code, not by humans directly
  • Persistent when needed: Stateful snapshots enable cross-session agent operations
  • Computer use: VNC server, web terminal, SSH, preview URLs for GUI agents

Architecture Summary

The platform has three planes:

  • Interface plane: SDKs (Python, TS, Go, Ruby, Java), CLI (daytona), Dashboard (React SPA), REST API
  • Control plane: NestJS API (apps/api) that orchestrates all sandbox operations
  • Compute plane: Runner service (apps/runner) + Daemon (apps/daemon) running inside each sandbox

Target Use Case

Daytona is designed as the execution infrastructure beneath coding agents, not as a coding agent framework itself. A typical use pattern: an LLM-powered application uses the Daytona Python or TS SDK to create a sandbox, runs agent-generated code inside it, captures output, and tears it down.

02

Architecture

Daytona — Architecture

Distribution

  • Type: Multi-component platform. Consumers use SDKs or CLI; operators deploy via Docker Compose (OSS) or use managed service.
  • Install (SDK): pip install daytona / npm install @daytona/sdk / go get github.com/daytonaio/daytona/libs/sdk-go / gem install daytona / Maven/Gradle io.daytona:sdk
  • Install (CLI): daytona Go CLI binary (from apps/cli)
  • Self-hosted: Docker Compose from docker/ directory; supports Nix flakes for dev environment

Mono-repo Structure

daytona/
├── apps/
│   ├── api/           — NestJS RESTful API (control plane entry point)
│   ├── cli/           — Go CLI (daytona create, daytona sandbox, etc.)
│   ├── daemon/        — Code execution agent inside each sandbox
│   ├── dashboard/     — React SPA web UI (Vite build)
│   ├── docs/          — Astro documentation
│   ├── proxy/         — Reverse proxy for custom routing / preview URLs
│   ├── runner/        — Compute plane; runs and manages sandbox instances
│   ├── snapshot-manager/ — Orchestrates sandbox snapshot creation
│   ├── ssh-gateway/   — SSH gateway for authenticated `ssh` connections
│   └── otel-collector/ — OTel exporter for SDK operations
├── libs/
│   ├── sdk-python/    — Python SDK
│   ├── sdk-typescript/ — TypeScript SDK
│   ├── sdk-go/        — Go SDK
│   ├── sdk-ruby/      — Ruby SDK
│   ├── sdk-java/      — Java SDK
│   ├── api-client-*/  — OpenAPI-generated REST clients per language
│   └── toolbox-api-client-*/ — Toolbox API clients per language
├── .claude/
│   ├── agents/        — batch-dependabot.md (agent instruction file)
│   └── settings.json  — Claude Code settings
├── AGENTS.md          — Nix dev shell guide for AI agents
└── docker/            — Docker Compose for self-hosted deployment

Three-Plane Architecture

Plane Components Role
Interface SDKs, CLI, Dashboard, REST API Developer/agent entry points
Control NestJS API (apps/api) Orchestrates all sandbox operations
Compute Runner + Daemon Actually runs sandbox instances

Build System

NestJS/Yarn 4 + Nx for TypeScript; Go modules via go.work for Go services; Poetry for Python; Nix flakes for reproducible dev shells.

Required Runtime (Self-Hosted)

  • Docker / Docker Compose (for service orchestration)
  • PostgreSQL + Redis (supporting services)
  • Nix (optional, for dev shells)
  • Language runtimes per component (Go, Node.js 22, Python 3.12, Ruby 3.4, JDK 17)

API Surface

REST API at https://app.daytona.io/api (managed) or self-hosted equivalent. Full OpenAPI spec used to generate client libraries.

03

Components

Daytona — Components

Platform Feature Areas

Area Components
Platform Organizations, API Keys, Limits, Billing, Audit logs, OpenTelemetry, Integrations
Sandboxes Environment, Snapshots, Declarative builder, Volumes, Regions
Agent tools Process & code execution, Filesystem operations, LSP, Computer use (VNC), MCP server, Git operations, PTY, Log streaming
Human tools Dashboard, Web terminal, SSH access, VNC access, VPN connection, Preview URLs, Playground
System tools Webhooks, Network limits

SDK (multi-language)

All SDKs expose the same operations against the sandbox lifecycle:

SDK Method Group Operations
Sandbox lifecycle create(), delete(), start(), stop(), get(), list()
Process & code execution process.codeRun(), process.executeCommand()
Filesystem fs.read(), fs.write(), fs.list(), fs.upload()
Git git.clone(), git.commit(), git.push()
PTY pty.create(), pty.send(), pty.resize()
Snapshots snapshot.create(), snapshot.restore()
Log streaming getLogs()

CLI (daytona)

Key subcommands (from README / AGENTS.md):

  • daytona create — Create a new sandbox
  • daytona sandbox — Manage sandboxes
  • Commands for snapshot management, key management, organization management

Dashboard

  • React SPA (Vite build) at apps/dashboard
  • Web UI for visual sandbox management
  • Accessible at app.daytona.io/dashboard (managed) or self-hosted

MCP Server

Daytona exposes an MCP server interface (/docs/mcp/) so MCP-compatible agents can interact with sandboxes via MCP tool calls.

Daemon (in-sandbox)

apps/daemon is a code execution agent running inside each sandbox. It exposes a toolbox API that the runner uses to execute commands, manage files, etc.

Runner (compute plane)

apps/runner manages sandbox instances on compute nodes. Supports both Daytona-managed infrastructure and customer-managed machines.

AGENTS.md / .claude Integration

The repo ships AGENTS.md (Nix dev shell guide) and .claude/settings.json for contributors using Claude Code to work on the Daytona codebase itself. This is developer tooling, not a user-facing agent framework feature.

05

Prompts

Daytona — Prompts

Daytona does not ship agent prompt files, skills, slash-commands, or hook configurations as part of its user-facing product. It is an infrastructure platform, not an agent behavior framework.

Verbatim: Python SDK Quickstart (from README)

from daytona import Daytona, DaytonaConfig

config = DaytonaConfig(api_key="YOUR_API_KEY")
daytona = Daytona(config)
sandbox = daytona.create()
response = sandbox.process.code_run('print("Hello World!")')
print(response.result)

Technique used: This is imperative SDK code, not a prompt. The "prompt" (if any) to the agent happens upstream in the application, not in Daytona itself.

Verbatim: TypeScript SDK Quickstart (from README)

import { Daytona } from "@daytona/sdk";

const daytona = new Daytona({ apiKey: "YOUR_API_KEY" });
const sandbox = await daytona.create();
const response = await sandbox.process.codeRun('print("Hello World!")');
console.log(response.result);

Verbatim: AGENTS.md (Developer Instructions for AI Contributors)

# Agent Development Guide

This project uses **Nix flakes** to provide reproducible development environments 
outside of the devcontainer. When working on this codebase, use the appropriate 
Nix dev shell to ensure all build tools, language runtimes, and dependencies are 
available.

## Available Dev Shells

| Shell | Command | Languages / Tools |
|---|---|---|
| `default` | `nix develop` | Go + Node.js + Python + Ruby + JDK (everything) |
| `go` | `nix develop .#go` | Go, golangci-lint, protobuf, buf |
| `node` | `nix develop .#node` | Node.js 22, Yarn 4 (via corepack) |

Technique: This AGENTS.md is a developer contribution guide instructing AI coding agents on how to navigate the Daytona monorepo build system — it is a repository-level CLAUDE.md analog, not a user-facing agent prompt.

Assessment

All "prompt-like" content in Daytona's repo is either SDK code examples or contributor tooling instructions. The platform provides zero agent-facing prompt injection — it is a pure infrastructure layer.

09

Uniqueness

Daytona — Uniqueness & Positioning

differs_from_seeds

Daytona is architecturally orthogonal to all 11 seed frameworks. Seed frameworks (superpowers, BMAD, claude-flow, openspec, taskmaster-ai, kiro, etc.) operate within the agent loop — they shape what the agent does via skills, hooks, persona files, MCP tools, or spec artifacts. Daytona operates as the compute substrate beneath agents: it provides isolated sandboxes that spin up in <90ms, accessible via multi-language SDKs and REST API, where agent-generated code safely executes. The closest analogy among seeds would be isolation_mechanism, but all seeds use none, git-worktree, or git-branch; Daytona provides full OCI/container sandboxes with dedicated kernels. The scale distinction is also significant: Daytona targets organizational/enterprise parallelization ("massive parallelization") with platform-level audit logs and billing, while seed frameworks target individual developer workflows.

Positioning

Daytona is the most enterprise-oriented sandbox infrastructure in this batch:

  • Scale: Designed for many concurrent sandboxes (organizations, limits, billing)
  • Multi-language: 5 SDKs (Python, TypeScript, Go, Ruby, Java)
  • Human-accessible: Dashboard, web terminal, VNC, preview URLs — not just agent-accessible
  • Compliance: Audit logs, organization management, security exhibit

Competitors in this batch: E2B (simpler, developer-focused cloud sandbox), microsandbox (local microVM, embeddable in code), brood-box (local microVM CLI for wrapping agents). Daytona is the most feature-complete and enterprise-ready but requires network access (cloud API or self-hosted infrastructure).

Distinctive Opinion

Sandboxes should be full composable computers (dedicated kernel, filesystem, network stack) rather than containers with a shared kernel, and they should be programmable by both agents and developers via standardized SDK/API.

Explicit Antipatterns

  • Running untrusted AI-generated code on host without isolation
  • Container-only isolation without dedicated kernel

Observable Failure Modes

  1. Network dependency: Requires connection to Daytona API (or self-hosted infra) — no offline mode
  2. AGPL-3.0 license: Copyleft implications for commercial use (SaaS exception via managed service)
  3. Self-hosting complexity: Full Docker Compose stack with PostgreSQL + Redis + multiple services
  4. No local-only mode: Unlike brood-box/microsandbox, Daytona cannot run purely local without infrastructure setup

Cross-References in This Batch

  • VibeKit (vibekit) ships a @vibe-kit/daytona provider package — Daytona is one of VibeKit's pluggable sandbox backends
  • E2B is the most direct competitor at the API/SDK layer
  • Microsandbox is positioned as the local/embeddable alternative to Daytona's cloud model
04

Workflow

Daytona — Workflow

Typical SDK Workflow (Python)

from daytona import Daytona, DaytonaConfig

config = DaytonaConfig(api_key="YOUR_API_KEY")
daytona = Daytona(config)

# 1. Create sandbox
sandbox = daytona.create()

# 2. Execute code
response = sandbox.process.code_run('print("Hello World!")')
print(response.result)

# 3. (Optional) Snapshot for persistence
# sandbox.snapshot.create("my-snapshot")

# 4. Delete sandbox
daytona.delete(sandbox)

Phases

Phase What Happens Artifact
1. API Key Auth Client authenticates with Daytona API Auth token
2. Sandbox Create Control plane allocates compute + boots sandbox (<90ms target) Sandbox ID + connection info
3. Code / Command Execution Agent sends code/commands via SDK or API to daemon inside sandbox Execution result (stdout/stderr/exit code)
4. Filesystem Ops Agent reads/writes files inside sandbox File contents / operation results
5. (Optional) Snapshot Save current sandbox state for later restoration Snapshot ID
6. (Optional) Preview / VNC Expose port or VNC for visual/human inspection Preview URL / VNC port
7. Teardown Sandbox deleted; compute freed (none)

Approval Gates

None in the standard SDK flow — the API is programmatic and has no human-in-the-loop gate by default. Human tools (dashboard, web terminal, VNC) exist for manual inspection but are not gates in the automated workflow.

Persistence Patterns

  • Ephemeral (default): sandbox created, used, deleted
  • Snapshot-based: snapshot.create() / snapshot.restore() allows persistence across sessions
  • Volumes: Persistent storage that survives sandbox lifecycle

Parallel Execution

Daytona supports massive parallelization — multiple sandboxes can be created and used concurrently. Each has its own isolated compute (kernel, filesystem, network).

06

Memory Context

Daytona — Memory & Context

State Model

Daytona sandboxes are stateless by default (ephemeral). Persistence is opt-in via:

  1. Snapshots: Capture full sandbox state (filesystem, processes, memory) at a point in time. Can be restored later to resume agent operations at the exact prior state.
  2. Volumes: Persistent storage attached to sandboxes; survives sandbox lifecycle.
  3. Stateful sessions: Via .withSession("existing-sandbox-id") in SDK, an existing sandbox can be reused across SDK calls.

State Files / Persistence Mechanisms

Mechanism Scope Use Case
Sandbox filesystem Session (ephemeral by default) Agent working directory
Snapshots Cross-session Resume agent workflows, checkpoint recovery
Volumes Permanent (until deleted) Shared data across sandboxes
Platform audit logs Platform-level Compliance, debugging

Memory Within a Session

There is no framework-level context compaction or memory system. The sandbox is a full computer — any memory management the agent inside does is the agent's own concern. The daemon (apps/daemon) inside each sandbox manages process execution but does not implement LLM context management.

Cross-Session Handoff

Supported via snapshot/restore. An agent can:

  1. Run operations in sandbox A
  2. Create snapshot S
  3. Later restore sandbox A from S to continue

Context to/from Agent

Daytona does not inject context or instructions into the agent. The agent runs as a process inside the sandbox's compute environment. The application using the Daytona SDK is responsible for crafting any agent prompts; Daytona just provides the execution substrate.

07

Orchestration

Daytona — Orchestration

Multi-Agent Support

Yes. Daytona is explicitly designed for massive parallelization — multiple sandboxes can be created and run concurrently. The platform provides the isolation boundary so parallel agents don't interfere.

However, Daytona itself does not orchestrate between agents. It provides the isolation substrate; the application or framework using the Daytona SDK decides how many agents to run and how to coordinate them.

Isolation Mechanism

Container-based (OCI/Docker-compatible), with a dedicated kernel per sandbox. Each sandbox gets:

  • Dedicated kernel
  • Isolated filesystem
  • Isolated network stack
  • Allocated vCPU and RAM

The "dedicated kernel" claim indicates a stronger isolation boundary than standard Docker (likely using microVM or gVisor under the hood), though the README does not specify the underlying hypervisor.

Execution Mode

Event-driven / on-demand: Sandboxes are created on API request, used, and deleted. Cold start target is <90ms. Supports both ephemeral (create-use-delete) and persistent (snapshot-based) patterns.

Orchestration Pattern

None built-in. Daytona is the infrastructure layer. Applications using the Daytona SDK implement their own orchestration (sequential, parallel, hierarchical) via the SDK.

Multi-Model

No. Daytona does not route models. The agent running inside a sandbox determines its own model usage.

Observability

  • OpenTelemetry: Experimental OTel collection (apps/otel-collector) for SDK operations and platform traces
  • Audit logs: Platform-level audit log for compliance (mentioned in feature list)
  • Log streaming: sandbox.getLogs() API for agent output
  • Web terminal: Human-accessible terminal for inspection
  • VNC: GUI access for computer-use inspection

Git Automation

SDK exposes git operations (git.clone(), git.commit(), git.push()) that agents can call programmatically inside sandboxes. Daytona itself does not auto-commit or create PRs.

Webhook System

Daytona supports webhooks for lifecycle events (sandbox creation, deletion, status changes) enabling event-driven application architectures.

08

Ui Cli Surface

Daytona — UI & CLI Surface

CLI Binary

  • Binary name: daytona
  • Language: Go (in apps/cli)
  • Is thin wrapper: No — interfaces with Daytona REST API
  • Key subcommands: create, sandbox, snapshot management, key management, organization management (full list not enumerated in public README)

Local Web Dashboard

  • Exists: Yes
  • Type: Web dashboard (SPA)
  • Stack: React + Vite (in apps/dashboard)
  • URL: app.daytona.io/dashboard (managed) or self-hosted equivalent
  • Features: Visual sandbox management, create/start/stop/delete sandboxes, view logs, API key management, billing (managed), org management

Observability UI

  • Web terminal: Browser-based terminal access to sandbox
  • VNC access: Browser-based VNC for GUI/computer-use agents
  • Preview URLs: Port-forwarded preview for web apps running in sandbox
  • Custom preview proxy: Developer-facing proxy for custom routing

API

REST API with full OpenAPI spec. Available at:

  • Managed: https://app.daytona.io/api
  • Self-hosted: configurable endpoint

IDE Integration

None explicitly. The Daytona SDK is used programmatically from application code, not as an IDE extension.

Playground

A web-based "Playground" for trying sandbox operations interactively without writing SDK code. Accessible from the dashboard.

Related frameworks

same archetype · same primary tool · same memory type

CUA ★ 17k
A9 Sandbox substrate

Unified SDK for building, benchmarking, and deploying agents that interact with full OS GUIs via isolated VMs.

E2B ★ 12k
A9 Sandbox substrate

Run AI-generated code safely in cloud-hosted isolated sandboxes via a 3-line SDK integration.

OpenSandbox ★ 11k
A9 Sandbox substrate

Protocol-first general-purpose sandbox platform for AI applications with multi-language SDKs and pluggable isolation backends.

Microsandbox ★ 6.3k
A9 Sandbox substrate

Spawn hardware-isolated microVMs as child processes directly from application code, with no server setup, in under 100ms.

CubeSandbox ★ 5.9k
A9 Sandbox substrate

Sub-60ms KVM microVM sandboxes for AI agents with E2B drop-in compatibility and <5MB memory overhead.

sandcastle (mattpocock) ★ 5.1k
A9 Sandbox substrate

Container-isolated TypeScript SDK for orchestrating AI coding agents with Docker/Podman/Vercel Firecracker sandboxes and…