Flintlock

Run hardware-isolated microVMs on your own hosts through one gRPC API.
Firecracker or Cloud Hypervisor, booted from OCI images.

Get started Read the docs

A kernel per workload

Each microVM gets its own kernel behind KVM, so a workload can’t reach its neighbours through a shared kernel the way a container can. MicroVMs still boot in seconds.

Pick your hypervisor

Use Firecracker or Cloud Hypervisor. Enable both on one host and choose per microVM.

Images, not disk files

Kernel, initrd and volumes come from OCI images in any registry, pulled through containerd. Build them with the tools you already use.

API first

Create, get, list and delete microVMs over gRPC or the HTTP gateway, or use the Go client.

Reach into the guest

Run commands in a microVM and proxy SSH to it through a guest agent over vsock. The guest doesn’t need a reachable network.

Metrics included

A metrics exporter publishes microVM metrics for Prometheus to scrape.

Built for

Kubernetes on bare metal

Use microVMs as the nodes of virtualized Kubernetes clusters on bare-metal hosts, with Cluster API Provider Microvm.

Sandboxes and agents

Give untrusted code or AI agents a short-lived VM of their own, then drive it with exec and SSH.

Pipelines and isolated jobs

Start a clean VM for each CI job or tenant workload and delete it when the job is done.

Features

Guest metadata

Pass cloud-init or Ignition metadata to configure the guest when it boots.

Flexible networking

Attach TAP devices, optionally on a Linux bridge, or macvtap devices (Cloud Hypervisor). Use DHCP or static IP addresses.

Shared directories

Share host directories with a microVM using virtiofs (Cloud Hypervisor).

CPU features

Choose which CPU features the guest sees.

Guest agent

Talk to an agent in the microVM over a vsock device. No guest networking needed.

Namespaces and labels

Group microVMs into namespaces, list them by namespace or name, and tag them with labels.

Try it

With flintlockd running, create a microVM with fl. The kernel and root volume are OCI images:

fl microvm create --host 192.168.1.66:9090 --name my-microvm \
  --kernel-image ghcr.io/liquidmetal-dev/firecracker-kernel:6.1 \
  --root-image ghcr.io/liquidmetal-dev/ubuntu:24.04 \
  --allow-guest-agent

Then look it up, run a command in it, or open a shell. For exec and ssh, start flintlockd with --enable-exec-api and --enable-ssh-proxy-api:

fl microvm get --host 192.168.1.66:9090 <vmid>
fl microvm exec --host 192.168.1.66:9090 <vmid> -- uname -a
fl microvm ssh --host 192.168.1.66:9090 <vmid>

The getting started tutorial walks through setting up a host from scratch.

The Liquid Metal ecosystem

Battery

A warm pool manager that keeps pools of pre-booted microVMs ready to be claimed.

Brigade

A distributed orchestrator that schedules microVMs across a fleet of flintlock hosts.

Cluster API Provider Microvm

A Cluster API provider that creates Kubernetes clusters with microVMs as the nodes.

fl

A command-line tool for managing microVMs on flintlock hosts.

Questions or ideas? Find us in #liquidmetal on the CNCF Slack, or read the contributing guide on GitHub.