What Is Daytona? Agent-Native Sandbox Infrastructure Explained

Daytona is a managed sandbox platform purpose-built for AI agents — it provides isolated, stateful compute environments that agents can spin up, execute code in, snapshot, fork, and destroy without managing container lifecycle manually. Unlike generic cloud VMs or developer-oriented cloud IDEs, Daytona is engineered around the agent execution model: fast cold starts, persistent state between tool calls, and native SDK support for Python, TypeScript, Ruby, and Go. Founded in 2023 by Ivan Burazin, Vedran Jukic, and Goran Draganic — the team that built Codeanywhere, one of the earliest cloud development platforms — Daytona raised a $24M Series A in February 2026 led by FirstMark Capital, with Pace Capital, Upfront Ventures, Datadog, and Figma Ventures participating. Customers include LangChain, Turing, Writer, SambaNova, and Fortune 100 enterprises. The platform reached $1M forward revenue run rate in under three months after launch, then doubled that figure six weeks later — a trajectory that validates the market need for agent-native compute infrastructure beyond what general-purpose Docker-based tooling provides.

Why “Agent-Native” Matters

Traditional sandboxes were designed for human developers: fire up a container, write some code, tear it down. AI agents work differently. A single agent run may involve dozens of tool calls, parallel exploration branches, and state that must persist across failures. Daytona’s sandbox lifecycle — Running → Stopped → Archived → Deleted — maps directly to these agent patterns. Sandboxes auto-stop after 15 minutes of inactivity and auto-archive after 7 days, so you pay only for active compute without manual cleanup. The result is infrastructure that behaves like a first-class agent runtime rather than a repurposed developer tool.

Sub-90ms Cold Start — How Daytona’s Architecture Achieves It

Daytona achieves sub-90ms cold starts — with production deployments reaching as low as 27ms — by using pre-warmed Docker containers with custom snapshotting rather than booting fresh VMs or containers from scratch on each request. When an agent needs a new sandbox, Daytona resumes from a pre-initialized snapshot rather than running a full container startup sequence, eliminating the kernel boot and process initialization phases that dominate traditional Docker cold start times. This architectural decision is the single most impactful differentiator in the current AI agent infrastructure landscape. For context: a Docker cold start typically takes 2–5 seconds per container; E2B’s Firecracker microVMs run at ~150ms; Daytona’s approach lands at sub-90ms measured p99, with 27ms achievable in optimized configurations. For an agent with 15 tool calls, Docker adds ~30 seconds of cold-start overhead per run. Daytona reduces this to ~1.3 seconds total — a 23x reduction in infrastructure latency that directly improves agent response times and reduces per-run compute costs.

Snapshot-and-Fork for Parallel Agent Exploration

Beyond raw cold start speed, Daytona supports forking an existing sandbox state into parallel branches — enabling multi-agent scenarios where different reasoning paths need isolated environments without re-running expensive setup steps. An agent can initialize a sandbox with dependencies installed and a codebase cloned, then fork that state across multiple parallel exploration threads. This pattern eliminates redundant setup work in tree-search or best-of-N agent architectures.

Native LSP and Tooling Support

Daytona sandboxes expose a Language Server Protocol (LSP) interface, enabling real-time code analysis — completions, diagnostics, go-to-definition — inside agent sandboxes without additional configuration. This matters for coding agents that need to understand code structure, not just execute it. Agents building or refactoring code can query type information and resolve symbols without spawning a separate analysis process.

Core Use Cases: Code Execution, Computer Use, and Reinforcement Learning

Daytona addresses three distinct deployment patterns for AI agent infrastructure, each requiring different sandbox capabilities. The platform’s architecture supports all three without requiring separate infrastructure choices for each use case, which reduces operational complexity for teams building multi-modal agent systems. Code execution is the primary use case and the one Daytona’s latency story directly addresses — agents that write and run code as part of their tool-call loop benefit most from sub-90ms startup times. Computer use extends sandboxes to full Linux, macOS, and Windows desktop environments, allowing agents to interact with GUI applications, browsers, and desktop software. Reinforcement learning training environments benefit from Daytona’s forking and snapshot capabilities: each RL rollout can start from a consistent forked state, ensuring environment determinism without container re-initialization overhead. These three pillars position Daytona as a general-purpose agent runtime rather than a narrow code execution service — an important distinction as agent workloads diversify beyond pure code generation tasks.

Code Execution Agents

