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 | 2.9k | 460 |
| Forks | 220 | 53 |
| Language | Rust | TypeScript |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | 5 days ago | 3 days ago |
| Topics | agents, local | agents |
| Curated connections | 4 | 3 |
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.