forkd is a microVM sandbox runtime for AI agent fan-out scenarios, built on Firecracker. Its core mechanism is: the parent VM is started only once, imports the runtime environment (e.g., Python and its dependencies, a JIT-warmed JVM, loaded ML models), and is then paused to disk. Each child is an independent Firecracker process that mmaps the parent's memory image via MAP_PRIVATE, with copy-on-write implemented at the page level by the kernel, so children share the parent's resident memory until they diverge.
In terms of main capabilities, the official claim is that 100 children can be spawned from a hot parent in about 100ms, and a running VM can be BRANCHed in about 150ms. forkd also supports BRANCH: pausing a running sandbox, snapshotting its in-progress state, and resuming. v0.3.4 fixed a slow-path regression where repeatedly BRANCHing the same parent ballooned from 150ms to 2.7s. v0.4's live BRANCH compresses the source pause window from about 200ms (Diff) to 56ms p50 / 64ms p90 on a 1.5 GiB source; with wait: false the caller returns in about 70ms, and the background copy completes asynchronously. The CLI can pass --live / --no-wait, REST can pass mode: "live" / wait: false, and the Python / TypeScript / MCP SDKs support it as well. v0.5 introduces diff snapshot chains, where each layer records a parent_tag + content hash edge, and the daemon traverses the chain at spawn time and assembles the memory image in one pass.
Isolation and inheritance characteristics: each child is an independent Firecracker microVM backed by KVM, and escape requires a hypervisor or kernel vulnerability; work already done by the parent, such as imports, JIT compilation, model weights, and prefetch caches, is inherited by children for free; each child has a real Linux environment, supporting multiple vCPUs, full TCP networking, apt install, and outbound HTTPS; multi-tenancy is implemented through per-child network namespaces, per-child cgroup v2 memory limits, and an independent /dev/urandom reseeded by vmgenid (Linux 5.20+).
In terms of usage, quickstart preflights the host (KVM, Firecracker, kernel image), asks what to set up (guest kernel download, tap device, per-child netns, and will not do so without consent or --yes), bakes a Python snapshot from python:3.12-slim (or pulls a pre-baked snapshot from the hub), then forks 10 microVM children from it and prints the time taken for each child; the command is idempotent, and repeated runs reuse the snapshot and skip completed setup. forkd doctor runs 17 checks (KVM, hardware virtualization, cgroup v2, IP forward, tap, netns, Firecracker binary and version, Docker daemon, snapshot directory and disk, etc.). Running requires x86_64 Linux with KVM, Ubuntu 22.04 or newer, Linux ≥ 5.7, vm.unprivileged_userfaultfd=1 (or CAP_SYS_PTRACE), and the vendored Firecracker fork from deeplethe/firecracker:forkd-v0.4-mem-backend-shared-v1.12; forkd doctor probes both of these.
Applicable scenarios include: code interpreters and Jupyter-kernel sandboxes; evaluation harnesses (such as SWE-bench-style parallel repository checkouts or test rollouts); large-scale per-user code execution; untrusted code execution in CI; self-hosted alternatives to managed sandbox SaaS; and integration with LangGraph / AutoGen / CrewAI via the Python SDK, or with Claude Desktop / Claude Code / Cursor / Cline via the MCP server provided by pip install forkd-mcp. Production case shapes include AI code interpreters, SWE-bench-style parallel evaluation, large-scale per-user code execution, untrusted CI, and fork-per-test isolated databases.
The enterprise deployment FAQ mentTo: deployable on Kubernetes, one forkd-controller Pod hosts N sandbox child nodes, requiring nodes with /dev/kvm + cgroup v2; with a 512 MiB prewarmed Python+numpy parent node, roughly 1 active running agent per vCPU, and roughly 50 idle pooled agents per 8 GiB Pod RAM; at N=100 the CoW overhead is 0.12 MiB per child node. The REST interface is POST /v1/sandboxes n=100, and the Python SDK allows from forkd import Sandbox. In terms of limitations, function-level snapshot runtimes are an order of magnitude faster than forkd's roughly 100 ms at the cost of giving up a real Linux (single vCPU, serial I/O); snapshots are not portable across Firecracker versions or host CPU microarchitectures; heavier parent nodes (browser, ML inference) will hit the ceiling sooner.
