# Unikernel vs microVM: what is the difference?

A microVM is a minimal virtual machine that boots a normal kernel; a unikernel is one application built with only the OS parts it needs.

**Runtime runs a full Linux microVM per sandbox, so an agent gets a shell, a
package manager and many processes, and it still starts in about a third of a
second.** A new sandbox ran its first Python command 351 ms after the create
request at the median, over the public internet, on 24 September 2026
([speed](/docs/speed)).

## Two answers to different questions

A **microVM** shrinks the machine. The monitor offers the guest very few
devices, so there is less to emulate and less to attack. Firecracker, the best
known, counts "only 5 emulated devices" on its site. Inside, the guest is an
ordinary operating system, usually Linux, with its own kernel, user space,
processes and package manager.

A **unikernel** shrinks the operating system. Unikraft, an open-source unikernel
project under a BSD licence, describes it as "a single-address space binary object": the
application and the library OS parts it uses are linked into one image, with
"no separation between kernel and user address spaces." Each image runs a
single application. Unikraft builds only the libraries an application needs,
down to the scheduler and memory allocator.

The two combine. A unikernel still needs a monitor to run on, and Unikraft
runs "as a virtual machine, using KVM (with QEMU or Firecracker as VMMs) or
Xen." Firecracker's FAQ lists OSv, another unikernel, as a supported guest. So
the real comparison is what runs inside the microVM: a general Linux, or one
application compiled as its own kernel.

## What unikernels claim

Unikraft publishes these results from its evaluation, described in its
EuroSys 2021 paper. They are the project's own figures:

- **Boot.** A hello-world unikernel boots in "tens (no NIC) to hundreds of
  microseconds (one NIC)" on QEMU and Solo5, guest only, and under 1 ms on
  Firecracker. Total VM boot is "dominated by the VMM": about 3 ms with Solo5 or
  Firecracker, about 10 ms with QEMU microvm, about 40 ms with standard QEMU.
  For comparison it measured Alpine Linux at around 330 ms on Firecracker.
- **Memory.** "2-6MBs of memory suffice for Unikraft guests" for the
  applications tested.
- **Size.** Images for helloworld, nginx, Redis and SQLite are "all under
  2MBs".
- **Speed.** Redis and nginx ran "around 30%-80% faster" than in a container
  and "70%-170% faster" than in a Linux VM, on a single core.

## What a unikernel gives up

The same design removes things general code relies on. Unikraft is direct
about it:

- **One application per image.** Isolation between applications comes from
  running each in its own VM; inside, there is one address space.
- **Partial Linux compatibility.** Unikraft implements Linux system calls
  through a shim, and a missing call is stubbed "by returning ENOSYS." It
  reports that applications tolerate a lot of stubbing, and it offers a
  binary-compatibility layer that runs unmodified Linux ELF binaries "with a
  slight performance hit." Support grows call by call.
- **A build step per application.** The image is compiled for one program with
  Unikraft's `kraft` tool and KConfig, not assembled at run time by installing
  packages.
- **Security features still arriving.** The feature table on Unikraft's
  security page lists stack
  protection, UBSan and several Arm protections as upstream, KASAN and PIE as
  under review, and Intel CET and FORTIFY_SOURCE as planned.

## Side by side

|                      | Unikernel (Unikraft)                                           | MicroVM (Firecracker, Linux guest)                        |
| -------------------- | -------------------------------------------------------------- | --------------------------------------------------------- |
| What is minimized    | The operating system, built per application                    | The virtual hardware                                      |
| Inside the VM        | One application linked with library OS parts                   | A full Linux kernel and user space                        |
| Address spaces       | One, no kernel/user split                                      | Kernel and user, as in any Linux                          |
| Processes            | A single application                                           | Any number of processes                                   |
| Compatibility        | Linux system call shim; ELF loader for unmodified binaries     | Linux, so Linux programs run unchanged                    |
| Software install     | Rebuild the image                                              | `apt`, `pip`, `npm` at run time                           |
| Boot, as published   | Under 1 ms guest boot on Firecracker, in Unikraft's evaluation | Up to 125 ms to guest init, in Firecracker's spec         |
| Memory, as published | 2 to 6 MB per guest, in Unikraft's evaluation                  | Up to 5 MiB for the VMM, in Firecracker's spec            |
| Isolation boundary   | The hypervisor                                                 | The hypervisor                                            |
| Best at              | One known service, many copies, very fast start                | Arbitrary programs, including ones nobody has seen before |

The boot and memory figures come from different measurements of different
things; neither is a head-to-head test.

## Can a unikernel run AI agent code?

Not the usual kind. A coding agent runs a shell, installs packages it picked a
moment ago, starts compilers, test runners and servers, and chains processes
with pipes. That needs a general kernel with a user space and a package
manager. A unikernel is built for the opposite: one application, known when
the image is compiled.

Where a unikernel fits an AI system is the fixed service around the agent: an
API server, a proxy, a function with a known entry point that must start in
milliseconds and use a few megabytes.

## When each fits

- **Pick a unikernel** for one known service you control and run in many
  copies: network functions, proxies, stateless HTTP handlers, serverless
  functions where every millisecond and megabyte counts, and you can rebuild
  the image when the code changes.
- **Pick a microVM with Linux** for code you do not know in advance: agent
  sandboxes, user-submitted programs, CI jobs and dev environments, where
  anything on Linux must simply work.

## Why Runtime runs Linux microVMs

Runtime's job is running code nobody has seen yet, so each sandbox is a
Firecracker microVM with Ubuntu 24.04, Python 3.12, Node.js 24, Bun, git and
gcc, and `sudo` working ([environment](/docs/sandbox-environment)). Anything
else installs the usual way, and any Dockerfile builds into a custom image
([images](/docs/images)). Network, CPU, memory and cost are enforced on the
host, outside the guest ([security](/docs/security)).

```ts
import { Sandbox } from "withruntime";

await using sbx = await Sandbox.create();
const run = await sbx.exec("ps -e --no-headers | wc -l && python3 --version && node --version");
console.log(run.stdout); // a full Linux user space, many processes
```

```python
from withruntime import Sandbox

with Sandbox.create() as sbx:
    run = sbx.exec("ps -e --no-headers | wc -l && python3 --version && node --version")
    print(run.stdout)  # a full Linux user space, many processes
```

Try it on the free trial, 50 sandbox hours with no card:

```bash no-run
npx withruntime sandbox run --trial -- cat /etc/os-release
```

More: [what is a microVM?](/glossary/microvm),
[what is a cold start?](/glossary/cold-start),
[QEMU vs Firecracker](/compare/qemu-vs-firecracker),
[WebAssembly vs microVM](/compare/webassembly-vs-microvm).

## Sources

Checked 25 September 2026.

- Unikraft: [concepts](https://unikraft.org/docs/concepts), [virtualization](https://unikraft.org/docs/concepts/virtualization), [compatibility](https://unikraft.org/docs/concepts/compatibility), [performance](https://unikraft.org/docs/features/performance), [security](https://unikraft.org/docs/features/security), [licence](https://github.com/unikraft/unikraft/blob/staging/COPYING.md)
- [Firecracker](https://firecracker-microvm.github.io/), [FAQ](https://github.com/firecracker-microvm/firecracker/blob/main/FAQ.md), [specification](https://github.com/firecracker-microvm/firecracker/blob/main/SPECIFICATION.md)

Facts on this page were checked on 25 September 2026.