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).

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

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). Anything else installs the usual way, and any Dockerfile builds into a custom image (images). Network, CPU, memory and cost are enforced on the host, outside the guest (security).

TypeScriptimport { 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

Pythonfrom withruntime import Sandboxwith 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:

Terminalnpx withruntime sandbox run --trial -- cat /etc/os-release

More: what is a microVM?, what is a cold start?, QEMU vs Firecracker, WebAssembly vs microVM.

Sources

Checked 25 September 2026.

• Unikraft: concepts, virtualization, compatibility, performance, security, licence
• Firecracker, FAQ, specification

Facts on this page were checked on 25 September 2026.