For coding agents — the most common production use case today — Daytona provides the full environment lifecycle: create a sandbox with a specific base image, install dependencies, execute code, capture output, persist state, and return results to the orchestrator. The Python and TypeScript SDKs expose this lifecycle cleanly, with async support for non-blocking execution in agent loops.

Computer Use Agents

Computer use sandboxes expose VNC or browser-accessible desktops. Agents can interact with GUI applications, run browser automation, test web UIs, or perform tasks that require visual input. Daytona handles the display server configuration, window management, and screenshot capture pipeline — the agent receives screen state and issues input events without managing the underlying infrastructure.

Reinforcement Learning Environments

RL training with Daytona uses the fork API to reset environments to a consistent initial state between episodes, eliminating the container restart overhead that normally dominates RL environment step times. Each rollout thread gets its own isolated sandbox forked from a shared baseline, supporting massively parallel training runs without per-episode cold starts.

Daytona SDK Walkthrough — Python, TypeScript, and LangChain Integration

Daytona publishes official SDKs for Python, TypeScript, Ruby, and Go, with LangChain packages on both npm and PyPI. The API surface is intentionally minimal: create a sandbox, run code, read files, expose ports, snapshot state. Here is a representative Python workflow that an agent might use per tool call:

from daytona_sdk import Daytona

daytona = Daytona()  # reads DAYTONA_API_KEY from env

# Create or resume a sandbox
sandbox = daytona.create()

# Execute arbitrary code inside the sandbox
result = sandbox.process.code_run("""
import subprocess
output = subprocess.check_output(['python3', '-c', 'print("hello from sandbox")'])
print(output.decode())
""")

print(result.result)

# Snapshot state for reuse
sandbox.stop()

The TypeScript SDK mirrors this interface with async/await:

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

const daytona = new Daytona();
const sandbox = await daytona.create();

const result = await sandbox.process.codeRun(`
const fs = require('fs');
fs.writeFileSync('/tmp/output.txt', 'agent output');
console.log('done');
`);

console.log(result.result);
await daytona.remove(sandbox);

LangChain Integration

Daytona publishes a langchain-daytona package on both npm and PyPI that wraps the sandbox SDK as a LangChain tool. Agents built with LangChain can add Daytona code execution as a tool without writing SDK glue code:

from langchain_daytona import DaytonaCodeExecutor
from langchain.agents import AgentExecutor

executor = DaytonaCodeExecutor()
# Use as a tool in any LangChain agent
tools = [executor.as_tool()]

OpenAI Agents SDK v2 (released April 2026) officially lists Daytona as one of seven supported native sandbox providers, alongside Blaxel, Cloudflare, E2B, Modal, Runloop, and Vercel — meaning Daytona sandboxes can be declared in the SDK’s sandbox configuration block without custom adapter code.

Claude and Multi-Agent Pipelines

For Claude-based agents, Daytona integrates via the standard Python or TypeScript SDK. The typical pattern wraps Daytona’s code_run as a tool definition in Claude’s tool-use API format, allowing Claude to request code execution and receive structured output. The stateful sandbox model is particularly well-suited to Claude’s multi-turn conversation structure: the sandbox persists across conversation turns, so Claude can build on previous execution state without re-initializing the environment.

Daytona vs E2B vs Modal: Head-to-Head Comparison

Daytona, E2B, and Modal represent the three dominant approaches to AI agent sandbox infrastructure in 2026, each with distinct architectural trade-offs. Daytona optimizes for cold start latency and operational simplicity using Docker containers with custom snapshotting; E2B prioritizes security isolation using Firecracker microVMs with dedicated kernel-per-session; Modal targets GPU-intensive workloads with gVisor-based isolation and native GPU passthrough. Choosing between them depends on your agent’s primary workload characteristics. For latency-sensitive agents making many short tool calls, Daytona wins. For agents handling untrusted user-provided code that requires hardware-level isolation, E2B’s microVM boundary is the right choice. For agents that need GPU access inside the sandbox — running local inference, fine-tuning, or GPU-accelerated computation — Modal is the only option among the three.

When E2B Wins

E2B’s Firecracker microVM provides a dedicated kernel per sandbox session — a hardware-level isolation boundary that Docker cannot match. For applications where sandboxes execute untrusted third-party or user-provided code, the microVM boundary is the appropriate security primitive. E2B also performs well for Python-heavy iterative agents where session state builds over many steps, as the persistent VM maintains Python process state efficiently. The $150/month Pro tier unlocks higher concurrency limits for production workloads.

When Modal Wins

