Flintlock MicroVM Management with containerd and Firecracker

Flintlock's Bare-Metal MicroVM Control Plane

Flintlock solves a specific infrastructure problem: turning a physical host into a manageable pool of lightweight virtual machines. It creates and manages the lifecycle of MicroVMs while using containerd as the backing store for guest volumes, kernels, and initrds. The documented original use case is a bare-metal host whose MicroVMs become nodes in a virtualized Kubernetes cluster. That origin explains several design choices, including an API-oriented service model and integration with other Liquid Metal components.

The intended users are infrastructure engineers operating Kubernetes clusters, isolated workloads, or pipelines that benefit from MicroVM isolation. Flintlock is also the execution layer under Battery, Brigade, and Cluster API Provider Microvm. Battery manages warm pools, Brigade schedules MicroVMs across a fleet, and the Cluster API provider uses them as cluster nodes. These are separate systems, so Flintlock should not be confused with an orchestrator that decides where workloads should run.

The service exposes MicroVM creation, lookup, listing, and deletion through gRPC or HTTP requests. This makes it suitable for infrastructure software that needs a machine-level API rather than a human-oriented virtual machine console. It is less suitable as a replacement for libvirt, QEMU management, or a cloud control plane when those environments expect disks, desktop peripherals, migrations, or broad hypervisor feature coverage.

Firecracker, Cloud Hypervisor, and Containerd Inputs

Flintlock supports Firecracker and Cloud Hypervisor, with the VMM selected separately for each MicroVM. That choice is operationally significant because their supported features and version ranges differ. Cloud Hypervisor provides the documented macvtap and virtiofs options. Firecracker can use TAP networking, but the README says macvtap users should choose Cloud Hypervisor because the former Weaveworks Firecracker fork is no longer supported.

Guest assets are represented through OCI images. The README lists volumes, the kernel, and the initrd as OCI-backed inputs, which ties image distribution into the existing container image ecosystem rather than requiring every asset to be transferred through a separate MicroVM-specific format. Guest metadata can be supplied through cloud-init or Ignition. Flintlock can also customize exposed CPU features and communicate with a guest agent through vsock.

The repository is organized as a Go service, with API definitions under `api/`, a client under `client/`, service code under `core/` and `internal/`, and command entry points under `cmd/`. The module declares `github.com/liquidmetal-dev/flintlock` and depends on containerd v2, `firecracker-go-sdk`, gRPC, CNI packages, Netlink, and Prometheus libraries. This structure indicates a host-level daemon and generated or dedicated API surface, not an application that embeds virtual machines inside its own process.

TAP, macvtap, and virtiofs Boundaries

Networking is one of Flintlock's most concrete areas of specialization. A MicroVM interface can be attached through a TAP device, optionally connected to a Linux bridge. Cloud Hypervisor can also use macvtap. Address assignment can come from DHCP or be configured statically. These options keep the guest connected through host networking primitives, but they also place responsibility for bridge setup, address assignment, and host networking policy outside a simple process lifecycle call.

Flintlock can expose metrics for collection by Prometheus, while vsock provides a dedicated path to a guest agent. Cloud Hypervisor can additionally share host directories with a guest through virtiofs. Sharing directories is useful when a workload needs host-provided files, but it also changes the isolation boundary. The presence of a host directory in the guest's accessible filesystem should be treated as an explicit deployment decision rather than a harmless default.

Cloud Hypervisor version selection also depends on host CPU behavior. The README warns that versions before v48.0 may not start on some hosts with newer Intel CPUs. This is a useful example of why a documented API capability cannot be evaluated independently of the physical host. A successful control-plane request still leaves kernel access, VMM compatibility, virtual networking, and image availability as separate deployment conditions.

Building Flintlock from the Repository

The README points readers to the external getting-started tutorial for installation and operational setup. It does not provide a complete host installation procedure, package-manager command, service configuration, or first MicroVM request in the README. The repository's `Makefile` does define concrete build targets for the principal binaries.

From the repository root, the default build target compiles the daemon, metrics utility, and provisioning command:

make build

The `Makefile` documents the resulting outputs as `bin/flintlockd`, `bin/flintlock-metrics`, and `bin/flintlock-provision`. The `go.mod` file requires Go 1.26.6, so a source build must use a compatible Go toolchain. The Makefile also builds releases for Linux with CGO disabled for its release target, but the documentation shown here does not state whether those release artifacts are available as packages for a particular distribution.

