A MicroVM is a virtual machine with almost everything removed. No emulated floppy controller, no VGA adapter, no legacy BIOS, usually no PCI bus - just a CPU, some memory, a handful of virtio devices, and a virtual machine monitor small enough to audit. What is left boots in the low hundreds of milliseconds and carries a memory overhead measured in single-digit megabytes rather than hundreds.
That is the whole idea, and the reason it matters is a trade nobody could make before: VM-grade isolation at close to container-grade density and speed. For twenty years the choice was a real isolation boundary (slow, heavy) or a fast, dense one (shared kernel). MicroVMs collapsed that choice, which is why the infrastructure you use every day is quietly built on them - AWS Lambda and Fargate, Fly.io, and platforms like ours.
Disclosure: Miget runs every customer workload in its own MicroVM under Cloud Hypervisor, so we have a side in this. The trade-offs section is where that shows, and we have tried to make it the honest part.
What got deleted, and why it mattered
A traditional hypervisor like QEMU can emulate a whole PC because it has to: it might be running Windows XP, or a BSD from 2003, or firmware that expects an IDE controller. That generality is a feature for a general-purpose VM and pure cost for a Linux container workload that will never touch any of it. It shows up as slow boot (firmware initialization, device probing), a large memory footprint per VM, and a large attack surface - every emulated device is code the guest can reach.
MicroVM monitors delete all of it and keep a minimal set:
- virtio-net for networking, virtio-blk or virtio-fs for storage, virtio-vsock for host-guest communication.
- A direct kernel boot: the VMM loads a Linux kernel and an initramfs straight into guest memory, skipping firmware entirely.
- A guest kernel configured for exactly this environment, so it does not spend boot time looking for hardware that is not there.
The result is a VM you can start per request, per container, or per pod without the economics falling apart.
The implementations worth knowing
Firecracker - built by AWS in Rust for Lambda and Fargate, and open-sourced. The most aggressively minimal of the group, and the only one that publishes a specification it enforces in CI: <= 125 ms from the start API call to the guest's /sbin/init, and <= 5 MiB of VMM memory overhead for a 1 vCPU / 128 MiB microVM. It ships a jailer that drops privileges behind a cgroup and namespace barrier, and snapshot/restore to skip booting entirely. Worth knowing that its reputation as a fixed, six-device machine is dated: PCI support arrived in v1.13.0 (opt-in, and now recommended over MMIO in the docs) and device hotplug in v1.16.0 as a developer preview. Fly.io runs on it too.
Cloud Hypervisor - also Rust, developed as a Linux Foundation project with Alibaba, AMD, Ampere, ARM, ByteDance, Intel, Microsoft, SAP and Tencent Cloud behind it, and sharing much of its implementation with Firecracker and crosvm through the rust-vmm crates. It makes a different trade: keep the MicroVM philosophy but support what a persistent workload needs - virtio-fs, VFIO passthrough, CPU and memory hotplug, and live migration of a running VM. This is the one we run, and those last two capabilities are exactly why.
Dragonball - a VMM built into Kata Containers itself, so the sandbox does not need a separate hypervisor process at all. As of Kata 4.0 (July 2026) this is Kata's default and recommended mode, on the grounds that running a separate VMM process "introduces overhead due to context switching and cross-process communication."
QEMU's microvm machine type - QEMU can also be told to be minimal. Useful when you are already deep in QEMU tooling and want a lighter machine.
The first two are the ones you meet in production, and choosing between them is a real decision with real consequences: Cloud Hypervisor vs Firecracker covers it properly.
MicroVM, container, and classic VM side by side
| Container (runc) | MicroVM | Classic VM | |
|---|---|---|---|
| Kernel | Shared with host | Its own, per workload | Its own, per workload |
| Boundary | Namespaces + cgroups | Hardware virtualization | Hardware virtualization |
| Start time | Milliseconds | Low hundreds of milliseconds | Seconds to minutes |
| Memory overhead | Negligible | Small: VMM + guest kernel | Large |
| Device model | Host's | Minimal virtio set | Full emulated machine |
| Runs any OS | No, Linux processes | Practically, Linux | Yes |
| Multi-tenant safe | Depends entirely on the host kernel | Yes, by design | Yes |
The row that does the work is the first one. A container shares the host kernel, so every container on a machine is one kernel vulnerability away from every other. A MicroVM does not, which is why every platform that runs strangers' code next to each other converges on this model or on gVisor's software equivalent.
What it costs
Three real prices, and anyone selling you MicroVMs without mentioning them is selling.
A memory floor per workload. The VMM process and the guest kernel are per-VM, not per-host. It is small, but on a machine holding hundreds of tiny workloads it is the difference between a viable and an unviable density target. This is the single strongest argument for gVisor-style software isolation instead.
Boot time you did not have. Hundreds of milliseconds is fast for a VM and slow compared to runc, where there is no boot at all. Irrelevant for a long-running service, potentially decisive for a function invoked ten thousand times a second.
Everything crosses a boundary now. Storage arrives over virtio-blk or virtio-fs, not as a bind mount. Networking is a virtual NIC. GPUs and other devices need explicit passthrough. Each of those is solvable and each is more moving parts than the container equivalent - which is the part platforms absorb so their users do not have to.
Does this matter to you?
If you deploy applications: mostly no, and that is the point. Your Dockerfile does not change, your app does not know, and the difference shows up as an infrastructure property - who else is on this machine, and what stands between us.
It matters when you are choosing a platform to run something that must not leak, or when you are the one operating the platform. In the first case the useful question to ask a vendor is simply "what is the boundary between my workload and the next customer's?" - the answers "namespaces," "gVisor," and "a MicroVM with its own kernel" are three genuinely different products, and only one of them is usually stated on the pricing page.
On Miget it is the third: every app, worker and database gets its own MicroVM under Cloud Hypervisor, on a flat plan where running more of them does not cost more.
Frequently asked questions
Is a MicroVM more secure than a container?
It has a fundamentally different boundary. A container is isolated by kernel features while sharing that kernel; a MicroVM has its own kernel and is isolated by the CPU's virtualization support. Any kernel bug reachable from inside a container is a potential escape; the same bug inside a MicroVM compromises only that VM's own kernel. That is a meaningfully stronger position, though not an absolute one - hypervisors and virtio devices have their own vulnerability history.
How fast do MicroVMs actually boot?
Firecracker publishes the only number that is continuously tested: <= 125 ms from the start API call to the guest's /sbin/init, with a minimal kernel and rootfs. That is the right order of magnitude for the category - there is no firmware phase and almost no device probing. Snapshot and restore, which Firecracker supports, can cut it further by resuming from a memory image instead of booting at all. Be sceptical of boot-time figures quoted for other MicroVM monitors; most are not backed by a published, enforced specification.
Do MicroVMs work with Docker images and Kubernetes?
Yes, and that is what makes them practical. Kata Containers presents MicroVMs through the standard containerd shim interface, so Kubernetes schedules them like any other pod through a RuntimeClass. Your image and manifests are unchanged; only the thing executing them differs.
What is the difference between a MicroVM and Firecracker?
Firecracker is one implementation of the idea. "MicroVM" is the category - a stripped-down VM with a minimal monitor - and Firecracker, Cloud Hypervisor, Dragonball and QEMU's microvm machine type are all members of it, with different feature sets and different priorities.
Can I run a MicroVM on my laptop?
Yes, with hardware virtualization enabled (KVM on Linux). Both Firecracker and Cloud Hypervisor are open source and runnable locally, which is the fastest way to understand the model: boot a kernel with a rootfs and watch a VM come up in the time a webpage takes to render.