Can you run Firecracker on a Mac? MicroVMs on Apple silicon explained

01Why doesn't Firecracker run on macOS?

Firecracker is a virtual machine monitor that runs in user space and asks the Linux kernel to do the hardware virtualization through KVM. Its getting-started guide lists x86_64 and aarch64 Linux as the supported platforms and says it needs read and write access to /dev/kvm, the device KVM exposes. KVM is part of the Linux kernel: a program opens /dev/kvm and drives virtual machines with ioctls on the file descriptors it gets back.

macOS has a different kernel and no /dev/kvm. The CPU in an Apple silicon Mac has virtualization extensions, but the way a program reaches them is through Apple's frameworks, not KVM. Porting Firecracker would mean replacing the layer it was designed around, so the project does not offer a macOS build. The same is true of gVisor, which requires Linux 5.6 or later, and of Kata Containers, which runs on Linux hosts.

02Hypervisor.framework vs Virtualization.framework: Apple's two layers

Apple ships two frameworks for virtual machines, at two levels. Hypervisor.framework, available since macOS 10.10, is the low level. Apple describes it as C APIs for using virtualization in user space without kernel extensions. It treats each VM as a process and each virtual CPU as a thread, allows one VM per process, and needs hardware support: the Virtualization Extensions on Apple silicon, or VT-x with Extended Page Tables and Unrestricted Mode on Intel. Every process that uses it must hold the com.apple.security.hypervisor entitlement. You can check availability with sysctl kern.hv_support.

Virtualization.framework, available since macOS 11, is the high level. Apple describes it as APIs for creating and managing VMs on Apple silicon and Intel Macs that run macOS or Linux guests, with virtio devices for network, sockets, serial ports, storage, entropy and memory ballooning. You describe a machine in a configuration object, and the framework handles the virtual CPU loop and the devices.

In Firecracker terms, Hypervisor.framework is roughly the KVM layer and Virtualization.framework is roughly KVM plus a ready-made VMM. A microVM on a Mac is therefore built one of two ways: write a small VMM on Hypervisor.framework, as libkrun does on macOS/ARM64, or configure a minimal Linux machine through Virtualization.framework, as Lima's vz driver and Apple's own Containerization package do.

03Can you run Firecracker inside a Linux VM on an M3 Mac?

Yes, on recent hardware. Nested virtualization lets a Linux guest use KVM itself. Apple added it to Virtualization.framework in macOS 15, and its documentation says it is available on Macs with the M3 chip and later. Lima added a nestedVirtualization setting for its vz driver in late 2024, listed in its v1.0.0 release as support for nested virtualization on M3, with the PR noting the same M3 and macOS 15 limits. Inside such a VM, /dev/kvm exists, and Firecracker's aarch64 build can use it.

On M1 and M2 Macs there is no nested virtualization, so Firecracker and Kata cannot run even inside a Linux VM. gVisor still can, because its default Systrap platform does not need virtualization support.

Two layers also cost something: every Firecracker microVM sits inside a Linux VM that has to be sized, kept running and updated. For learning Firecracker, or for testing code that will run on Linux servers with KVM, that is a reasonable trade. For everyday sandboxing on a laptop, a tool that uses Apple's frameworks directly avoids the extra layer.

04What are the options for microVMs on Apple silicon?

Listed by how they reach the hardware, not ranked. Each fact comes from the project's own documentation.

One practical detail applies to all of them: guests on Apple silicon are arm64. Images built only for amd64 need emulation, which these tools handle in different ways or not at all; Docker's docs, for example, note that Docker VMM does not currently support Rosetta, so amd64 emulation is slow.

• Lima with nested virtualization (M3 or later, macOS 15): a Linux VM on Lima's vz driver, the default on macOS since Lima v1.0, then Firecracker, Kata or another KVM tool inside it.
• Lima or UTM without nesting: a Linux VM running Docker or gVisor, for any Apple silicon Mac.
• Apple's Containerization package: each Linux container in its own lightweight VM on Virtualization.framework, with sub-second start times per Apple; it needs macOS 26 on Apple silicon, and its command-line tools live in the separate apple/container repository. Apache-2.0 licensed.
• libkrun: a library for virtualization-based process isolation that uses KVM on Linux and Hypervisor.framework on macOS/ARM64. Apache-2.0 licensed.
• Docker Desktop and Docker Sandboxes: Docker Desktop runs its Linux VM on Docker VMM or Apple's Virtualization framework; Docker Sandboxes runs coding agents in microVMs, each with its own Docker daemon.
• A remote Linux host with KVM: run Firecracker where it was designed to run; its guide notes that on EC2, KVM is available on .metal instances.

05How to run a Linux VM for an AI agent on a Mac

For an AI coding agent, the questions are less about which hypervisor and more about the sandbox around it. Does each agent get its own kernel, or do several share one Linux VM? Can the agent see only its project folder, or your home directory? Is the network closed except for the hosts it needs? Do API keys enter the VM? Can you undo what it did?

A single shared Linux VM, as in a plain Lima or Docker Desktop setup, gives one boundary between all your agents and the Mac but none between agents. A VM per agent, built on Virtualization.framework or on nested KVM, separates them. Either way, the network, keys and undo come from the tooling you add on top, so check each tool's documentation for those, not only for the word microVM.