Unikernels are one of those ideas that periodically come back, promise a lot, and then fade. The first wave was around 2015 with MirageOS, IncludeOS, and HaLVM; the promise was running applications as specialized kernels of a few megabytes that booted in milliseconds with minimal attack surface. Interest diluted once Docker and Kubernetes ate the deployment world.

Ten years later, Unikraft has spent a couple of years approaching the same terrain with a different pitch. With its stable release published, it is time to check whether the idea works this time.

Key takeaways

  • A unikernel is application + libraries + OS parts compiled together as a single binary that boots directly on KVM or Xen.

  • Unikraft differs from the first wave in three aspects: modular architecture, a Docker-style kraft tool, and a catalog of ported applications.

  • Real numbers: boot in 30-50 ms (vs. 400-800 ms for a container nginx), 2 MB image size.

  • Fits three niches: serverless platforms, workloads needing strong isolation, and edge computing with extreme resource constraints.

  • Does not fit a typical enterprise application, with its dependency tree and fast development cycles.

What exactly is a unikernel

A unikernel is an executable image that bundles into a single binary the application, the libraries it needs, and the operating-system parts the application uses. There is no generic kernel; there is a kernel built specifically for that application, with only the drivers and subsystems it requires. The result boots directly on a hypervisor like KVM or Xen, without going through an intermediate operating system.

The comparison with familiar models helps understand the saving:

  • Minimal Linux VM: hundreds of megabytes, thousands of processes, drivers, and services the application never uses.

  • Container: lighter because it shares the kernel with the host, but still requires user space with libraries, tools, and sometimes an init system.

  • Unikernel: solely the application and what it needs, compiled together as a single artifact.

The consequences are concrete:

  • Boot times drop to tens of milliseconds.

  • Minimal attack surface: no shell, no users, no installed packages that may hide vulnerabilities.

  • Image size of one to ten megabytes for a simple application.

  • Potentially better performance because application and kernel are compiled together.

Why the first wave failed

What sank MirageOS and company was not technical but practical. The problems were:

  • Language dependency: MirageOS served only OCaml, HaLVM Haskell, IncludeOS C++. If your team used none of those, there was no path.

  • Complex compilation: required deep knowledge of how the host hypervisor worked, and debugging meant reading raw memory traces.

  • Operational ecosystem not ready: deploying in production required dropping abstraction down to the hypervisor, which few cloud providers made easy. Orchestrators did not understand the model.

Meanwhile, Docker solved 80% of what unikernels targeted at a fraction of the adoption cost. Unikernels stayed as an academic curiosity.

What Unikraft does differently

Unikraft started in 2017 as an incubation project of the Xen Project under the Linux Foundation umbrella[1]. In 2023 the founding team spun out as an independent company, a NEC Laboratories Europe spin-off backed by its own European and US venture funding[2]. The stated intent was to take it to production. The value proposition differs in three concrete points:

  • Modular architecture. Unikraft does not pick a language or specific library: it is a build framework where you combine a POSIX compatibility layer, a C standard library, drivers, a scheduler, and the application as interchangeable pieces. A C, Python, Go, or JavaScript application can be compiled as a Unikraft unikernel by adding the right layers.

  • The kraft tool. Offers a Docker-like command-line experience. With kraft run you boot a unikernel on local KVM in seconds, with environment variables, networks, and volumes declaratively configured.

  • Catalog of ported applications. The official catalog ships redis, nginx, node, python, mongodb, and several dozen more, already packaged as ready-to-run unikernels. That was unthinkable with MirageOS and eases first contact.

Real numbers

In my lab, the measurements are:

Metric nginx unikernel nginx container
Boot time 30-50 ms 400-800 ms
Image size 2 MB 50 MB
Minimum memory 32 MB ~25 MB
Throughput (small responses) +10-20% baseline

Boot is roughly ten times faster. Memory is comparable. Network performance is slightly better for small responses because the network stack lacks usual abstraction layers; for large responses the difference dilutes.

