Firecracker vs Multipass: a human's VM vs a program's VM

Search for "lightweight VM" and you'll land on both Canonical's Multipass and AWS's Firecracker within about two clicks. The pitches sound suspiciously similar: get a small Ubuntu machine, fast, without the ceremony of a full desktop hypervisor. So people line them up as competitors. They aren't. Multipass is a developer-workstation tool for humans who want a throwaway Ubuntu box. Firecracker is a production VMM primitive for programs that want ten thousand VMs. Once you see the split that way, almost every difference between them stops looking like a feature gap and starts looking like a deliberate design decision.

I'm Ajay — I build PandaStack, which runs Firecracker microVMs as a service, so treat me as an interested party. I'll try to earn your trust by being straight about the case where Firecracker is the wrong answer, which is most laptop-shaped situations. If you want a dev VM on your MacBook this afternoon, close this tab and run `multipass launch`. It is genuinely the right tool and you will be done in ninety seconds.

Why they get compared in the first place

Both projects reacted to the same annoyance: full-fat desktop virtualization is heavy. Spinning up a VM historically meant a GUI, an ISO, a virtual BIOS, an installer, an emulated SATA controller, an emulated graphics card, and about twenty minutes of your life. Multipass and Firecracker both said "no thanks" to that experience — but they cut different things away, because they were solving for different users.

Multipass cut the ceremony. It kept the full general-purpose Ubuntu image and hid the hypervisor behind a friendly CLI. Firecracker cut the machine. It kept the automation surface and threw away nearly every device a general-purpose OS expects to find. One optimized for the human; one optimized for the fleet.

What Multipass actually is

Multipass is Canonical's tool for getting an Ubuntu VM on your workstation with one command. Rather than shipping its own hypervisor, it wraps whatever the host already has: on macOS it drives QEMU or the platform's native virtualization, on Windows it can use Hyper-V, and on Linux it can sit on QEMU/libvirt or LXD depending on how it's configured. That backend flexibility is the point — it's how one command works on three operating systems. Backends and defaults do shift between releases, so verify the specifics for your platform and version against Canonical's own docs rather than trusting any blog post, including this one.

What you get is a real, complete Ubuntu machine: systemd, apt, a full device model, a normal network, cloud-init support so you can declaratively describe the instance, and host directory mounts so your editor on the host and the compiler in the guest see the same files. Image management is handled for you — you ask for `24.04`, it fetches and caches the right cloud image. There's `shell`, `exec`, `transfer`, `suspend`, `stop`, `delete`, `purge`. It is, in the best sense, boring. You do not think about kernels.

What Firecracker actually is

Firecracker is a Virtual Machine Monitor written at AWS to run Lambda and Fargate. Its design brief was roughly: run untrusted code from millions of strangers, thousands of VMs per host, and never let the blast radius escape one guest. Everything about it follows from that brief.

So the device model is deliberately tiny — virtio-net, virtio-block, virtio-vsock, a serial console, a keyboard controller good for exactly one thing (rebooting), and an entropy device. Devices sit on MMIO. There is no PCI bus, no BIOS, no bootloader, no graphics, no USB, no sound, no emulated SATA. The guest kernel is loaded directly as an uncompressed image and starts executing. Every device you delete is attack surface you no longer have to audit and boot time you no longer have to pay.

The control interface is a REST API on a Unix domain socket. Not a CLI for humans — an HTTP API for a supervising process. You PUT a boot source, PUT a drive, PUT a network interface, PUT a machine config, then PUT an action to start the instance. On top of that sit the jailer (chroot, namespaces, cgroups, dropped privileges) and a seccomp filter that restricts the VMM process to the small set of syscalls it actually needs. And it snapshots: you can freeze a running microVM to a memory file plus a state file and restore that machine later, repeatedly, as many times as you like.

The obvious catch: it needs Linux with KVM. There is no macOS build, no Windows build. Firecracker isn't shy about this. It is a Linux systems component, not a cross-platform developer tool.

The same job, two interfaces

Nothing makes the difference clearer than putting the two setups next to each other. Here's "give me an Ubuntu VM" in each. Note that the second one isn't unfair or strawmanned — that really is the shape of raw Firecracker, and the verbosity is the feature: every one of those calls is a knob an orchestrator wants to set programmatically.

# =================================================================
# A) Multipass -- one command, a human is watching, works on
#    macOS / Windows / Linux. Flags and defaults vary by release:
#    check Canonical's docs for your version.
# =================================================================
multipass launch 24.04 --name dev --cpus 4 --memory 8G --disk 40G \
  --cloud-init cloud-init.yaml
multipass mount ~/code dev:/home/ubuntu/code   # host dir in the guest
multipass shell dev                            # you're in an Ubuntu box
multipass delete dev && multipass purge

# =================================================================
# B) Firecracker -- no CLI for humans. You bring the kernel, the
#    rootfs, the tap device, and an HTTP client. Linux + KVM only.
# =================================================================
set -euo pipefail
SOCK=/tmp/fc-$$.sock
api() { curl -s --unix-socket "$SOCK" -X PUT "http://localhost$1" \
          -H 'Content-Type: application/json' -d "$2"; }

