Backend Modes
DevCell separates product lifecycle from machine implementation. All clients create, start, inspect, stop, and destroy a cell; the selected backend determines what boundary and guest behavior sit behind it.
Capability comparison
Section titled “Capability comparison”| Capability | Fake | Container | Firecracker |
|---|---|---|---|
| Durable lifecycle | Yes | Yes | Yes |
| Real workspace files | No | Yes | Per-cell rootfs; workspace wiring in progress |
| Devcontainer execution | No | Yes | Guest image integration in progress |
| Guest exec | No | HTTP cell-agent |
Host vsock dial wired; current guest image required |
| Filesystem checkpoint | Metadata only | Quiesce + copy | Not yet |
| Dedicated kernel | No | No—shared-kernel label | Yes |
| TAP + vsock + jail staging | No | No | Yes |
| Restart reconciliation | In-memory rebuild | Rehydrate runtime | Processes + TAP + sockets + orphan cleanup |
Fake mode
Section titled “Fake mode”The fake backend is a control-plane test double. It validates generated Connect clients and handlers, SQLite migrations, idempotency, operation events, explicit steps, and startup reconciliation without starting a guest process. It is fast and safe on macOS, but it does not prove workspace execution.
Container mode
Section titled “Container mode”The container backend is the current end-to-end golden path. It owns a cell workspace directory, launches cell-agent, resolves the repository’s devcontainer, executes commands, publishes ports, checkpoints files, and reconstructs live machines after celld restarts.
It deliberately reports a shared-kernel isolation label. Docker namespaces and cgroups are useful runtime boundaries, but they are not presented as the final security boundary.
Firecracker mode
Section titled “Firecracker mode”The Firecracker backend owns a KVM microVM per cell. It prepares a writable rootfs, deterministic vmconfig.json, TAP device, guest MAC, unique vsock CID, Unix socket, API socket, and jail root. It launches Firecracker—or the jailer when privilege permits—and cleans those resources on teardown and reconciliation.
The host-to-guest vsock client is implemented. The immediate integration boundary is a freshly built CellOS rootfs containing the current vsock-listening cell-agent, followed by workspace block and memory snapshots.
Why one contract matters
Section titled “Why one contract matters”Backend differences should change capability labels, not force every client to learn a second product. The Mac app, CLI, and API can render one operation model while still refusing to imply dedicated-kernel or live-snapshot guarantees on weaker modes.
See System Architecture for the interface and request path, or Firecracker Runtime for host artifact details.