Mitos boots Firecracker microVMs, forks them through copy-on-write snapshots, and exposes the whole lifecycle through declarative CRDs (SandboxPool, Sandbox, Workspace) in the mitos.run/v1 API group. A sandbox is a microVM, not a pod: it gets hardware isolation through KVM, and pod-scoped mechanisms (NetworkPolicy, ResourceQuota, PSA) do not govern it.
The pieces:
- controller (Deployment): reconciles the CRDs, selects a node, and drives
forkd. It tracks the available fork nodes through a registry fed by per-node capacity heartbeats. - forkd (DaemonSet): the per-node daemon that owns the VMs. It serves gRPC on
:9090for the controller (fork, prepare-pool, heartbeat) and an HTTP sandbox API on:9091for exec and file traffic. It needs/dev/kvm, so it runs only on KVM-capable nodes. - guest agent: PID 1 inside each microVM. It speaks a vsock protocol for exec, files, environment, and fork notifications.
- sandbox-server: the same fork engine behind a plain REST API, with no Kubernetes required, for local loops and single-host use.
- SDKs (
sdk/python,sdk/typescript,sdk/go, and more): clients for the hosted service, a cluster, orsandbox-server.
Two hot paths carry the system:
- Claim path: the controller picks a warm node from the registry and calls
forkdForkover gRPC; the resulting sandbox reports Ready throughforkd’s HTTP API on that node. - Exec path: the SDK or CLI talks to
forkdon:9091, which bridges over vsock to the guest agent inside the VM.
Fork is the core primitive: a source VM is snapshotted once and N children restore from that snapshot through copy-on-write, so each sibling lands warm and independent while the shared template pages are stored and metered once. Because Firecracker needs hardware virtualization, bare metal (Talos on Hetzner is the reference platform) is a first-class target; the cloud control plane stays on ordinary nodes while execution lands on KVM-capable machines.