E2B vs Daytona vs Modal: Picking an Agent Sandbox You Can Self-Host

On April 15, 2026, agent sandboxing stopped being a DIY problem. That day's OpenAI Agents SDK release made sandboxes a native, first-class primitive: seven built-in providers — Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel — plus bring-your-own support and a workspace Manifest abstraction so the same agent definition runs against any of them. Swap provider="e2b" for provider="modal" and your agent's code execution moves clouds. For teams building agents, that is unambiguously good news. For teams building the platforms agents run on — especially platforms that own their machines — it raises a sharper question than "which provider": which of these primitives can you actually self-host, and what does each one cost you if you can't?

Here is the verdict up front, with the receipts below: integrate first, build later — and integrate against the open-source one. E2B is the default choice for a self-hosted PaaS roadmap: Firecracker microVMs at roughly 150-millisecond boot, Apache-2.0 licensed, with a documented self-host path. Daytona is technically the fastest and the most stateful, but its June 2026 move of core development to a private codebase is exactly the license rug-pull self-hosters must price in. Modal wins any GPU argument and loses every self-hosting argument — closed cloud, no self-host path, period. And the in-house option, Firecracker directly on your own metal, is genuinely buildable but buys you a second platform to operate; take it only when tenant demand outgrows what an integration serves.

The market in one table​

The table compresses several independent comparisons that converge on the same ranking: Qovery's 2026 seven-way comparison, community benchmark suites exercising all three providers against identical agent workloads, and competitive teardowns that name Daytona fastest, E2B and Daytona most comprehensive, and Modal best for GPUs. No single vendor tops every row — which is precisely why the choice is a roadmap decision, not a shopping decision.

April 2026: sandboxing became an interface​

Before walking the contenders, it is worth naming what actually changed in April, because it reframes the whole buy-vs-build calculus. The Agents SDK did four things at once: native sandbox execution, a Codex-style agent harness, snapshot/rehydrate lifecycle, and the provider integrations — with a Temporal extension shipping alongside so sandbox agents can run as durable workflows with session management. The Manifest abstraction is the quiet radical part: mount local files, define output directories, pull data from S3, GCS, Azure Blob, or Cloudflare storage — and that workspace description is portable across providers.

The honest caveat first: the market did not literally crystallize around three vendors. The SDK ships seven providers, and credible coverage also names Fly.io Sprites, Docker Sandboxes, Deno Sandbox, and Cloudflare's Sandbox SDK as serious entries. E2B, Modal, and Daytona are the three most-cited pure-plays — the ones every comparison table includes — but "crystallized" describes the interface (one SDK, swappable backends, portable manifests), not a three-vendor oligopoly. That distinction matters for the roadmap verdict: you are betting on an interface with a BYO escape hatch, not on a single vendor's survival.

The interface also surfaces the question marketing pages hide: who owns the sandbox lifecycle? E2B exposes Firecracker microVMs as an SDK primitive your app drives (Sandbox.create(), commands.run(), kill(), first-class pause()/resume()). Modal pools serverless containers the platform owns — you call a function, Modal decides where it lands. Daytona sits between: per-agent sandboxes with lifecycle management your platform orchestrates. For a PaaS, that ownership line determines how much of your control plane you are outsourcing with the choice.

E2B: the Firecracker default​

E2B is the reference implementation of the category: Firecracker microVMs, hardware-virtualized isolation, boot times in the 125–200ms band (commonly cited around 150ms from snapshot), and an SDK designed around the agent loop — create a sandbox, run commands, read/write files, pause when idle, resume in about a second with billing stopped while paused. Founded in 2023 by Vasek Mlejnsky and Tomas Valenta, the company raised an 11.5-million-dollar seed round led by Decibel to build what it calls an open-source runtime for executing AI-generated code.

For a self-hosting audience, the license line is the whole story: E2B is Apache-2.0 and openly self-hostable, with a Terraform/Nomad self-hosting path the community has documented and run. That makes it the only contender of the three a platform can adopt without adopting a vendor dependency — run their cloud while you are small, move the same primitive onto your own machines when the economics or data-residency story demands it, and never re-target your agents because the SDK interface is identical either way. The gaps are real but bounded: no GPU story (CPU-focused by design), and sandboxes that run up to 24 hours before disappearing, which suits ephemeral tool execution better than long-lived agent sessions. Neither gap is architectural — both are product scope — and neither blocks a PaaS whose first sandbox users are running code interpreters, not training runs.

Daytona: fastest and most stateful — read the license first​

On pure capability, Daytona arguably leads. Sandbox creation from a warm pool lands around 71ms with sub-90ms cold starts generally — the fastest boot in the category — and where E2B sandboxes are deliberately ephemeral, Daytona offers stateful sandboxes with unlimited persistence and snapshotting: pause a whole computer, snapshot it, resume it later. The company pivoted from dev environments to agent infrastructure in early 2025 and the bet paid off commercially: a 24-million-dollar Series A in February 2026 led by FirstMark (Matt Turck joined the board), 31 million dollars raised in total, and a claimed one-million-dollar ARR run-rate reached in under three months.

