Skip to main content

Daytona Raised $24M in February, Then Closed Its Source in June: A Buy-vs-Build-vs-Fork Read on Agent Sandboxes

12 min readDora NodaDora Noda
Share
On this page

On February 5, 2026, Daytona announced a $24M Series A led by FirstMark Capital to build "agent-native compute": sandboxes that launch in milliseconds, fork into parallel branches, and snapshot mid-execution. On June 11, the same company moved its production codebase closed-source, freezing its public repository with a note that it "is no longer maintained."

Four months separated the funding announcement from the license funeral. That whiplash is the clearest single signal of what happened to the agent-sandbox tier in 2026: it fragmented instead of consolidating. No mergers, no shared standard — just vendors racing in opposite directions. OpenAI's April 2026 Agents SDK update blessed seven sandbox providers at once (Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel), and the Superagent 2026 benchmark now frames the open question directly: do sandboxes stay a discrete primitive, or get absorbed into the platforms above them?

For a team that wants agent sandboxes on machines it owns, that question is really three questions: which vendors are still openly self-hostable, what the license file plus the funding model jointly signal about staying that way, and what work you inherit the day you stop renting sandboxes. This post answers all three, with the scorecard first and the receipts after.

The self-hostability scorecard​

VendorLicense postureFunding signalSelf-host pathVerdict
E2BApache-2.0 runtime + infra$21M Series A (Insight, Jul 2025); ~$32M totalYes — self-hostable Firecracker runtimeBuy or self-host
DaytonaCore closed Jun 2026; frozen AGPL-3.0 repo$24M Series A (FirstMark, Feb 2026)Enterprise only; community fork existsBuy, or fork with care
ModalClosed engine, open client SDK only$355M Series C at $4.65B (May 2026)NoneBuy only
RunloopClosed (cloud Devboxes)$7M seedNone publicBuy only
microsandboxApache-2.0, self-hosted onlyIndependent / OSS-firstYes — microVMsSelf-host
Nightona / OpenSandboxAGPL-3.0 fork / OSS E2B-compatibleCommunityYes — youngFork if you can carry it

If you only read one section, read this table twice: the vendors most willing to sell you sandboxes are, with one big exception, the vendors least willing to let you run them yourself. The rest of this post is why that split happened and what it costs to cross it.

The money trail: four rounds, four theses​

The funding table looks like one hot category. Read the round theses and it is four different bets.

E2B: the usage-SaaS bet on an open runtime. E2B raised an $11.5M seed led by Decibel in October 2024, then a $21M Series A led by Insight Partners in July 2025, and reports 88% of the Fortune 100 signed up with hundreds of millions of sandbox sessions served. Sandbox volume grew from roughly 40,000 a month in March 2024 to about 15 million a month a year later — a ~375x ramp. The business model is usage on top of an Apache-2.0 runtime and infra: openness is the top of the funnel, metered Firecracker microVMs are the revenue. That is the only funding thesis in this tier where self-hostability is structurally aligned with the vendor's growth rather than tolerated despite it.

Daytona: the pivot bet. Daytona launched in 2023 as a self-hosted developer-workspace tool for human engineers, pivoted toward agent infrastructure through 2024, and raised its $24M Series A — FirstMark leading, with Pace Capital, Upfront Ventures, E2VC, Darkmode, and strategic checks from Datadog and Figma Ventures — to finish the turn. FirstMark's Matt Turck joined the board, and named customers include LangChain, Turing, Writer, and SambaNova.

The round funded "give every agent a computer," and the product delivered the category's most developed stop/archive/pause/fork lifecycle — forking a live VM with memory intact has no clean equivalent elsewhere. But a pivot round is a bet on velocity, and velocity is what the June closed-source move bought: fewer constraints, faster shipping, at the cost of the open-source safety valve.

Modal: the scale bet. Modal's $355M Series C at a $4.65B post-money valuation in May 2026, led by General Catalyst and Redpoint, came with roughly $300M in annualized revenue growing ~5x year over year — about 4x the $1.1B valuation of its September 2025 Series B. September reports put the company in talks for another ~$750M at roughly $15–16B. Modal builds every layer from scratch in Rust — filesystem, container runtime, scheduler, GPU memory snapshotting — and sells serverless GPU infrastructure where sandboxes sit next to inference and batch jobs on one platform. There is no self-host story because there was never meant to be one: the moat is the closed engine, and the valuation prices that moat, not openness.

