Firecracker's one-process API and its deliberately short device list

One process, one OpenAPI endpoint, 1 vCPU and 128 MiB by default

Firecracker runs as a single micro virtual machine monitor process, and once that process starts it exposes an API endpoint to the host. That endpoint is the whole control surface. The specification is written in OpenAPI format at `src/firecracker/swagger/firecracker.yaml`, and the request reference lives in `docs/api_requests`. Nothing in the top-level layout suggests a second daemon or a config file to hand-edit; `Cargo.toml`, `CHANGELOG.md` and `SECURITY.md` sit alongside a `src/` tree, and every setting arrives as a request.

Two defaults define a fresh microVM: vCPUs default to 1, and memory defaults to 128 MiB. Both are changed over the same endpoint, alongside a CPU template documented separately in `docs/cpu_templates/cpu-templates.md`. Teams building a serverless control plane write against these requests directly, which is why the OpenAPI file matters more here than any sample configuration. Firecracker was written at Amazon Web Services to accelerate services like AWS Lambda and AWS Fargate, and ships under Apache-2.0 with `NOTICE`, `THIRD-PARTY` and a dependency policy in `deny.toml` at the top level.

The device list is short on purpose, and the gaps land on you

The design trade is stated outright: Firecracker excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface of each microVM. What survives is a short, specific set. You can add network interfaces, read-write or read-only file-backed block devices, a vsock socket, an entropy device, a pmem device, and memory hotplugging. Two block device moves are worth learning early: a re-scan triggers while the guest runs so the guest OS picks up size changes to the backing file, and the backing file itself can be swapped before or after boot.

The cost shows up when a guest needs hardware outside that list. There is no generic PCI passthrough and no display adapter, because either one would undo the reason the list is short. A workload that cannot be reshaped to run with the devices on offer is a workload that pushes you toward changing the VMM itself, and the project does not document an extension point for that. Virtio device rate limiters, which cap bandwidth, operations per second, or both, are the only throttling control in the API, so a misbehaving guest gets fenced there rather than through a host scheduler.

Stop is x86_64 only, so teardown is not one code path

One line in the feature list carries an architecture tag: stopping the microVM is marked `[x86_64 only]`. On the Graviton rows of the tested platform table, m6g.metal and m7g.metal, there is no stop request to send. A lifecycle script written by reading the API list will assume one exists, land on an aarch64 host, and meet the gap in production rather than in review. Work out the teardown path for non-x86 hosts before you write the control plane.

Everything else on the endpoint is architecture-neutral. Starting a microVM from a kernel image, a root file system and boot arguments carries no tag, as do vCPU count and memory size. That asymmetry is the thing to pin down in a runbook, because a script that is correct on Cascade Lake is incomplete on Graviton. Neither the feature list nor the quickstart reference says what an aarch64 host falls back to, or what a rejected stop returns, so treat teardown on ARM as something you have to design rather than something you inherit.

The jailer is missing from the default cargo build, on purpose

`Cargo.toml` declares `members = ["src/*"]` but narrows the build with a `default-members` list covering `src/firecracker`, `src/seccompiler`, `src/snapshot-editor`, `src/rebase-snap`, `src/acpi-tables`, `src/cpu-template-helper` and `src/clippy-tracing`. The jailer is absent, and the comment above the list explains why: `cargo build` compiles for the gnu target, and the jailer needs a statically compiled binary to work correctly.

If your production plan depends on the jailer, do not assume a workspace build produced it. The jailer is the piece that applies a cgroup and namespace isolation barrier and then drops privileges, so it is exactly the artifact separating a development microVM from a multi-tenant one. Two profile settings matter for packaging. `[profile.release]` sets `lto = true` and `strip = "none"`, so release binaries keep their symbols and are larger than you may expect from a VMM. Both `[profile.dev]` and `[profile.release]` set `panic = "abort"`, which changes what a panic inside a guest driver does to the VMM process instead of unwinding.

Building in the development container, and what the first run needs

Two routes exist. Download the latest release binaries from the GitHub releases page, or build from source on any Unix/Linux system with Docker running and `bash` installed. The source route uses a development container and three commands:

git clone https://github.com/firecracker-microvm/firecracker
cd firecracker
tools/devtool build
toolchain="$(uname -m)-unknown-linux-musl"

That `toolchain` variable is not decoration. The binary lands at `build/cargo_target/${toolchain}/debug/firecracker`, so a mismatch between your `uname -m` output and the directory you look in is the usual reason a finished build looks like it vanished. Note that the path says `debug`, not release.

The quickstart guide at `docs/getting-started.md` holds the actual boot sequence, and the top-level README does not reproduce the requests that start a microVM. The feature list gives the shape: set vCPU count and memory size first, attach the block device, then start with a kernel image, root file system and boot arguments. If you want a working reference instead of a bare VMM, the Kata Containers and Flintlock integrations are where that wiring already exists.

Multi-tenancy rests on host configuration Firecracker cannot verify

The security boundary is stated plainly: the overall security of Firecracker microVMs, including the ability to meet the criteria for safe multi-tenant computing, depends on a well configured Linux host operating system, and the project points at `docs/prod-host-setup.md` for a configuration it believes meets that bar. Firecracker supplies seccomp filters described as advanced and thread-specific, plus the jailer for the cgroup and namespace barrier, but it does not audit your host. No command in the documented surface reports whether a host passes, so applying that document and then proving it is your work, and no rollback or verification procedure is written down.

The tested matrix is narrower than the compatibility story people assume. Rows cover Intel Cascade Lake, Ice Lake, Sapphire Rapids and Granite Rapids, AMD Milan and AMD Genoa, and AWS Graviton instances, with host kernels `al2 linux_5.10`, `al2023 linux_6.1` and `al2023 linux_6.18`, an `ubuntu 24.04` guest rootfs, and guest kernels `linux_5.10` and `linux_6.1`. Hardware outside those rows is untested by the project, which is not the same as unsupported, and the distinction matters when you are deciding whether a bug report will be taken seriously.

Driving the endpoint yourself, or letting a container runtime own it

The second option is to stop treating Firecracker as a process you own. Two container runtimes are named as having integrated it: Kata Containers and Flintlock. The difference in approach is where your code stops. Talking to the Firecracker OpenAPI endpoint means you set vCPU count, memory size, block devices, rate limiters and the metadata service data tree yourself, one request at a time. Sitting behind a container runtime means you submit a workload through that runtime's interface and never address those requests directly.

What you hand over is control surface. Rate limiters, block device re-scan, backing file swap after boot, memory hotplugging and the guest-facing metadata service all live on the Firecracker API. The integration is stated in one sentence, with no interface description and no statement about which requests pass through, so you cannot assume the passthrough. Teams that need per-microVM throttling, or a metadata service filled with tenant specific data, should read the runtime's own documentation before picking that route over the endpoint.

Two release lines moved on the same day

New versions are published on the GitHub releases page every two or three months, with a change history in `CHANGELOG.md` and the rules in `docs/RELEASE_POLICY.md`. Recent tags show why a pin matters: v1.17.0 and v1.16.2 carry the same release date, 2026-09-10, while v1.16.1 sits back at 2026-07-02. Two lines moved on one day, so decide which one you track before you script an upgrade, and remember that a `cargo build` of the main branch is not the same artifact as either tag.

A `DEPRECATED.md` file at the top level is where removals land. Nothing in the release policy reference in the README says whether a deprecated feature keeps working across a minor bump, so read that file before moving between the two lines. The repository itself is not archived, and its last push was on 2026-09-29, which is a faster cadence than the two-or-three-month release tags suggest.

Editorial conclusion

Firecracker fits teams that already run KVM hosts and want one microVM per tenant, and it does not fit people who want a container runtime with a VM-shaped security story attached, or who need arbitrary guest hardware. Before adopting, check three things: whether your host configuration matches the production host setup document, whether your instance type and kernels appear in the tested platform table, and whether the requests you depend on are ones you want while the guest-facing metadata service is still tagged BETA and virtio PCI hotplug is still Developer Preview. Licensing is Apache-2.0, with the dependency policy in deny.toml and third-party notices in THIRD-PARTY; the question to answer yourself is whether your distribution model has to carry NOTICE downstream. Then pin to a single release line, because v1.17.0 and v1.16.2 were both published on 2026-09-10.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes