The plan,not a promise.

Save a running microVM's full state and boot a new one from it, consuming the snapshot or not — durable across a daemon restart.

Stopping a sandbox snapshots it by default instead of destroying it; ?keep=false opts back into full destruction.

Create or resume by a caller-given name via get-or-create, race-safe under a per-name lock.

An idle sandbox is paused and snapshotted automatically, freeing resources while staying resumable.

Register an already-built rootfs and boot from it. OCI/Docker-image conversion is not done.

Fork a snapshot without consuming it. Not true parallel forking — at most one live fork of a given snapshot at a time.

A sqlite-backed record of every sandbox that ever existed and how it ended, surviving a daemon restart — deliberately not the same thing as live sandboxes surviving one, which nothing can make true today.

A matching sandbox create resumes a ready snapshot instead of cold-booting — transparent, no special call. An optional max_count caps total live instances, queueing a claim at capacity instead of exceeding it. Honestly-measured caveat: resuming has a real, non-rare guest-kernel-panic failure mode that a health check catches and falls back from. See the Performance page.

Extends auto-suspend into named tiers — suspend, then archive, then delete — each with its own window. The archive tier ships, moving a held snapshot to a separately configured local directory past its timeout. The delete-after-archive tier was deliberately left out of that slice, and archiving to a remote object store rather than a local path isn't built either.

Resuming retains the checkpoint instead of deleting it, restorable again later as many times as wanted via the snapshot history API. Sequential, not branching: refuses while anything sharing that checkpoint's network identity is live or held. Real cost: unbounded disk usage with no automatic expiry yet, a delete endpoint being the mitigation so far.

Every snapshot records the snapshot its own source sandbox was resumed or forked from, queryable in both directions — walk a full ancestry tree one request at a time, without a dedicated tree-shaped endpoint.

Cloning one snapshot into several live sandboxes at once needs the same unsolved independent-rootfs problem as parallel forking above — not a separately achievable feature.

Every sandbox is a real Firecracker microVM with its own kernel — the strongest available isolation for untrusted code.

A single shared-secret token gates every /sandboxes* route. Off by default, warns loudly if left off.

Bridge port isolation between sandboxes — no sandbox-to-sandbox traffic by default, verified.

Per-sandbox vcpu and memory overrides, rejected outright rather than silently clamped if out of range.

Firecracker's jailer (chroot, cgroups v2, unprivileged uid), opt-in. Not yet proven against a real jailer binary on hardware.

Separate Linux users with private home directories, baked into the base image build.

Per-sandbox IP/CIDR allow/deny policy, one dedicated iptables chain per sandbox, deny always winning over allow on overlap. Domain-level rules and port-level matching are not built yet — still needs the shared DNS proxy to become source-IP-aware.

Firecracker's own token-bucket rate limiter (ops/sec plus bandwidth), applied per sandbox to every drive and the network interface — unlimited by default, capped with one field on create.

Per-sandbox syscall filtering and a hard disk quota — neither exists yet.

A drive attached read-only may be shared by arbitrarily many sandboxes at once; read-write still needs exclusive access. Drive.create/list/delete in both SDKs and kiln drive.

FUSE-mount an S3-compatible bucket into a sandbox and read or write it like local disk, via rclone running inside the guest — credentials written in as a 0600 config file rather than a command line. Daemon-only: no SDK or CLI wrapper yet. Needs a guest kernel built with CONFIG_FUSE_FS and rclone/fusermount3 in the rootfs, neither of which a stock setup has. Verified end to end against a local S3-compatible test fixture, not against a hosted object store. Mounts are not re-applied after resume, fork or restore.

kiln logs -f and streamed exec output, once the daemon can stream a response.

A real, bidirectional shell session over WebSocket, distinct from batch exec. kiln sandbox pty and Sandbox.pty() in the JS/TS SDK. A per-sandbox concurrent-session cap of 64 is enforced daemon-side. No live resize yet.

Every sandbox with a name or tags serves its own id, name and tags to itself via Firecracker's native MMDS at 169.254.169.254 — no daemon call needed from inside the guest.

chmod, chown, mkdir, rename, copy, symlink, readlink, truncate, and directory listing with real metadata — the full set, in both SDKs and the CLI, alongside read-file and write-file.

An alternative to the proxied /preview/:port path — a real routable domain per port. Needs DNS and routing infrastructure this project doesn't have; a bigger lift than the existing proxy.

The reverse of dev-server preview: code inside a sandbox reaches a real service on the caller's own machine, via sandbox.tunnel() (JS/TS and Python, sync and async) or kiln sandbox tunnel. Built on the one deliberate exception to this project's host-always-connects-in vsock rule — the guest dials out using Firecracker's own guest-initiated-connection mechanism. Verified end to end on all three surfaces with a real local HTTP server reached from inside a real sandbox.

Explicitly not planned — Firecracker has no GPU device model, and adding one is a different project from this one.

Docker-in-VM and VPN clients inside the guest — still needs base-image and kernel-config work more than daemon changes. The FUSE half is done: the guest kernel build enables CONFIG_FUSE_FS and the rootfs can carry a FUSE userspace, which is what remote storage mounts run on.

More than one daemon, more than one box, a routing layer — deliberately last, after single-node is fully solid.

Getting started, core concepts, guides, and reference for the HTTP API, both SDKs and the CLI — this site.

A code playground (JS/TS), an AI-agent sandbox runner (Python), a dev-server preview reference, an interactive-terminal reference, and a pre-warmed-pool reference that reports real results honestly instead of a single lucky run — see examples/ in the repository.

A managed desktop inside a sandbox — screenshot capture, full keyboard and mouse control, reconnect without killing the VM. A meaningfully different product surface, not a small extension.

Version-controlled sandbox state as a first-class concept — branches as mounted directories, a snapshot doubling as a commit. A substantial new subsystem alongside snapshot/resume/fork, not a replacement for them.