Runloop: the enterprise wedge bet. Runloop's $7M seed funds Devboxes — suspend/resume, snapshots, blueprints, Axon observability — plus Public Benchmarks for standardized agent evals starting at $25. It is the youngest vendor here, aiming at the "production gap" between prototype agents and enterprise deployment. Nothing about a seed-stage enterprise wedge promises future self-hostability, and nothing has been offered.

License file × funding model: the joint signal​

Neither the license nor the cap table tells the story alone. Together they sort the tier cleanly.

E2B pairs Apache-2.0 code with usage-metered SaaS: the license removes adoption friction, the meter captures value from teams that would rather not operate Firecracker fleets. Self-hosting is a supported escape hatch, not a threat to the model. microsandbox is the purest version of the same shape — Apache-2.0, self-hosted only, 4,800+ GitHub stars — with a cloud service still in closed beta.

Daytona is the cautionary case. Its public code was AGPL-3.0 — strong copyleft with a network-use disclosure clause — and on June 11, 2026 the company announced core development was moving to a private codebase, stating plainly that "AI can now be pointed at an open source repository and systematically search it for exploitable flaws, at a speed and scale no human team can match." The public repo still exists at its last open release (v0.190.0) but is explicitly unmaintained, so "Daytona is open source" is now effectively deprecated OSS plus a closed cloud product.

The community answered with Nightona, a fork carrying v0.190.0 forward — but AGPL follows the fork, which means any platform building on it inherits copyleft obligations that Apache-2.0 alternatives simply do not impose. Forking Daytona's corpse is legally heavier than self-hosting E2B's living runtime.

Modal and Runloop need no license analysis: closed engine, closed cloud. Modal's client SDK is open; the thing that makes Modal Modal — the scheduler, the snapshotting, the GPU fabric — is not and, at a $4.65B valuation predicated on it, will not become open.

The joint rule of thumb: a vendor stays self-hostable only while openness is its growth engine. E2B's meter runs on top of open code, so openness compounds. Daytona's Series A priced pivot velocity, and velocity eventually priced out the commons. Modal's Series C priced a closed moat. Money does not lie about roadmaps; it just files them six months early.

The fork shelf: what you can actually self-host today​

Suppose you take the tier at its word and self-host. Four options are real, with honest caveats.

E2B's self-hosted runtime is the default answer: Apache-2.0, Firecracker microVMs (the same KVM-based virtualization AWS built for Lambda), SDKs in Python and JS/TS, and the only pause semantics in the category that keeps every sandbox's memory intact with no expiry. The maturity is proven by other people's production traffic — 15M sandbox runs a month flow through the architecture you would be operating. The caveat is operational, not legal: you inherit a Firecracker fleet to run.

microsandbox is the lightweight answer: Apache-2.0, self-hosted only, microVM-based, with SDKs in Python, JS, and Rust. It is the popular E2B alternative at laptop-to-small-cluster scale. The caveat is scope: it is a runtime, not a fleet — multi-tenancy, scheduling, and snapshot storage at scale are your design exercise.

Nightona is the Daytona-continuity answer: a community fork of Daytona v0.190.0 keeping a fully open sandbox alive and self-hostable. The caveat is double — a young community carrying a frozen codebase, under AGPL-3.0 copyleft that reaches across the network boundary.

OpenSandbox is the clean-room answer: turn ordinary Linux CPU machines into a self-hosted, E2B-compatible sandbox cluster with K3s plus gVisor, explicitly positioned for teams whose Daytona self-host path evaporated in June. The caveat is youth plus the gVisor-vs-microVM isolation tradeoff (gVisor is a user-space kernel, not hardware virtualization).

Notice what is missing: nobody on this shelf gives you Modal's GPU-adjacent sandboxing. That gap is the subject of the next section, and it is the expensive one.

The bill for leaving the cloud​

The day you stop renting sandboxes and schedule them on your own fleet — say, a Cluster-API-managed pool on Hetzner — you inherit three engineering problems the vendors currently absorb: GPU scheduling, snapshot storage, and the concurrency gap between marketing numbers and production reality.

GPU scheduling is newly tractable, not solved. Dynamic Resource Allocation went GA in Kubernetes 1.34, and at KubeCon Europe in Amsterdam in March 2026 both NVIDIA and Google donated their GPU and TPU DRA drivers to the CNCF, moving the reference implementations for structured, attribute-based accelerator scheduling into neutral governance. The KAI Scheduler — gang scheduling, topology-aware placement, DRA-native — entered CNCF Sandbox the same season.