# 0. Host networking is YOUR job. No DHCP, no NAT, no magic.
sudo ip tuntap add tap0 mode tap
sudo ip addr add 172.16.0.1/30 dev tap0
sudo ip link set tap0 up

# 1. Start the VMM. It boots nothing yet -- it opens a socket and waits.
firecracker --api-sock "$SOCK" &
sleep 0.05

# 2. Kernel: an uncompressed vmlinux, booted directly. No BIOS, no
#    bootloader, no GRUB menu to miss because you blinked.
api /boot-source '{"kernel_image_path":"./vmlinux-5.10",
  "boot_args":"console=ttyS0 reboot=k panic=1 pci=off"}'

# 3. Root device: a raw ext4 file on virtio-blk. You built this file.
api /drives/rootfs '{"drive_id":"rootfs","path_on_host":"./rootfs.ext4",
  "is_root_device":true,"is_read_only":false}'

# 4. NIC: virtio-net bound to the tap you created above.
api /network-interfaces/eth0 '{"iface_id":"eth0","host_dev_name":"tap0"}'

api /machine-config '{"vcpu_count":2,"mem_size_mib":1024}'

# 5. Go. The guest kernel starts executing in single-digit ms.
curl -s --unix-socket "$SOCK" -X PUT http://localhost/actions \
  -H 'Content-Type: application/json' \
  -d '{"action_type":"InstanceStart"}'

If you are one person who wants one VM, block B is an insult and block A is a gift. If you are a scheduler placing the four-thousandth VM of the hour on host seventeen, block B is a clean state machine you can drive from code and block A is a subprocess you have to screen-scrape.

Side by side

Eight dimensions where the two genuinely diverge. Multipass behaviour varies by version, host OS, and which hypervisor backend it's using, so verify anything load-bearing against Canonical's own docs. The Firecracker latency figures below are PandaStack's measured numbers on our platform, not generic claims about the VMM.

• Target user and job — Multipass: a developer at a workstation who wants a disposable Ubuntu box to break. Firecracker: an orchestrator or platform that programmatically creates and destroys VMs as a unit of work.
• Host OS support — Multipass: macOS, Windows, and Linux, wrapping the host's native hypervisor (QEMU/HVF, Hyper-V, or QEMU/libvirt/LXD depending on platform and config). Firecracker: Linux with KVM only — no macOS or Windows build exists.
• Device model — Multipass: a full general-purpose machine (firmware, disk controllers, a normal PC-shaped device set) so a stock cloud image just works. Firecracker: virtio-net, virtio-blk, virtio-vsock, serial, RNG, over MMIO. No PCI, no BIOS, no graphics, no USB.
• Boot and create time — Multipass: fast enough that a human doesn't mind; it's still a general-purpose OS boot with cloud-init running. Firecracker: guest kernel starts in milliseconds, and with snapshot-restore you skip boot entirely — PandaStack creates a sandbox at p50 179ms / p99 ~203ms, of which the restore step itself is ~49ms.
• API surface — Multipass: a human CLI (launch, shell, mount, transfer, suspend) plus a local daemon. Firecracker: a REST API over a Unix domain socket, designed to be driven by a supervising program; there is no interactive UX and that is on purpose.
• Isolation and hardening — Multipass: real hardware virtualization via the host hypervisor, with that hypervisor's defaults and its full device surface. Firecracker: hardware virtualization plus a jailer (chroot, namespaces, cgroups, privilege drop) and a seccomp filter on the VMM, with a minimal device surface as the primary hardening strategy.
• Snapshot and restore — Multipass: has suspend/stop for pausing your own instance; treat cloning and snapshot semantics as version-specific and check the docs. Firecracker: first-class snapshot to a memory file plus state file, and restore is the normal creation path at scale — one baked snapshot restored thousands of times.
• Density and footprint — Multipass: sized for a handful of instances on one workstation. Firecracker: a few MB of overhead per guest by design, and with copy-on-write memory (MAP_PRIVATE) plus CoW rootfs, identical pages are shared across VMs — thousands per host is the design target, not a stunt.

What each one deliberately gives up

It's more useful to frame this as omissions than as wins, because both sets of omissions are intentional.

What Multipass gives you that Firecracker deliberately doesn't

• Image management. You say `24.04` and an Ubuntu cloud image appears. Firecracker has no concept of an image registry — you hand it a kernel file and a rootfs file that you built, and it does not care where they came from.
• Cross-platform reach. One command on macOS, Windows, and Linux. Firecracker runs on Linux/KVM, full stop.
• A CLI meant for people. `multipass shell` is a thing you type. Firecracker's equivalent is "write a program that PUTs JSON to a Unix socket."
• Host mounts out of the box. Sharing your working directory with the guest is one command. On Firecracker you'd wire up your own transport — vsock, a network filesystem, or a block device you populate.
• A full general-purpose distro with systemd and a complete device model, which means arbitrary software you didn't anticipate tends to just work.

What Firecracker gives you that Multipass doesn't aim at