Modal is the only sandbox platform supporting GPU workloads inside agent loops. If your agent pipeline requires GPU inference — running a local model, processing embeddings at scale, or training a small fine-tuned model — Modal is the clear choice. Modal uses gVisor for system call interception rather than full VM isolation, providing a middle ground between Docker’s performance and Firecracker’s security posture.

Pricing Breakdown: Pay-As-You-Go, Free Credits, and Self-Hosting Options

Daytona charges $0.0504 per vCPU-hour on a pay-as-you-go basis, matching E2B’s pricing at the same tier. New accounts receive $200 in free credits at signup; startup-tier credits up to $50,000 are available through Daytona’s startup program. This pricing model is transparent and predictable: a sandbox running for one hour on a 2-vCPU configuration costs $0.10, which covers thousands of individual tool-call executions given Daytona’s sub-90ms startup times and typical execution durations of under a second per call. The open-source AGPL-3.0 license enables a third cost path: self-hosted deployment on your own infrastructure. Unlike most competitors, Daytona does not gate self-hosting behind an enterprise contract — the full platform is available on GitHub and deployable on any Kubernetes or Docker environment. This matters for enterprises with data residency requirements, air-gapped deployments, or regulatory constraints that prohibit sending code to third-party managed services.

Total Cost of Ownership Comparison

For a team running 10,000 agent tool-call executions per day at 500ms average execution time with 2 vCPUs per sandbox:

• Daytona (cloud): ~$0.14/day ($5/month)
• E2B (cloud): ~$0.14/day ($5/month) + $150/month Pro for higher concurrency
• Self-hosted Daytona: Infrastructure cost only (cloud VM running 24/7 at ~2 vCPU = ~$50/month on major cloud providers)
• Docker on your own servers: $0 platform cost but 30x higher latency overhead

For most production agent workloads at moderate scale, Daytona’s cloud offering is the lowest total cost path. At high scale (millions of executions/month), self-hosted Daytona on reserved instances significantly undercuts managed cloud pricing.

Real-World Benchmarks: Latency, Throughput, and Agent Tool-Call Overhead

The clearest validation of Daytona’s performance claims comes from real migration data. Teams replacing Docker-based code execution with Daytona consistently report eliminating 2–5 seconds of cold start overhead per agent turn. Across a 15-tool-call agent run, Docker adds approximately 30 seconds of pure infrastructure latency; Daytona reduces this to ~1.3 seconds total — a 23x improvement that directly reduces wall-clock agent response time and LLM API costs (since faster execution means less time waiting on API round-trips). In the Superagent AI Code Sandbox Benchmark 2026, Daytona achieved 27ms cold starts in optimized production configurations and ranked first for latency-sensitive workloads. E2B averaged 150ms; Modal came in sub-second but higher than Daytona. For throughput, Daytona’s sandbox forking allows horizontal scaling without per-instance cold start penalties — a workload that requires 100 parallel sandboxes can fork from a single pre-initialized baseline rather than booting 100 fresh containers.

Benchmark Results Summary

These numbers reflect production workloads — not synthetic microbenchmarks with pre-warmed caches on dedicated hardware. Your results will vary based on image size, dependency installation, and network conditions, but the relative ordering is consistent across published benchmarks.

Security and Isolation: Docker-Based Sandboxing vs MicroVM Alternatives

Daytona uses Docker containers as its primary isolation layer, with optional support for Kata Containers and Sysbox as drop-in runtimes that provide stronger isolation guarantees. Standard Docker isolation provides namespace and cgroup-based separation — sufficient for trusted workloads where the code executing in the sandbox is generated by your own agent, not by end users. For threat models where the sandbox executes untrusted external code (user-submitted scripts, agent-generated code from untrusted prompt inputs), Kata Containers or Sysbox add a VM-backed isolation layer while preserving Docker’s operational model and most of its performance characteristics. Kata Containers uses lightweight VMs (QEMU or Firecracker) to provide kernel isolation, with cold start overhead of 50–150ms rather than microVM-only alternatives at 150ms+. Sysbox adds a custom OCI runtime that enables nested container execution and provides stronger isolation than standard Docker without the full VM boot cost. E2B’s Firecracker microVM provides a dedicated kernel per session — the strongest isolation primitive currently available in managed sandbox infrastructure — but at the cost of higher cold start latency (150ms vs Daytona’s 27ms in optimized configurations).

Security Posture Decision Tree

