Zeroboot

Overview

Zeroboot takes a radically different approach to AI agent sandboxes: instead of booting VMs or starting containers, it forks them. A Firecracker microVM boots once, pre-loads a runtime (Python, Node, etc.), and snapshots its entire memory and CPU state. Each new sandbox is created by mapping that snapshot as copy-on-write memory and restoring CPU state into a new KVM VM — in 0.79ms.

Key stats (as of June 2026): 2,360 stars, 102 forks, Apache-2.0, Rust. Created March 15, 2026. Working prototype, not production-hardened — and no commits since March 21, 2026.

Status: stalled but not dead

The honest read as of June 11, 2026: all development happened in a six-day burst (March 15–21, 2026), and the repo has been silent since. There are no releases or tags, networking inside forks never shipped, and the managed API is still a waitlist signup form. Stars more than doubled (1,135 → 2,360) on the strength of the idea — the Show HN hit 311 points — but attention has not translated into continued development. The repo is not archived, and the demo API at api.zeroboot.dev still responds with healthy Python and Node templates, so the infrastructure is being kept alive. Funding is not publicly disclosed; no pricing has been published, though the maintainer said on Hacker News that the planned managed service would be usage-based.

---

How It Works

The architecture is elegantly simple:

1. Template (one-time, ~15s): Firecracker boots a VM, pre-loads your runtime and dependencies, snapshots memory + CPU state to disk
2. Fork (~0.8ms): Creates a new KVM VM, maps snapshot memory as MAP_PRIVATE (copy-on-write), restores all CPU registers
3. Execute: Fork runs agent code in complete isolation — separate KVM VM with hardware-enforced memory boundaries
4. Teardown: Fork is destroyed, CoW pages are freed

The key insight: most sandbox time is spent booting and loading runtimes. By snapshotting after boot and forking the result, Zeroboot eliminates that cost entirely. Each fork starts with a fully-initialized Python/Node environment ready to execute.

Benchmarks vs. Competitors

The memory numbers are the real story. At ~265KB per sandbox vs ~128MB for E2B, Zeroboot can run ~480x more sandboxes on the same hardware. This enables patterns that are economically impossible with traditional approaches — like forking a sandbox per function call or running thousands of concurrent agent evaluations.

---

SDKs

Python and TypeScript SDKs are available:

Python:

from zeroboot import Sandbox
sb = Sandbox("zb_live_your_key")
result = sb.run("print(1 + 1)")

TypeScript:

import { Sandbox } from "@zeroboot/sdk";
const result = await new Sandbox("zb_live_your_key").run("console.log(1+1)");

A demo API is live at api.zeroboot.dev with a public demo key (still responding as of June 11, 2026), plus an early-access waitlist for the managed service — which had not launched as of June 2026.

---

Known Limitations

The project is transparent about its constraints:

• CSPRNG reseeding: Forks share CSPRNG state from the snapshot. Kernel entropy is reseeded but userspace PRNGs (numpy, OpenSSL) need explicit reseeding per fork
• Single vCPU: Each fork gets one vCPU. Multi-vCPU is architecturally possible but not implemented
• No networking: Sandboxes communicate via serial I/O only — no outbound network access
• Template updates: Require full re-snapshot (~15s), no incremental patching
• Not production-hardened: Explicitly a working prototype

The no-networking constraint is notable — it makes Zeroboot ideal for pure computation (code execution, data processing) but unsuitable for agents that need to call APIs or fetch URLs from within the sandbox.

---

Competitive Position

Zeroboot enters the AI agent sandboxes market with a fundamentally different architecture. While E2B and Sprites use Firecracker for isolation, they still boot or restore full VMs. Zeroboot's CoW fork approach trades flexibility (no networking, single vCPU) for extreme speed and density.

The closest architectural parallel is Unix fork() — but applied to entire virtual machines instead of processes. This is a research-grade insight that could reshape how high-throughput agent workloads run.

Best for: Batch code execution, agent evaluation at scale, compute-heavy workloads that need massive concurrency with real isolation.

Not for: Agents that need network access, long-running sessions, or multi-core compute.

---

Strengths

• 190x faster spawns than the market leader (E2B) with real VM isolation
• ~480x memory density enables patterns impossible with traditional sandboxes
• Rust implementation with clean architecture and honest documentation
• Apache-2.0 license — fully open source, self-hostable
• Live demo API at api.zeroboot.dev, still responding as of June 2026 (managed service remains waitlist-only)

Weaknesses

• No networking — major limitation for many agent use cases
• Single vCPU — can't parallelize within a sandbox
• Working prototype — not production-hardened, unclear roadmap
• Development stalled — no commits since March 21, 2026; managed API still waitlist-only, no production users disclosed
• Template re-snapshot takes ~15s, limiting rapid iteration on environments

---

What Developers Say

The Show HN thread (311 points, March 2026) drew substantive engagement from sandbox builders:

"Nice to see this work! I experimented with this for exe.dev before we launched. The VM itself worked really well, but there was a lot of setup to get the networking functioning... I have seen several use cases where people want a VM for something minimal, like a python interpreter, and this is absolutely the sort of approach they should be using." — crawshaw, Hacker News

"I don't really love the idea of using VMs more, but I super love this project. Heck yes forking our processes/VMs." — jauntywundrkind, Hacker News

"More than the sub ms startup time the 258kb of ram per VM is huge." — vmg12, Hacker News

Third-party analysis has been positive on the architecture: Addo Zhang's March 2026 survey of agent sandboxes concluded that if Zeroboot matures, its CoW-fork approach could "fundamentally rewrite" the traditional trade-off between container performance and VM security — while flagging the same not-production-hardened caveat. No post-March community discussion of production usage was found, consistent with the development stall.

---

Bottom Line

Zeroboot is still the fastest sandbox runtime in the AI agent ecosystem by a wide margin — 0.79ms spawn latency with real KVM isolation is a genuine breakthrough, and the CoW fork architecture remains architecturally unique. But three months after launch, the picture has shifted from "extremely early" to "stalled": no commits since March 21, 2026, no releases, no networking, and a managed API that never left the waitlist.

Recommended for: Researchers and infrastructure builders studying the CoW-fork technique — the code is Apache-2.0 and the idea is sound. Self-hosters running batch, network-free code execution who can accept prototype-grade software.

Not recommended for: Any production agent workload. The development stall, missing networking, and absent managed service make E2B, Daytona, or Sprites the practical choices.

Outlook: The idea earned real attention (311-point Show HN, stars doubling to 2,360 with zero new code) and the demo API is still being kept alive, so a revival or acqui-hire is plausible. But until commits resume or the managed service ships, treat Zeroboot as a published proof of concept, not a product.