forkd vs superserve
fork() for agent microVMs: children fork copy-on-write from a warm Firecracker parent — 100 KVM-isolated VMs in ~100ms, live-VM branching in ~56ms, portable snapshots from a hub. — versus — Persistent, secure sandboxes for AI agents on Firecracker microVMs — TypeScript and Python SDKs, CLI and console; the runtime is a hosted service, the SDK stack is Apache-2.0.
Both give agents Firecracker microVMs; superserve sells persistent, SDK-driven sandboxes, forkd sells copy-on-write forks off a warm parent for throwaway fan-out.
| forkd | superserve | |
|---|---|---|
| Stars | 3.0k | 474 |
| Forks | 273 | 54 |
| Language | Rust | TypeScript |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | today | today |
| Topics | sandboxes, agents, local | sandboxes, agents |
| Curated connections | 5 | 5 |
forkd — the curator's take
The sandbox primitive agent fan-out actually wants: instead of cold-booting a kernel per child, a parent VM boots once with your runtime warm (deps imported, model loaded, JVM JITed) and children mmap its memory copy-on-write — so spawning 100 isolated environments costs ~100ms, and v0.4 can BRANCH a live running VM. Tree-search agents, parallel experiment runners and RL rollouts are the natural fits. NOT a managed platform: Linux/KVM only, you operate it, and there's no E2B-style API compatibility — this is a runtime primitive you build on, not a sandbox service you call.
superserve — the curator's take
The pitch is persistence: sandboxes that survive between agent runs instead of being disposable, on Firecracker isolation. Know what the repo is before starring: this is the SDK/CLI/console monorepo — the actual sandbox runtime lives behind the hosted service at superserve.ai, and the README is a contributor doc, not a product doc (the substance is at docs.superserve.ai). Use it when you want managed microVM sandboxes with a clean SDK and don't want to run KVM hosts; NOT for air-gapped or self-hosted requirements — that's CubeSandbox's territory. Young project, small community — evaluate the service's durability before building on it.