• Agent executes its own generated code, no user input reaches the sandbox: Standard Daytona Docker isolation is appropriate.
• Agent processes user-provided prompts that could influence code generation: Evaluate Daytona + Sysbox or E2B depending on latency tolerance.
• Sandbox directly executes untrusted user-submitted code: E2B’s microVM boundary is the correct choice.
• Compliance requires data never leaves your infrastructure: Self-hosted Daytona on your own cloud account.

Who Should Use Daytona? Strengths, Weaknesses, and Ideal Use Cases

Daytona is the best choice for teams building production AI agents where latency is the primary constraint and the code executing in sandboxes is generated by controlled agent pipelines rather than direct user input. The combination of sub-90ms cold starts, stateful persistence, forking for parallel execution, and open-source self-hosting covers the majority of enterprise agent deployment patterns. Daytona is particularly strong for teams that need to own their infrastructure — the AGPL-3.0 license and documented self-hosting path make it the only major sandbox platform that doesn’t require a managed cloud dependency. This is a decisive advantage for enterprises in regulated industries (financial services, healthcare, government) where data sovereignty requirements prohibit third-party code execution services. The main weaknesses are the Docker-based isolation model for high-security threat models, and the absence of GPU support for inference-heavy workloads. Teams building agents that need to run local LLMs or GPU-accelerated computation inside sandboxes must use Modal or provision GPU instances outside the Daytona sandbox boundary.

Ideal Use Case Matrix

Daytona Roadmap and 2026 Funding Momentum

Daytona’s $24M Series A (February 2026) positions the company to expand its infrastructure footprint and deepen framework integrations. The funding round’s composition — Datadog and Figma Ventures alongside traditional VCs — signals strategic interest from enterprise observability and design tooling ecosystems, suggesting upcoming integrations with monitoring and workflow platforms. Daytona reached $1M forward ARR within three months of launch and doubled that figure six weeks later, demonstrating product-market fit at a velocity rarely seen in infrastructure-layer companies. The Series A capital will fund three stated priorities: expanding the managed cloud infrastructure to reduce latency further, deepening SDK coverage for emerging agent frameworks, and building the enterprise security and compliance features (SOC 2, HIPAA readiness, private cloud deployments) required by Fortune 500 customers already in the pipeline. OpenAI’s official inclusion of Daytona in Agents SDK v2 as a supported native provider (April 2026) is a significant distribution catalyst — it means any team building on the OpenAI platform can adopt Daytona without custom integration work, accelerating enterprise adoption. With LangChain, Claude, Codex, and OpenCode integrations already published, and a growing list of Fortune 100 customers, Daytona is positioned as the infrastructure default for production agent deployments where latency and operational simplicity are the primary requirements.

FAQ

What is Daytona and what does it do? Daytona is an AI agent sandbox infrastructure platform that provides isolated code execution environments with sub-90ms cold starts. Agents can create sandboxes, execute code, persist state, fork parallel branches, and snapshot environments — all via Python, TypeScript, Ruby, or Go SDKs. It’s designed specifically for AI agent tool-call loops, not human developer workflows.

How fast is Daytona’s cold start compared to Docker and E2B? Daytona achieves sub-90ms cold starts, with optimized production configurations reaching 27ms. Standard Docker cold starts take 2–5 seconds; E2B’s Firecracker microVMs average ~150ms; Modal comes in sub-second. For a 15-tool-call agent run, Daytona reduces total cold-start overhead from ~30 seconds (Docker) to ~1.3 seconds.

Is Daytona open source and can I self-host it? Yes. Daytona is licensed under AGPL-3.0 and the full codebase is available on GitHub. Self-hosting on Kubernetes or Docker environments is supported without enterprise gating — a key differentiator from E2B and Modal, which are managed-cloud-only.

How does Daytona pricing compare to E2B? Both Daytona and E2B charge $0.0504/vCPU-hour at the base tier. Daytona gives new accounts $200 in free credits; E2B offers a $150/month Pro tier for higher concurrency. Startup credits up to $50,000 are available from Daytona’s startup program. For high-volume workloads, self-hosted Daytona on reserved instances typically costs less than either managed option.

When should I use E2B or Modal instead of Daytona? Use E2B when your sandboxes execute untrusted user-provided code that requires hardware-level isolation — E2B’s Firecracker microVM provides a dedicated kernel per session that Docker cannot match. Use Modal when your agent workload requires GPU access inside the sandbox for local inference, embedding generation, or fine-tuning. For all other production agent workloads, Daytona’s latency and self-hosting flexibility make it the default choice.