Then came June 2026, when Daytona moved its core development to a private codebase — the stated rationale being that a public sandbox implementation hands attackers a blueprint of the kernel boundary they are trying to break. The community response was immediate: Nightona, a community-maintained fork of the last open release (v0.190.0, AGPL-3.0), picked up the self-hostable torch. Whether you find the security rationale convincing or not — and reasonable operators disagree — the episode is the single most instructive event in this market for a self-hosting team. It demonstrates the exact failure mode of building a roadmap on someone else's open-source license: the code you run today can be the last open code you ever get, and your options at that point are a community fork of unknown velocity or a migration. Daytona-the-product remains excellent; Daytona-the-dependency now carries a risk premium E2B does not, and any integration decision should price it explicitly rather than discovering it mid-migration.

Modal: the GPU answer, and only the GPU answer​

Modal comes from the opposite direction: not a sandbox company that added compute, but a serverless GPU cloud that added a Sandboxes API. The isolation is gVisor (user-space kernel, weaker boundary than Firecracker microVMs but broader compatibility), cold starts run sub-second to a few seconds depending on image and region — noticeably slower than both rivals — and the numbers that matter are the GPU ones: H100, A100, H200, B200, L40S, A10, L4, T4, autoscaling from zero to over a thousand GPUs, per-second billing with 30 dollars a month in free credits, SOC 2 and HIPAA compliance. Customers running production agent workloads on it include names like Runway, Suno, and Cognition. If your tenant's agent needs a GPU — inference with a local model, a training loop, a vLLM fleet — E2B's CPU-only pool is out of the conversation entirely, and Daytona's younger GPU offering is narrower than Modal's T4-to-B200 lineup.

The cost is total platform dependence. Modal is closed cloud with no self-host story: no license to fork, no Terraform path, no BYO escape hatch beyond the Agents SDK's provider-swapping (which moves you to another vendor, not to your own metal). For a self-hosted PaaS this makes Modal a complement, never a foundation — the GPU offload target you integrate for the workloads your own hardware cannot serve, while the CPU sandbox primitive lives somewhere you control. That is a perfectly respectable architecture; it is just not a self-hosting story, and it should never be presented as one.

Build vs integrate: the roadmap decision​

Which leaves the real question: should a self-hosted PaaS build its own Firecracker-backed sandbox primitive, or integrate? Here is the honest accounting of what "build" entails on owned hardware:

• KVM-capable hosts. Firecracker needs /dev/kvm — bare metal or nested-virt-capable virtualization. Budget dedicated servers qualify; many shared cloud instances do not. Your fleet plan must put sandbox hosts on the right metal from day one.
• Snapshot, pause, and resume. The 150ms boot bar the market set is a snapshot-restore number, not a cold-boot number. Matching it means building template snapshotting, memory-state capture, and sub-second resume — solved problems (Firecracker supports all of them) but real engineering, not configuration.
• An API surface and template story. Sandbox.create() looks simple because E2B spent years on everything behind it: OCI-image-to-microVM conversion, filesystem overlays, networking and egress policy per sandbox, and a template registry.
• Multi-tenant hardening. Running untrusted, model-generated code from mutually untrusting tenants on shared hosts is the sharp end of the threat model. MicroVM boundaries, jailer configuration, seccomp, resource quotas, noisy-neighbor isolation, and abuse metering are all yours to build, audit, and keep patched.
• Metering and billing. Per-second billing with pause semantics has to be implemented, tested, and trusted before the first invoice.

None of that is exotic — it is roughly one senior infrastructure engineer for two quarters to reach E2B's 2024 feature level, and then a permanent maintenance tail every Firecracker CVE and kernel update. Against that, integration costs an afternoon (the SDK provider interface exists precisely to make it cheap) and defers every item above until tenant revenue justifies it. The rational sequence for a young platform is therefore: integrate E2B-compatible execution now (cloud-hosted E2B today, self-hosted E2B on your own metal when volume or residency demands it — same interface, no re-targeting), add Modal as the GPU offload the day a tenant needs accelerators, and revisit the in-house Firecracker build only when sandbox margin or control requirements exceed what the integration serves. Daytona's June reversal is the reason the first integration target should be the Apache-2.0 one: the whole point of "integrate first" collapses if your integration target can close its source mid-roadmap.

One more consideration for the build column, honestly stated: the Agents SDK's BYO-sandbox support means a future in-house primitive slots into the same interface your tenants already use. Building later does not mean migrating tenants later. That escape hatch — designed by OpenAI, of all vendors, to keep providers honest — is what makes "integrate first" a reversible decision instead of a trap. Use it as the forcing function: any integration that cannot be swapped for your own backend through the BYO interface is not an integration, it is a dependency wearing an interface costume.

The primitive grew up; the fine print matters more than ever​

Twelve months ago, giving an agent a computer meant hand-rolling Docker isolation and hoping your seccomp profile held. Today it is an SDK one-liner against a competitive, benchmarked, increasingly standardized market — Firecracker's ~125ms boot and sub-5MiB overhead made microVMs the default isolation technology, the Agents SDK made providers interchangeable, and the remaining differences (boot time, statefulness, GPUs, license) map cleanly onto different tenants' needs. That maturity is exactly why the fine print now dominates the decision: when every vendor's demo works, you choose on what survives contact with your roadmap — licenses, self-host paths, and who owns the lifecycle. Read those three rows of the table before the benchmark rows, and the market's crystallization becomes something you can build on rather than something you rent.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent sandboxes are on the roadmap as a first-class primitive: star the repo on GitHub and help shape what self-hosted agent execution looks like.