sandkiln.

Five crates. None reachesinto another's internals.

The core is a Rust workspace kept deliberately modular: the daemon can change without touching the guest agent, and the guest agent ships as its own static binary, independent of everything that talks to it.

workspace

Five crates, and exactlywhat each one owns.

cratewhat it ownsdepends on
sandkiln-protocolThe wire format shared by host and guest — length-prefixed JSON, kept dependency-light so neither side reaches into the other.nothing
sandkiln-guest-agentRuns inside the microVM as a systemd service. Listens on vsock and answers exec, read, write and list. A static musl binary.protocol
sandkiln-vmmDrives Firecracker directly: boot, snapshot and resume, network leasing, drives, the vsock client. A hand-rolled HTTP client talks to Firecracker's API socket.protocol
sandkiln-storeA small sqlite-backed crate for durable sandbox history — the record of every sandbox that ever existed and how it ended, surviving a daemon restart the live sandbox map never could.nothing
sandkiln-daemonThe axum + tokio HTTP API wrapping the lifecycle — create, exec, list, stop, snapshot, images, drives, pools — with auth, tags and tracing built in from the start.protocol, vmm, store
lifecycle

What actually happensinside a create.

Your callPOST /sandboxessandkilndleases tap + IPFirecrackerboots a real kernelguest-agentbinds vsock — ready
01

Lease

A tap device and IP are leased from the pool and attached to the bridge — concurrently with the rootfs clone, not after it.

02

Boot

Firecracker starts; boot-source, drive, machine-config and vsock are configured over its API socket.

03

Agent up

The guest kernel boots, systemd starts the guest agent, and it binds its vsock port.

04

Ready

The host's vsock client connects. The sandbox can now run anything you send it.