Beam's Beta9 Is the Only Self-Hostable E2B Alternative Left Standing

E2B and Daytona's AI-agent sandbox pricing converged on the exact same number in 2026: $0.0504 per vCPU-hour, $0.0162 per GiB-hour. A price war that ends in a tie usually means the metered layer got commoditized. It also means price stopped being the thing that separates these vendors — and the thing that took its place is a lot less flattering for two of the three.

Weeks after that price parity became common knowledge, Daytona announced it's moving its production codebase to a private repository, citing security as the reason. The public daytonaio/daytona repo — 5.6k forks deep — stays up, but gets no further updates, fixes, or releases. E2B's e2b-dev/infra is still open (Apache 2.0), but self-hosting it means standing up a scaled-down copy of E2B's own production stack: Terraform, Nomad, Consul, a minimum 24 CPUs and 2,500GB of SSD, and Firecracker microVMs that need bare-metal or nested-virtualization access GCP is the only fully supported target for. That leaves Beam Cloud's open-source engine, Beta9 (AGPL-3.0), as the one sandbox runtime in this category you can helm install into a Kubernetes cluster you already run, on hardware you already own, that's still getting commits as recently as July 6, 2026.

The Price War That Ended in a Tie​

The numbers are worth stating plainly, because they're the premise the rest of this piece argues past. Both E2B and Daytona bill AI-agent sandbox compute at $0.0504 per vCPU-hour and $0.0162 per GiB-hour — not "similar," the same figure to four significant digits. That kind of convergence in a still-young market is what happens when a metered resource stops being a place either vendor can win: undercut the other by a cent and margin goes negative before volume makes up the difference.

What it means for a buyer evaluating sandbox vendors on price alone is that price alone no longer tells you anything. Two vendors billing identically for the metered layer forces the actual decision down into what price can't capture — deployment model, isolation guarantees, and whether the thing you're renting today is still a thing you can run yourself tomorrow if the vendor's roadmap stops matching yours.

Three "Open Source" Sandboxes, Now Down to One​

That last question used to have three plausible answers. As of mid-2026, it has one.

Daytona's move is the one that changes the category, not a footnote to it. A frozen repo with 5.6k forks doesn't get CVE patches, doesn't track new Kubernetes API versions, and doesn't get the next isolation-runtime improvement — it's a snapshot, not a foundation. Anyone who picked Daytona for its self-hosting story inherited that snapshot the day the announcement went out, whether they'd deployed yet or not.

E2B's repo is still genuinely open and still gets real engineering, but "open source" and "easy to self-host" aren't the same claim. E2B's Terraform and Packer tooling exists to reproduce E2B's own production topology — a GCP-primary deployment orchestrated by Nomad and Consul, gated behind a 24-CPU/2,500GB minimum quota, requiring the kind of bare-metal or nested-virtualization access most managed Kubernetes offerings don't hand out by default because Firecracker needs a hardware-level KVM boundary to boot. AWS support is in beta. Azure and generic bare-metal Linux are "planned." None of that is a knock on E2B's engineering — it's an accurate description of what "self-host E2B" actually requires, and it's a materially higher bar than a Helm install into infrastructure a team already operates.

Beta9 is the one built to be dropped into someone else's cluster rather than to reproduce its own. It ships as a Helm chart for any existing Kubernetes cluster and lists AWS, GCP, Azure, and Hetzner as supported targets alongside bringing your own hardware outright — Hetzner support in particular puts it in the same infrastructure lane as a self-hosted PaaS already running a Cluster API-provisioned fleet on owned bare metal, not a hyperscaler-shaped stack that happens to also technically run elsewhere.

What Beta9 Actually Trades for Sub-Second Cold Starts​

Beta9 doesn't win this comparison by copying E2B's architecture cheaper — it uses a different isolation runtime entirely, and that's a real tradeoff worth naming honestly rather than glossing over.

E2B's sandboxes run on Firecracker microVMs: each sandbox gets a dedicated kernel, hardware-enforced memory isolation via KVM, and a minimal attack surface (five emulated devices, roughly 50,000 lines of Rust). That's the strongest isolation boundary available short of a physically separate machine — and it costs roughly 125ms to boot a bare microVM, more once a large custom image has to be mounted into it.

Beta9 builds sandboxes on runc plus gVisor, Google's user-space kernel that intercepts syscalls between a container and the host rather than virtualizing hardware underneath it. That's a meaningfully thinner isolation boundary than a dedicated-kernel microVM — the workload still shares more of the host than a Firecracker guest does, and gVisor's syscall interception typically adds a 20–50% overhead on syscall-heavy workloads. What it buys back is speed: Beta9's lazy-loading container runtime launches sandboxes with custom dependencies in under a second, where a Firecracker-based platform mounting the same large custom image is measurably slower to boot.

Neither number makes the other wrong. A microVM's kernel-per-sandbox isolation is the right call for running fully untrusted, adversarial code with no other mitigations in place. gVisor's syscall interception is a legitimate, widely-deployed middle tier — the 2026 practitioner consensus is explicit that bare containers aren't enough isolation for AI-generated code, but it doesn't follow that only a full microVM clears the bar. The honest read is that Beta9 picked a real point on the isolation/speed curve, not a free lunch — and disclosed which point, which is more than most vendor pricing pages do.

What It Means for a Cluster API Fleet's Own Sandbox Roadmap​

For a self-hosted platform already running Kubernetes via Cluster API on owned Hetzner hardware, this changes what "add an E2B-style sandbox feature" actually means as a build-vs-adopt decision.

Renting metered sandbox time from E2B or Daytona was never structurally different from any other per-second-billed compute this list keeps recomputing against owned-hardware economics — the sandbox itself runs on someone else's fleet, at someone else's price, subject to someone else's roadmap. Daytona's closed-source pivot is the concrete version of the risk that was always implicit in that arrangement: the thing a team picked specifically because it was self-hostable stopped being maintained as open source with a single blog post.

Adopting E2B's own self-host stack outright doesn't fix that dependency, it just relocates it — a team now operates Terraform, Nomad, and Consul as a second orchestration system running alongside the Kubernetes-and-Cluster-API stack it already runs everything else on, sized to E2B's GCP-shaped minimums rather than to the fleet it's actually running on Hetzner.

Beta9 is the one option that fits the shape of infrastructure a Cluster-API-based platform already has: Helm into an existing cluster, native Hetzner support, no second orchestrator to stand up next to the first one. That doesn't mean adopting Beta9 wholesale is automatically the right call — a platform that already runs gVisor or Kata for tenant workload isolation elsewhere in the cluster may prefer to reuse that shared isolation layer directly rather than take on Beta9 as a dependency with its own upgrade cadence and AGPL obligations. But as a reference architecture for what an AI-agent sandbox feature should look like when it's built to run on infrastructure a team owns instead of infrastructure it rents — Kubernetes-native, multi-cloud including bare metal, and actually shipping — it's the most credible open-source example standing once Daytona took itself out of the running.

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.

Sources​

• Daytona: Daytona is going closed source. Here's why.
• GitHub - daytonaio/daytona
• GitHub - e2b-dev/infra: Infrastructure that's powering E2B Cloud
• E2B infra self-host.md
• GitHub - beam-cloud/beta9: Ultrafast serverless GPU inference, sandboxes, and background jobs
• Beam: How to Self-Host a Code Execution Sandbox for AI Agents (2026)
• Beam: E2B Pricing Explained (2026)
• Northflank: Firecracker vs gVisor — Which isolation technology should you use?
• Northflank: How to sandbox AI agents in 2026 — MicroVMs, gVisor & isolation strategies