Zeroboot: Copy-on-Write KVM Forks for Agent Code Execution

The problem: agent code execution is dominated by sandbox startup

An AI agent that writes code needs somewhere to run it. The usual answer is a container or a fresh microVM per task. Both carry a fixed cost before the first line of user code executes: the README's own comparison table puts E2B at roughly 150ms p50 spawn latency, microsandbox at roughly 200ms, and Daytona at roughly 27ms. When an agent makes dozens of small tool calls, that startup cost is paid over and over, and the memory footprint per sandbox (the README lists about 128MB for E2B and about 50MB for the others) caps how many can run at once. Zeroboot targets the case where the runtime is known in advance and the per-task code is short: boot the runtime once, snapshot it, then fork the snapshot for each task. The intended user is someone building an agent platform who is willing to run KVM hosts rather than call a hosted execution API.

How the fork primitive works, step by step

The README describes three stages. First, a template is built one time: Firecracker boots a VM, pre-loads the chosen runtime, and snapshots both memory and CPU state. Second, each fork creates a new KVM VM, maps the snapshot's memory with mmap(MAP_PRIVATE) so pages are shared until written, and restores the saved CPU state. The README puts that fork step at roughly 0.8ms. Third, isolation: every fork is a separate KVM VM, so memory isolation is enforced by hardware rather than by a userspace runtime. The data flow is one-directional at fork time. The child starts from an identical memory image and diverges only on write, which is why the README can claim about 265KB of memory per sandbox: most of the address space is still shared with the template. The single-vCPU constraint follows from this design, since restoring CPU state for one core is what the snapshot contains.

What the benchmark table does and does not establish

The README's table reports 0.79ms p50 and 1.74ms p99 spawn latency, about 8ms for a fork plus Python exec, and 815ms for 1000 concurrent forks. Those figures come from the project's own measurements, and the README labels the project a working prototype rather than a production-hardened system, so treat the numbers as the author's characterization of the fork path on the author's hardware. The comparison columns for E2B, microsandbox and Daytona are given as approximate single values with no methodology, no machine specification and no date, so the table is useful for order-of-magnitude context and not for procurement. What the table does make concrete is the shape of the trade: the gap is not a constant factor but roughly two orders of magnitude against the container-class tools, which is the entire reason to accept KVM host requirements and a single-vCPU limit.

Getting a sandbox running: the curl call and the SDKs

The fastest path in the README is the managed API, using the demo bearer token that ships in the documentation. The request body takes a code field and returns the execution result. The README also gives two SDK entry points. In Python, from zeroboot import Sandbox, then Sandbox("zb_live_your_key"), then sb.run("print(1 + 1)"). In TypeScript, import { Sandbox } from "@zeroboot/sdk", then await new Sandbox("zb_live_your_key").run("console.log(1+1)"). Note that the demo token is zb_demo_hn2026 while the SDK examples use a zb_live_ prefixed key, so the SDKs appear to expect a real key rather than the demo one. For self-hosting, the README says any Linux box with KVM works and points at docs/DEPLOYMENT.md and docs/ARCHITECTURE.md, but it does not reproduce the build or configuration commands in the README itself. That is a real gap for anyone evaluating self-hosting from the repository front page: you have to open the deployment guide to learn what the host needs.

Known limitations, and one that bites silently

The README lists four limitations, and they are not equally severe. The one worth reading twice is CSPRNG state. Forks inherit the snapshot's random number generator state, so two forks created from the same template can produce identical random output unless userspace libraries are reseeded. The README says kernel entropy is reseeded via RNDADDENTROPY but that userspace PRNGs such as numpy and OpenSSL need explicit reseeding per fork, and it links to Firecracker's own guidance on randomness for clones. In an agent setting this is a correctness and security issue, not a performance footnote: any generated token, key or sample drawn from a userspace PRNG inside a fork may repeat across forks. The other three are easier to reason about. One vCPU per fork rules out parallel workloads inside a single sandbox. No networking inside forks means the sandbox communicates over serial I/O only, so an agent that needs to call an API from inside the sandbox is the wrong fit. Template updates require a full re-snapshot of about 15s with no incremental patching, which is fine for a stable runtime image and painful for one that changes often.

Where Zeroboot is the wrong tool, and what to use instead

If your sandboxes need outbound network access, Zeroboot's serial-only I/O is a hard stop, and a container-based executor such as E2B or Daytona is the more direct choice: those run a general-purpose sandbox with networking, at the cost of the spawn latency the README's table reports. If your workload needs multiple cores inside one sandbox, the same applies, since multi-vCPU is described as architecturally possible but not implemented. The interesting middle case is Firecracker used directly without Zeroboot's fork layer. Firecracker already gives you KVM isolation and snapshot support; what Zeroboot adds is the copy-on-write fork path and the exec API on top. If you only need a handful of long-lived VMs, booting Firecracker yourself avoids depending on a prototype fork implementation and its reseeding caveats. If you need thousands of short-lived, single-threaded executions and you control the host kernel, the fork approach is the one that changes the cost structure rather than shaving it.

Maintenance, licensing and what to check before you commit

Zeroboot is Apache-2.0, which permits commercial use, modification and redistribution provided the license and notices are preserved; the repository ships a LICENSE file at the root. This is not legal advice, and if you plan to embed the fork path in a product, have counsel review the notice requirements. On maintenance, the project has no releases retrieved, so there is no tagged version to pin and no changelog to read; you would be tracking main. The README's own status line calls it a working prototype that is not production-hardened, and the author is building a managed service alongside it, which is worth weighing if you are deciding whether to depend on the self-hosted path long term. The practical checks are narrow: confirm your host exposes KVM, read docs/DEPLOYMENT.md for the actual host requirements, read docs/ARCHITECTURE.md for how reseeding is expected to work per fork, and run the exec call against your own build rather than the managed endpoint so you are testing the fork primitive and not the hosted service.

Editorial conclusion

Adopt Zeroboot if you need many short-lived, single-threaded Python or Node execution sandboxes and you control the host kernel, or if you want to evaluate the fork primitive before building your own. Do not adopt it if forks must reach the network, need more than one vCPU, or must be trusted with secrets that depend on a userspace CSPRNG. Before committing, verify the KVM host requirements in docs/DEPLOYMENT.md, read the reseeding guidance in docs/ARCHITECTURE.md, and run the curl exec call against your own build to confirm the fork path works on your hardware.

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. zerobootdev/zeroboot on GitHub