• Snapshot-restore as the standard creation path. Not "resume my machine" but "stamp out the ten-thousandth copy of this exact booted machine." This is the mechanism behind sub-second create.
• A tiny per-VM overhead measured in single-digit megabytes, so density is a memory question rather than a hypervisor-overhead question.
• A minimal attack surface as the core security argument: fewer emulated devices means less code between untrusted guest and host, backed by jailer plus seccomp.
• An API built for automation, with a clean lifecycle a state machine can drive and no interactive assumptions anywhere.
• Behaviour that holds at fleet scale — per-VM network namespaces and tap devices, per-VM cgroups, and no shared daemon state that becomes a bottleneck at the four-thousandth guest.

On a Mac, they're complements — not rivals

Here's the detail that quietly resolves the whole comparison. Firecracker needs KVM. Your MacBook does not have KVM. So to run Firecracker on Apple Silicon you need a Linux VM with nested virtualization enabled — and the thing that gets you that Linux VM is... a tool like Multipass or Lima. PandaStack's own local development flow does exactly this: a Lima VM using Apple's Virtualization.framework provides the KVM host, and Firecracker microVMs run inside it.

Multipass and Lima are how you get a Linux host on a laptop. Firecracker is what you run inside that host. Comparing them is a bit like comparing a garage to an engine.

That's why the answer to "Firecracker vs Multipass" is usually "both, at different layers." You use the workstation tool to obtain a Linux/KVM machine; you use the VMM inside it to create microVMs from a program. Nobody is displacing anybody.

The third option: don't run a VMM at all

There's a case neither tool serves cleanly: you don't want a laptop VM and you don't want to operate a VMM. You want your application to create isolated Linux machines as a normal function call — because an LLM is about to run a command you have not read, or a customer just uploaded a build script, or your agent needs to try five fixes in parallel and keep the one that passes. In that world, the thing you're really shopping for is a boot path and a lifecycle, not a hypervisor.

That's what PandaStack does with Firecracker underneath: snapshot-restore on every create (no warm pool of idle VMs to pay for), a pre-allocated network namespace and tap device per sandbox, copy-on-write rootfs, and vsock into a guest agent. The API is a Python call, not a Unix socket.

from pandastack import Sandbox

# No tap devices, no vmlinux, no jailer flags, no Linux host required
# on your side. Each of these is a real Firecracker microVM with its
# own guest kernel -- created by restoring a baked snapshot (p50 179ms).
with Sandbox.create(
    template="code-interpreter",
    ttl_seconds=900,
    metadata={"job": "llm-generated-analysis"},
) as sbx:
    # Code you did not write, about to run somewhere that isn't your host.
    sbx.filesystem.write(
        "/work/analyze.py",
        b"import pandas as pd\n"
        b"df = pd.read_csv('/work/input.csv')\n"
        b"print(df.describe().to_string())\n",
    )
    sbx.filesystem.write("/work/input.csv", open("input.csv", "rb").read())

    run = sbx.exec("python /work/analyze.py", timeout_seconds=120)
    if run.exit_code != 0:
        raise RuntimeError(run.stderr)
    print(run.stdout)

    # Freeze this exact machine -- deps installed, data loaded, warm.
    snap = sbx.snapshot()

    # Then branch it. Same-host fork lands in 400-750ms, so "try five
    # candidate fixes in parallel" is a loop, not an architecture.
    for candidate in candidate_patches:
        child = sbx.fork()
        child.filesystem.write("/work/patch.diff", candidate.encode())
        result = child.exec(
            "cd /work && git apply patch.diff && pytest -q",
            timeout_seconds=300,
        )
        record(candidate, passed=result.exit_code == 0, log=result.stdout)
# Sandbox destroyed on block exit. The snapshot outlives it.

The forking bit is the part that has no Multipass analogue, and it isn't a gimmick. Copy-on-write memory and a reflinked rootfs mean a fork shares pages with its parent until something writes, so branching a warm machine five ways is cheap in both time and RAM. That is a fundamentally different primitive from "launch a fresh Ubuntu box and install everything again."

When Firecracker is the wrong tool (and Multipass is the right one)

Let me be plain, because the honest version is more useful than the sales version. If you want a Linux VM on your laptop to poke at, install Multipass. If you're on macOS or Windows, install Multipass. If you want host directory mounts, a shell, and a full Ubuntu userland where random software works without you thinking about it, install Multipass. If you have one VM, or five, and a human is the one deciding when they start and stop, Firecracker will cost you a kernel image, a rootfs build, a tap device, a REST client, and a Linux host, and hand you back nothing you wanted. That's not Firecracker failing — it's you using an engine as a garage.

The microVM approach starts earning its keep at a specific inflection point: when a program, not a person, decides that a VM should exist. When the code inside is untrusted or model-generated. When the count goes from tens to thousands and per-VM overhead becomes an actual line item. When you need to freeze a warm machine and restore it a thousand times, or branch it mid-execution. When "one tenant per machine" needs to be a hardware boundary rather than a filter in application code. Below that line, reach for the workstation tool and get on with your day. Above it, you were never really choosing between Multipass and Firecracker — you were choosing between running a VMM yourself and having something run it for you.