My lab numbers line up with what the project itself publishes. The official performance documentation[3] measures boot times of tens to hundreds of microseconds on QEMU and Solo5, excluding hypervisor time, with images under 2 MB for nginx, Redis, or SQLite. The academic paper that introduced the project at EuroSys 2021[4] reported 30%-80% performance gains over equivalent containers.

On security, the structural argument is clear: no shell, no package manager, no processes beyond the application. A vulnerability in the application remains exploitable, but post-compromise escalation is much harder because there are no native tools for an attacker.

Where it fits and where it does not

Unikraft fits particularly well in three scenarios:

  • Serverless platforms where fast boot is a differentiator. Booting in fifty milliseconds enables scaling patterns not viable with containers.

  • Highly specialized workloads with short lifecycles: running third-party code, sandboxing for autonomous agents, ephemeral data processing functions. Strong isolation, fast boot, and a tiny footprint arrive together. It is the same goal pursued by user-space kernel isolation in gVisor, but with the application compiled inside the specialized kernel itself instead of intercepting syscalls from the outside.

  • Edge computing with extreme resource constraints: a device with 128 MB of RAM can run two or more Unikraft unikernels where a full VM would not fit. That is the same compute and latency constraint already covered in industrial edge computing.

Where Unikraft does not fit:

  • Typical enterprise applications with large dependency trees and fast development cycles.

  • Teams already running Kubernetes with containers and no boot or density problems.

Conclusion

Unikraft is the most serious attempt to date to bring unikernels to production, and it is a better experience than MirageOS offered a decade ago. Unikernels will remain niche technology, but that niche is bigger now. Three currents create use cases where they have real advantage: the explosion of serverless platforms, the interest in running untrusted code with strong isolation, and the need for efficiency at the edge.

For anyone designing a new platform with serverless patterns or strong isolation as a requirement, Unikraft deserves a serious proof of concept. For those operating classic infrastructure, better to follow the project closely before investing adoption time.

This article is also available in Spanish.

Sources:

  1. Linux Foundation — Xen Project Introduces the Unikraft Unikernel Project[1]
  2. NEC Laboratories Europe — Unikraft raises seed funding and begins operation as an independent company[2]
  3. Unikraft — official performance documentation[3]
  4. Kuenzer et al. — Unikraft: Fast, Specialized Unikernels the Easy Way (EuroSys 2021)[4]

Frequently asked questions

Do I have to rewrite my application in another language to run it as a Unikraft unikernel?

No. Unlike the first wave (MirageOS only for OCaml, HaLVM for Haskell, IncludeOS for C++), Unikraft is a modular build framework. It combines a POSIX compatibility layer, a C standard library, drivers, a scheduler, and the application as interchangeable pieces, so a C, Python, Go, or JavaScript application can be compiled with the right layers. The official catalog also already ships redis, nginx, node, python, mongodb, and several dozen more packaged as ready-to-run unikernels.

How much faster does a unikernel boot than a container?

Ten times faster to boot: in the lab, nginx as a unikernel boots in 30-50 ms versus 400-800 ms for the same nginx in a container. The image is 2 MB versus 50 MB. Minimum memory is comparable (32 MB versus about 25 MB) and throughput on small responses is 10-20% higher because the network stack lacks the usual abstraction layers; for large responses the difference dilutes.

Should I migrate to Unikraft if I already run Kubernetes with containers?

If you have no boot or density problems, no: Unikraft does not fit typical enterprise applications with large dependency trees and fast development cycles, so follow the project before investing adoption time. It deserves a serious proof of concept in three niches. The first two are serverless platforms, where booting in fifty milliseconds enables new scaling patterns, and workloads needing strong isolation, such as running third-party code or sandboxing agents. The third is edge computing on devices with 128 MB of RAM.

Sources

  1. incubation project of the Xen Project under the Linux Foundation umbrella
  2. NEC Laboratories Europe spin-off backed by its own European and US venture funding
  3. official performance documentation
  4. academic paper that introduced the project at EuroSys 2021