That stack is what replaces the decade-old integer-count device-plugin hack (nvidia.com/gpu: 1) with fractional sharing, MIG partitions, and topology awareness. But "GA API plus donated drivers" is still a kit, not a product: on your own fleet you wire the DRA driver, the ResourceSlice plumbing, the scheduler, and the node-pool topology yourself, and nobody hands you Modal's GPU memory snapshotting. Budget a quarter, not a sprint, before a tenant's GPU-backed sandbox schedules onto spare VRAM instead of claiming a whole card.

Snapshot storage is the quiet cost center. The features that make sandboxes agent-shaped — pause with memory intact, fork mid-execution, resume after failure — are storage and memory-bandwidth problems wearing a product costume. E2B's no-expiry paused sandboxes and Daytona's fork-a-live-VM lifecycle both rest on snapshot infrastructure with real retention and restore-latency budgets. Self-hosting means sizing that storage, setting retention policy, and deciding what a snapshot restore is allowed to cost in seconds — before your first agent forks a hundred parallel branches and finds out for you. (Copy-on-write microVM forking exists in the open — forkd spawns children in ~100ms from a warm parent — but integrating it into a multi-tenant control plane is still your work.)

Concurrency is where marketing claims go to die. The Superagent 2026 benchmark reports Daytona at ~90ms cold start, E2B at ~150ms, Blaxel at ~25ms, and Modal at sub-second — but an independent late-August 2026 run under concurrent load measured Daytona at 0.27 seconds median time-to-interactive with only a 37% success rate at that concurrency, Modal at 0.88 seconds, and E2B at 1.61 seconds, noting explicitly that vendor claims are measured sequentially while real agent fleets launch sandboxes concurrently. A July 2026 practitioner roundtable confirmed Daytona's sub-90ms figure under benchmark conditions while one operator reported 2–5 seconds of cold-start latency per sandbox in production.

Normalized pricing, meanwhile, spreads less than the marketing suggests: E2B, Daytona, and Blaxel all land near $0.083/hour for 1 vCPU + 2GB, Modal near $0.12, Vercel near $0.15. When you build your own capacity plan, benchmark concurrency, not brochures — the fleet you operate will be judged on the 37%-success-rate curve, not the 90ms headline.

The verdict: buy, build, or fork — by workload​

There is no single answer, but there is a single decision procedure. Split by workload, because the tier already split by workload (and if your decision is between hosted PaaS sandboxes rather than self-hosting, our Railway-vs-Sprites pricing teardown works the per-hour math for that side):

  • CPU code execution (the common case): fork. Self-host E2B's Apache-2.0 runtime or microsandbox on your own nodes. The isolation primitive (Firecracker/libkrun microVMs) is proven, the license is permissive, and the ~$0.083/hour meter you stop paying is pure margin once your fleet exists. Revisit if your sandbox volume drops below the cost of operating the fleet.
  • GPU-adjacent sandboxes (inference, RL, training-adjacent): buy — from Modal. No open option reproduces closed-engine GPU snapshotting and scheduling today. Rent Modal's sandbox tier while tracking the CNCF DRA stack (drivers, KAI) toward the quarter you can credibly schedule fractional GPUs yourself. The Superagent benchmark's own recommendation agrees: Modal or Beam where GPU work happens on the sandbox side of the wire.
  • Eval-heavy agent development (benchmarks, RL environments): buy — from Runloop or E2B. Standardized eval harnesses and snapshot-heavy iteration loops are the vendors' home turf; rebuilding Public Benchmarks or E2B's pause semantics before you have agent volume is premature infrastructure.
  • Everything else, or if Daytona was your plan: fork with eyes open. Nightona or OpenSandbox can carry a Daytona-shaped workload, but budget maintainer time the way you would budget a dependency on a pre-1.0 framework — because that is what a community fork of a frozen codebase is.

And the meta-verdict: re-run this scorecard every two quarters. A tier where one vendor goes from $24M Series A to closed-source in four months is a tier whose self-hostability column has a half-life. The license file tells you what you may do today; the funding model tells you what you will be allowed to do next year. Read both, in that order.

For the adjacent question — what agent sandboxes get right that agent-operated deploys still don't — see our October comparison of E2B vs Modal vs Daytona.

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 our roadmap exactly the way this post describes: fork the open runtimes, rent the closed GPUs, and keep the fleet yours. Star the repo on GitHub or deploy your first app today.

Related articles

Give your agents a chain backend

Autonomous agents hit RPC endpoints very differently than people do. See what bex router handles on their behalf.

Read the agents guide