Our 2013 ASPLOS paper, "Unikernels: Library Operating Systems for the Cloud", received a test-of-time award in March 2025. The title says "for the Cloud." We wrote it while I was in Jon Crowcroft's group at the University of Cambridge. The core idea: instead of running an application on a general-purpose OS, compile the application and only the OS libraries it needs into a single sealed image that runs directly on a hypervisor. No kernel, no shell, no unused drivers. Our DNS server image was 200 KB. The BIND appliance it replaced was over 400 MB.
Five properties fell out of that architecture. None of them are unique to unikernels (a careful Yocto configuration can achieve most of them), but unikernels make them the default. I think they hold up better now than they did in the cloud:
- Sealed images. The binary is fixed at compile time. No runtime package installation, no configuration files, no shell to log into.
- Dead code elimination. If the application does not use the filesystem, the filesystem is not in the binary.
- Single address space. One application, one address space (no internal process isolation, the hypervisor provides isolation between unikernels).
- Configuration is compilation. Network addresses, TLS certificates, and firewall rules are baked in at build time. No configuration parser at runtime means no configuration parser to exploit.
- Small trusted computing base. The TCB is the hypervisor plus the application. No general-purpose kernel, no init system, no sshd.
Traditional VM
MirageOS unikernel
Anil, Balraj and I co-founded Unikernel Systems to bring this to production. Docker acquired us three months later. At Docker, we built Docker Desktop from scratch, adding MirageOS unikernel components to the networking stack via vpnkit (we wrote an ICFP paper about how that works). Millions of developers use it daily. Meanwhile, containers won the cloud and Unikraft took the unikernel deployment model in a POSIX-compatible direction for serverless. The unikernel-as-product did not take over (yet!), but the libraries shipped further than we ever expected.
In 2021, when Tarides joined Cyber@Station F, I pitched unikernels to over thirty internal teams at Thales: cyber, compliance, transport, defence, ... Most were politely interested. The one that clicked was Régis de Ferluc at Thales Alenia Space. His reaction was not "that is interesting" but "that is how we already build embedded systems, but done in a principled way (and where you can safely introduce dynamic behaviour)."
He was right. Satellite flight software ships as fixed binaries, qualified on the ground, no shell access in orbit, no runtime configuration changes. The five properties above are not innovations in space, they are requirements. What satellite software does not have is the type safety, the tooling, and the library ecosystem that OCaml and MirageOS provide.
Régis pushed us to look deeper, introduced us to EU programmes (ORCHIDE via Horizon Europe, CEOS), and SpaceOS was born. Miklos and I co-founded Parsimoni to build it.
The ASPLOS paper asked whether sealed, single-purpose images could improve cloud infrastructure. Twelve years later, I think the more interesting question is whether those same properties matter more in constrained environments (satellites, hardware security modules, embedded controllers) where every kilobyte counts, you cannot ssh in after deployment, and "no unused code" is not an optimisation but a qualification requirement.
