Daytona Went Closed-Source: What It Costs to Build Agent Sandboxes on Borrowed Open Source

In June 2026, Daytona — the $31M-funded company pitching "a computer for every agent" — moved its core development into a private codebase. The public repo is still there, frozen at v0.190.0 under AGPL-3.0, "as is and without support or warranty." If your agent-sandbox roadmap was built on that repo, here is the verdict up front: the frozen tree is now an unpatched dependency you maintain yourself, and the shortlist of replacements depends on exactly one question — where the sandbox runs. Laptop-scale development points to Microsandbox. Your own cluster points to E2B self-hosted or the kubernetes-sigs agent-sandbox. Need to keep calling the E2B API? That is CubeSandbox. And if your agents need GPUs, the whole table flips — only Beam's bring-your-own-cloud model survives contact with that requirement. This post shows the receipts: what froze, the three bills that just came due, and the full comparison.

What exactly froze​

Daytona's arc is a compressed version of the whole sandbox market. Founded in 2023 by Ivan Burazin, it raised a $5M seed in May 2024, went open source under Apache 2.0 to community applause, then raised a $24M Series A in February 2026 led by FirstMark (Matt Turck joined the board), reportedly hitting $1M in ARR in under three months. The product earned its reputation honestly: sub-90ms sandbox cold starts, OCI containers with optional Kata/Sysbox isolation, persistent stateful workspaces, SOC 2 Type II, MCP-native SDKs — and, per community benchmarks, a marquee demo of roughly 14,000 sandboxes in 7 minutes at MCP Academy Live in March 2026.

Then the timeline turns:

The reason given, per the project's own announcement trail, was security: AI-assisted exploit discovery against the public isolation code. That deserves to be taken at face value — a sandbox vendor whose isolation primitives are under automated adversarial review has a real problem that a web framework does not. The repo README says it plainly:

As of June 2026, Daytona's core development has moved to a private codebase. It remains public and free to use, fork, and build on under the LICENSE, as is and without support or warranty.

Note the license detail: the frozen tree is AGPL-3.0, not the Apache 2.0 the project launched with. That single fact determines most of what follows.

The three bills that just came due​

Freezing a repo does not freeze its costs. It transfers them to you. Three in particular:

1. The CVE bill: you now backport your own isolation patches. The last meaningful datapoint in the open tree is a patched sandbox-escape-class vulnerability (CVE-2026-31431, April 2026). Every future vulnerability in that isolation code — the exact code the vendor cited as the reason for going private — gets fixed in the private tree first, if at all, and never lands in v0.190.0. Running unpatched isolation primitives for untrusted AI-generated code is not technical debt; it is the one line item a sandbox exists to guarantee. A community fork (Nightona) exists, but a fork with no security team is a mirror, not a maintainer.

2. The drift bill: the hosted API walks away from the frozen release. Daytona still sells a managed cloud. Every new hosted feature — GPU sandboxes at $3.95/hr for an H100, new SDK surface, protocol changes — widens the gap between what daytona.io does and what your pinned v0.190.0 does. Code written against the hosted API quietly stops being portable to your self-hosted tree, and code written against your tree stops being able to migrate up. You did not just lose updates; you lost a shared interface.

3. The AGPL bill: the fork you maintain is network-copyleft. Under AGPL-3.0, offering the sandbox platform over a network obligates you to offer the complete corresponding source of your modified version to users. For a team embedding the frozen Daytona tree into a PaaS control plane, that means your sandbox layer's modifications — the exact layer where you will now be writing all your own security fixes — must be published. That is manageable, but it is a legal posture you must adopt deliberately, not discover during diligence. Contrast this with every alternative in the next section, which is Apache-2.0 or similarly permissive.

Total the three and the honest price of "just keep running the open Daytona" is: a self-maintained, AGPL-encumbered fork of isolation-critical code with no upstream security feed, drifting permanently away from the commercial API. Some teams will rationally pay it — the code works today — but it should be priced, not assumed.

The remaining self-hostable field​

Here is the field as of late 2026, configured the way a self-hoster would actually run each one — not the vendor's hero benchmark. The last column is the one the Daytona episode teaches you to read first: who can take it away from you.

Three things to read out of that table. First, the GPU row eliminates almost everybody: E2B's Firecracker architecture cannot do GPU passthrough at any tier, and Microsandbox has no GPU story — if your agents train, render, or run inference inside the sandbox, Beam's BYOC model is the only self-hostable answer, at less than half the hosted H100 rate (Beam $1.74/hr vs Modal and Daytona hosted at ~$3.95/hr). Second, "self-hostable" covers wildly different bills: Microsandbox is a binary on your machine, while E2B self-hosted means operating a Terraform-provisioned Nomad estate on a hyperscaler — one team's afternoon is another team's headcount. Third, the governance column is the actual hedge against a Daytona repeat: SIG-governed code cannot be taken private by a board decision, and a Tencent-scale backer fails differently than a Series A startup.

The honest footnote: every one of these except the SIG project carries some version of Daytona risk. E2B and Beam are venture-backed companies whose self-host paths exist at their discretion. CubeSandbox depends on one corporation's continued interest. Microsandbox is, today, roughly where Daytona was in 2024 — excellent software from a young company. Price that in.

Pick by constraint, not by logo​

Stop asking "which sandbox is best" and ask which constraint binds you:

• Constraint: laptop-scale agent dev, no ops budget. Pick Microsandbox. Apache-2.0, sub-200ms microVMs, a built-in MCP server, zero infrastructure. Accept the single-company risk with open eyes and keep your harness behind a thin interface so you can move.
• Constraint: production on a cluster you already operate. Pick the kubernetes-sigs agent-sandbox if you can live without E2B API compat — it inherits your nodes, your GPUs, your network policy, and no vendor can close it. If you need the E2B API, CubeSandbox is the only open runtime offering it; accept Tencent-concentration risk instead of startup-concentration risk.
• Constraint: agents need GPUs inside the sandbox. Pick Beam BYOC. Nothing else in the open field does self-hosted GPU sandboxes, and running them on your own cloud account means the vendor relationship is billing, not tenancy.
• Constraint: none of the above fits and you just need sandboxes tomorrow. Take the hosted-API fallback without shame: E2B Cloud or Daytona hosted. Over $289M in venture capital has poured into this layer (E2B $43.8M, Modal $80M+, Daytona $31M) precisely because hosted sandboxes are a good product. Just budget it as a vendor line with an exit plan, not as infrastructure you own.

And the structural hedge underneath all four: own the substrate, rent the sandbox. Standard Kubernetes, OCI images, ephemeral namespaces, gVisor or Kata runtimes, egress policy, TTL-based teardown — build your agent harness against a small sandbox-backend interface you define, so Daytona-today or Microsandbox-tomorrow are backends, not foundations. The teams hurt by June 2026 were not the ones using Daytona; they were the ones fused to it.

The pattern to name​

Daytona going private is not a scandal — a sandbox vendor protecting isolation code from automated exploit mining is defensible engineering. It is a pricing event: it revealed the true cost of building platform infrastructure on a single company's open repo, payable in CVE backports, API drift, and AGPL obligations. The broader market agrees the layer matters — agent infrastructure drew roughly $2.8B in the first half of 2025 alone. Mattering is exactly why you should own your piece of it: keep the sandbox behind your interface, on machines you control, under a license no board meeting can revoke.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.