Overview
Daytona is sandboxed, long-running agent infrastructure: secure, persistent, isolated execution environments for AI agents that need to run for hours or days rather than seconds. On October 24, 2026 it raised a $60M Series B at a $1B valuation — the clearest venture signal yet that agent infrastructure is its own investment category. Daytona provisions sandboxes in seconds via API/SDK, keeps them alive for 24-hour-plus task horizons (matching harnesses like Notion's sixth-generation agent harness), snapshots and restores full environments mid-task, and enforces per-sandbox filesystem/process/network isolation with egress policy controls. Grew out of the open-source Daytona dev-environment project and is compatible with the OpenSandbox interface line donated by Alibaba to the Agentic AI Foundation in October 2026. Python and TypeScript SDKs; self-hostable open-source core.
Features
- ✓Fast sandbox provisioning via API and Python/TypeScript SDKs
- ✓Long-running persistence — environments alive for hours or days
- ✓Snapshots and restore — checkpoint, resume, or fork entire environments
- ✓Per-sandbox filesystem, process, and network isolation with egress policy
- ✓Any toolchain inside — runtimes, browsers, databases, MCP servers
- ✓Multi-runtime support (containers and microVMs)
- ✓OpenSandbox-interface compatible (Agentic AI Foundation governance)
- ✓Per-sandbox usage metering for agent cost attribution
Installation
pip install daytona-sdk # or npm install @daytonaio/sdk; self-host via github.com/daytonaio/daytonaPros
- +Purpose-built for long-running agent work — persistence measured in days
- +Strong isolation with per-sandbox network egress policy
- +Snapshots give environments the same durability agents have
- +$1B-valuation capitalization plus an open-source core de-risks the substrate choice
Cons
- −Another infrastructure layer to operate at scale
- −Fleets of 24-hour sandboxes compound cost quickly
- −Category is young — OpenSandbox governance consolidation just happened in October 2026
Alternatives
Documentation
Daytona
Overview
Daytona is sandboxed, long-running agent infrastructure — secure, persistent, isolated execution environments for AI agents that need to run for hours or days rather than seconds. On October 24, 2026, Daytona announced a $60M Series B at a $1B valuation, the clearest venture signal yet that "agent infrastructure" is being capitalized as its own category, distinct from model providers, agent frameworks, and observability tooling.
Daytona's thesis maps directly onto the 2026 agent wave: as agents moved from chat (seconds) to workflows (minutes) to harnesses that run past 24 hours — Notion's sixth-generation agent harness being the reference example — the execution substrate became the bottleneck. Agents doing real work need environments with filesystems, installed toolchains, network policy, and state that persist across the full task horizon, isolated from each other and from host infrastructure. Daytona provides exactly that: provision a sandbox in seconds, hand it to an agent, keep it alive for the task's duration, snapshot it, and tear it down.
The company grew out of the open-source Daytona dev-environment project and has repositioned through 2026 as the compute substrate for coding agents, browser agents, and long-horizon autonomous workflows. With OpenSandbox (the sandboxed-execution standard donated by Alibaba to the Agentic AI Foundation in October 2026) consolidating the interface layer, Daytona is the best-funded implementation of the pattern.
Features
- Fast sandbox provisioning — isolated environments ready in seconds via API or SDK
- Long-running persistence — environments stay alive for hours or days, matching 24-hour-plus agent harnesses
- Snapshots and restore — checkpoint an environment mid-task, resume or fork it later
- Secure isolation — filesystem, network, and process isolation per sandbox; no cross-agent leakage
- Network policy controls — egress allowlists/denylists per sandbox, aligned with enterprise exfiltration requirements
- Any toolchain inside — install language runtimes, browsers, databases, or MCP servers inside the sandbox
- Multi-runtime support — containers and microVMs with different isolation/latency tradeoffs
- API and SDK access — Python and TypeScript SDKs; provision and manage sandboxes programmatically
- Standard-aligned interfaces — compatible with the OpenSandbox interface line now under Agentic AI Foundation governance
- Usage metering — per-sandbox resource accounting for the two-tier credit and metering models agents now run under
Installation
# Python SDK
pip install daytona-sdk
# TypeScript SDK
npm install @daytonaio/sdk
# Or run the open-source core self-hosted
git clone https://github.com/daytonaio/daytona
cd daytona && ./install.sh
Quick Start
from daytona import Daytona
daytona = Daytona()
# Provision a sandbox for a long-running coding agent
sandbox = daytona.create({
"language": "python",
"snapshot": "python-toolchain-base", # prebuilt toolchain image
"timeout": 86400, # alive up to 24 hours
"network_policy": {
"egress": {"allow": ["pypi.org", "github.com"]}
},
})
# Execute work inside the isolated environment
response = sandbox.process.code_run("""
import subprocess
result = subprocess.run(["pytest", "-q"], capture_output=True, text=True)
print(result.stdout[-2000:])
""")
print(response.result)
# Snapshot mid-task, then resume later or fork for a parallel variant
snapshot = sandbox.snapshot()
resumed = daytona.restore(snapshot.id)
Core Concepts
The Sandbox as the Agent's Computer
The unit of abstraction is a full environment, not a function invocation. Each sandbox has a filesystem, installed packages, running processes, and network posture — an agent working inside it can edit files, run tests, restart servers, and come back tomorrow to continue. This is the difference between serverless tool calls (stateless, seconds) and agent work (stateful, days): the sandbox is the computer the agent owns for the task's duration.
Snapshots: Durability for Environments
Checkpoints capture the entire environment — filesystem state, installed toolchain, running-process context — and can be restored or forked. Combined with agent-level durability primitives (TanStack AI's checkpointed agent state, for example), this closes the durability gap end to end: the agent's mind and the agent's computer can both be paused and resumed.
Isolation as Policy
Every sandbox is isolated at filesystem, network, and process level, with egress policy per environment. For enterprises running agent fleets against production-adjacent data, per-sandbox network allowlists are the enforcement point for the exfiltration controls that frameworks like AgentGuard specify at the policy layer — Daytona enforces them at the substrate.
The Metering Layer
Agent economics in 2026 is a metering and routing problem (Gartner's fivefold cost forecast being the reference), and Daytona's per-sandbox resource accounting feeds directly into the two-tier credit models that platforms like Notion introduced. Infrastructure that can attribute cost per sandbox makes the 2027 agent bill auditable.
Advanced Features
Coding-Agent Integration
# Typical pattern: pair an agent framework with a Daytona sandbox
from daytona import Daytona
from openai import OpenAI
daytona = Daytona()
sandbox = daytona.create({"snapshot": "node22-toolchain", "timeout": 3600})
client = OpenAI()
tools = [{
"type": "function",
"function": {
"name": "run_in_sandbox",
"description": "Run a shell command in the project sandbox",
"parameters": {"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"]},
},
}]
def run_in_sandbox(cmd: str) -> str:
out = sandbox.process.exec(cmd)
return out.stdout[-4000:]
Browser Agents
Sandboxes ship with headless-browser-capable images, giving browser agents an isolated, network-scoped environment — the execution half of the browser-agent pattern that Playwright MCP and agent-browser occupy at the tool layer.
Multi-Agent Fleets
Each agent gets its own sandbox; fleets run in parallel with per-agent network policy, per-sandbox cost attribution, and centralized snapshot management. Cross-agent coordination happens through your orchestration layer (LangGraph, CrewAI, AutoGen); Daytona stays out of the agent's way and manages its computers.
Examples
- Autonomous coding agent — 24-hour repository refactor: sandbox with toolchain, snapshot checkpoints after each milestone, restore on failure
- Security-research agent — sandbox with strict egress allowlist running multi-step vulnerability investigation (the VulnLoc-style multi-step pattern)
- Data-pipeline agent — long-running transformation with database installed in-sandbox, results extracted at completion
- QA swarm — forked sandbox snapshots running test variants in parallel
Pros
- ✅ Purpose-built for long-running agent work — persistence measured in days, not request lifetimes
- ✅ Strong isolation with per-sandbox network policy, matching enterprise exfiltration requirements
- ✅ Snapshots give environments the same durability agents themselves now have
- ✅ $1B-valuation capitalization and an open-source core de-risk the substrate choice
- ✅ Alignment with the OpenSandbox standard reduces interface lock-in
Cons
- ❌ Another infrastructure layer to operate — self-hosting the full feature set (multi-runtime, snapshots at scale) is real ops work
- ❌ Cost model is usage-heavy; fleets of 24-hour sandboxes compound quickly (though meterable)
- ❌ The category is young — the OpenSandbox governance consolidation just happened in October 2026
- ❌ Overkill for stateless, seconds-scale tool calls; use it when agents genuinely run long
When to Use
- Your agents run for hours or days and need a persistent, isolated computer (coding, research, QA, data pipelines)
- You're building the execution layer under a long-running harness (Notion-style) and need snapshots, restore, and per-agent isolation
- Security posture requires per-agent network egress control at the substrate
- You need per-sandbox cost attribution for metered agent billing