After building, do not assume that `bin/flintlockd` is ready to start with default settings. The README does not document a complete first-run daemon command or show a valid `config.yaml`. The repository contains `config.yaml.example`, but its contents are not reproduced here. Follow the linked getting-started tutorial to obtain the documented setup sequence rather than inventing service flags, storage settings, network names, or API endpoints.

Operating Flintlock Beyond Kubernetes

The API is broad enough for uses outside Kubernetes. The README lists create, get, list, and delete operations, per-MicroVM VMM selection, cloud-init or Ignition metadata, OCI-based assets, networking, CPU configuration, vsock, virtiofs, and Prometheus metrics. Those features make Flintlock relevant to isolated workloads and pipelines, provided the host environment satisfies the requirements of the selected VMM.

This is still an infrastructure service rather than a complete deployment product. The documentation does not explain image publishing, host CNI deployment, firewall policy, DNS, image caching, credential handling, or guest operating system installation. It also does not claim live migration, snapshots, cloning, or a graphical interface. A team considering those features would need to confirm elsewhere whether an external controller or adjacent tool supplies them.

The relationship with containerd is narrower than the project name may suggest. Containerd backs the MicroVM assets and integration, while Firecracker or Cloud Hypervisor runs the guest. Flintlock does not present itself as a general-purpose container runtime replacement. Its value lies in translating infrastructure requests into MicroVM resources and lifecycle operations on a host.

Version Compatibility and Maintenance Cost

The latest listed release is `v0.16.0`, published on 2026-10-03. The repository's last push was on 2026-10-14, and the repository is not archived. Those facts indicate recent project activity, but they do not remove the need to coordinate upgrades with host components. Flintlock's compatibility table pairs `v0.16.x` with official Firecracker v1.16 or later and Cloud Hypervisor v48.0 through v53.0.

Older Flintlock lines target older VMM versions. This matters because changing Flintlock alone does not guarantee that the host's Firecracker or Cloud Hypervisor remains valid. Operators must account for API changes, VMM startup behavior, CNI versions, and operating system changes. The repository pins CNI dependencies in `go.mod`, including `github.com/containernetworking/cni` v1.1.2 and `github.com/containernetworking/plugins` v1.1.1, which is another reason to review dependency and host compatibility together.

Flintlock is licensed under MPL-2.0. That license permits use and modification of covered files under its terms, while file-level obligations can apply when distributing modified MPL-covered files. The license does not remove the need to review third-party dependencies, VMM licenses, guest image licenses, or organizational policy. This is a technical licensing note, not legal advice.

Where Flintlock Is the Wrong Layer

Flintlock is the wrong tool when the requirement is broad virtual machine management rather than MicroVM lifecycle control. The README does not document graphical consoles, arbitrary device passthrough, storage snapshots, live migration, or a general user-facing VM catalog. It also does not document orchestration decisions for capacity, placement, warm pools, or cluster formation. Those activities belong to controllers such as Battery, Brigade, or Cluster API Provider Microvm in the documented Liquid Metal setup.

It is also unsuitable where the host cannot run the selected VMM. Firecracker compatibility is tied to a specific Flintlock line, and Cloud Hypervisor has version and CPU-related constraints. A host without the required virtualization facilities, containerd integration, or network setup cannot be made eligible merely by exposing the API.

The macvtap boundary is especially easy to misread. Flintlock supports macvtap through Cloud Hypervisor, but the README explicitly says the old Weaveworks Firecracker fork with macvtap is no longer supported. Teams migrating from that path need to account for a VMM change rather than treating macvtap as an interchangeable flag.

Editorial conclusion

Flintlock is appropriate for teams operating MicroVMs on suitable bare-metal hosts, especially Kubernetes infrastructure built around Liquid Metal. It is a poor fit for developers who need a general desktop or server VM manager, or for deployments whose Firecracker and Cloud Hypervisor versions fall outside the documented compatibility ranges. Verify host support, the selected VMM version, containerd access, network configuration, OCI asset availability, and the external getting-started documentation before adoption.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. liquidmetal-dev/flintlock on GitHub
3. Project website
4. README
5. Releases