firecracker-containerd: Running Containers Inside Firecracker microVMs

KVM Isolation Without Abandoning the Container Ecosystem

Traditional Linux containers share the host kernel. A privilege escalation in one container can expose other containers on the same host. Firecracker microVMs run each workload inside a separate KVM-based virtual machine that does not share kernel memory with its neighbors. Firecracker was designed for fast start-up and low overhead, making per-container VM isolation practical at scale.

firecracker-containerd connects these two worlds. It allows containerd, the standard container runtime used by Docker and Kubernetes, to manage Firecracker microVMs the same way it manages ordinary containers. The README identifies the main use cases: sandboxing untrusted third-party containers in their own microVMs to reduce secret leakage risk, and bin-packing disparate workloads on a shared host while keeping them strongly isolated from each other. The README notes explicitly that multi-tenant use cases are at the user's own risk.

Four Components: Plugin, Runtime, Agent, and Image Builder

The repository implements four pieces that work together. The control plugin manages microVM lifecycle and implements a control API defined in a protobuf file at `proto/firecracker.proto`. Because building a Go plugin out-of-tree is difficult with Go's current plugin mechanism, the control plugin is compiled directly into the containerd binary, which means users must build a specialized containerd binary rather than using the upstream release.

The runtime (`runtime/`) links containerd outside the microVM to the Firecracker VMM. It is implemented as an out-of-process shim communicating over ttrpc, following the standard containerd shim pattern. Inside the microVM, an agent (`agent/`) invokes runc via containerd's `containerd-shim-runc-v1` to create standard Linux containers. The fourth component is a root filesystem image builder (`tools/image-builder`) that assembles the microVM root filesystem containing runc and the firecracker-containerd agent. This four-layer stack means containers inside the microVM still run as standard OCI containers, preserving compatibility with the container image ecosystem.

The architecture document at `docs/architecture.md` provides detailed descriptions of each component and their interactions. The examples directory contains a `taskworkflow.go` and `taskworkflow.md` that demonstrate how to use the client API to launch containers inside microVMs programmatically.

Building and Running firecracker-containerd

The README directs users to a getting-started guide and a quickstart guide in the `docs/` directory for detailed build instructions. The repository uses a Makefile with targets for building the main components:

make build

The go.mod file requires Go 1.25.0. The Makefile uses Docker for builds and specifies separate builder images; the variable `FIRECRACKER_CONTAINERD_BUILDER_IMAGE` defaults to `golang:1.25-bookworm`. Integration tests require Docker and use `TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE` to locate the Docker socket, which means the test suite depends on Docker being available.

The Makefile's architecture check at build time supports x86_64 and aarch64. Any other architecture causes the build to fail immediately with an unsupported error. The Makefile also pre-builds kernel images for each supported architecture using SHA256-verified downloads.

Networking with CNI and tc-redirect-tap

Container networking in firecracker-containerd is configured at the microVM level rather than the container level. The project added CNI plugin support and ships its own CNI plugin called `tc-redirect-tap`, designed for chaining with other CNI plugins. The README mentions this as part of its recent work.

The `tc-redirect-tap` plugin creates a tap device that Firecracker's VMM can use and chains it into an existing CNI network configuration. The go.mod file lists `github.com/awslabs/tc-redirect-tap` as a dependency, confirming the network plugin is not bundled directly but pulled from a separate repository maintained by AWS Labs. This dependency means network behavior is tied to the tc-redirect-tap release cadence. The README's short-term roadmap includes constraining the Firecracker VMM process to improve host security posture, which is separate from the network layer work.

How firecracker-containerd Differs from Kata Containers

Kata Containers is the most widely discussed alternative for VM-based container isolation. Both projects wrap containers in virtual machines, but the underlying hypervisor and design philosophy differ. Kata Containers supports multiple hypervisors including QEMU, Cloud Hypervisor, and Firecracker; when it uses Firecracker, it does so through its own integration layer rather than through this project's containerd shim. firecracker-containerd is specifically and exclusively Firecracker-based, which means it benefits from Firecracker's minimal attack surface and fast start times but cannot swap to another hypervisor if operational requirements change.

Kata Containers also aims for broad Kubernetes CRI compatibility as a primary goal, with an established conformance story. The firecracker-containerd README lists CRI conformance and Kubernetes compatibility as longer-term roadmap items that are not yet complete. Teams that need production Kubernetes integration today should verify the current state of CRI support before committing to firecracker-containerd. The README's existing roadmap mentions allowing multiple containers colocated in the same microVM and exploring how to raise the container count per microVM, both of which are ongoing work rather than completed features.

Maintenance, License, and Kubernetes Roadmap

The last push to the firecracker-containerd repository was on 2026-09-10. The repository is not archived and is maintained by the firecracker-microvm organization. The project uses the Apache 2.0 license, which permits commercial use, modification, and redistribution with notice.

The go.mod file requires Go 1.25.0 and pins recent versions of containerd, runc, and CNI plugins. The dependency on `github.com/containerd/containerd v1.7.33` and the need to build a custom containerd binary means upgrade paths are tied to upstream containerd releases. The README lists Kubernetes CRI conformance and compatibility as a longer-term goal; until that work is complete, deploying this in a Kubernetes environment requires custom integration work. Security issues should not be reported via GitHub issues; the README points to Firecracker's security reporting guidelines instead.

The project has no GitHub releases. Tracking the current stable state requires watching commits directly or following the Buildkite CI pipeline linked from the README. For general questions and community discussion, the README points to the `#containerd` channel on the Firecracker Slack workspace.

Editorial conclusion

firecracker-containerd suits operators running multi-tenant container workloads on Linux where the default kernel-based container isolation is not sufficient and full VM overhead is unacceptable. Before adopting, verify that your host hardware supports KVM and that your team can build the specialized containerd binary the project requires; the upstream containerd binary will not work. Check whether your Kubernetes integration needs are met today, since the README lists CRI conformance as a longer-term roadmap item. The project uses the Apache 2.0 license. The last push to the repository was on 2026-09-10.

Frequently asked questions

Official sources

1. firecracker-microvm/firecracker-containerd on GitHub
2. Issues
3. License: Apache-2.0
4. README