AI is reviving unikernels, the single-purpose operating systems that were once too hard to build

Unikernels — operating systems compiled to run a single application and nothing else — are drawing renewed attention, and a widely shared essay by developer Geoffrey Huntley argues the revival is being driven by AI coding tools that have removed the friction which kept the technology niche for a decade.

The post on Huntley's site, which reached the front page of Hacker News, grew out of a conversation with Justin Cormack, an engineer who worked on the MirageOS unikernel project and at Unikernel Systems, and who has been running a series of newsletter interviews on the topic after noticing the same wave of rediscovery.

What a unikernel is

A unikernel inverts the usual software stack. Rather than an application sitting on top of a general-purpose operating system, the application is compiled together with the libraries it needs. There is no userland: nothing to fork, nothing to spawn, no shell. If the workload needs a web server, DNS or email, those arrive as libraries linked into the image.

Huntley first encountered the idea around 2015, arriving through Haskell and OCaml circles at MirageOS. The concept worked; the surrounding ecosystem did not. According to Cormack, Mirage had TCP and HTTPS stacks but almost nothing for storage, and the team extracted drivers from NetBSD that could be run outside the kernel. That gap-filling effort is what earned unikernels their reputation for difficulty.

Why AI changes the calculus

Huntley's core claim is that the industry's folk wisdom — that Nix is hard, that Bazel is hard, that unikernels are hard — has since been absorbed into today's AI models, so difficulty alone is no longer a reason to avoid an approach. The classic blocker was a missing library: if the application must talk to Stripe and no OCaml binding exists, a developer once had to write one by hand. His remedy is to have an agent port an existing Go implementation and iterate until it works.

The underlying technique is porting against a reference: keep the original tool as the oracle, generate outputs from both implementations, compare them, and port the tests across. Cormack described doing exactly that while building minimal Linux appliance images, which he notes are already close to a unikernel since a single application runs as PID 1. Needing to create an XFS filesystem without pulling in all of xfsprogs, he had an agent write mkfs.xfs in Rust, matching the original's output byte for byte with every command-line flag handled and tests across block sizes, all within a few hours.

The storage gap gets a different answer: treat S3-compatible object storage as the primary, growable store with a local NVMe cache in front of it — a pattern Huntley attributes to turbopuffer and says Cormack also favors. When upstream dependencies are broken or compromised, a Nix overlay lets an agent patch the problem directly instead of waiting on a maintainer who may be on holiday or long gone.

The security case, and the pushback

Huntley frames the general-purpose operating system as what he calls design debt: it exists in its multi-user form because, decades ago, a person sat in front of the machine. When a conventional application is compromised, the shell an attacker lands in becomes a convenient staging ground for stealing data. In a unikernel, functionality that is not compiled in simply is not there — and, he argues, an attacker's AI tooling has no playbook for a machine with no shell and no interpreter, which turns opportunistic attacks into targeted ones requiring the source code.

Cormack pushed back during their conversation: attack-surface claims are often fuzzy, stripped-down Linux containers still contain effective interpreters, programs can be executed without a writable filesystem, and memory-safety bugs and gadget chains remain. Huntley's answer is that the industry has spent decades trimming away at attack surface — from the old advice to keep compilers off production systems to modern hardened build pipelines — instead of designing systems without one. His summary position: use the formally verified seL4 where guarantees are paramount, and consider unikernels otherwise, noting that even the old criticism of running everything in a single privilege ring is now largely a prompt away from being addressed. Huntley also mentions spaceleans, a distributed unikernel operating system he has been prototyping, including an NTP client so that a fleet of unikernels can keep time.

Why it matters

The essay is less a unikernel tutorial than a signal of where deployment thinking is heading: single-purpose, minimal operating system images instead of hardened general-purpose ones. The security backdrop sharpens the timing — Huntley notes that the week the conversation was recorded, a KVM vulnerability earned its finder $50,000 from Vercel and a few other vendors, a modest sum for a flaw in the hypervisor beneath Firecracker and much of managed cloud sandboxing. The wider consequence extends past unikernels: if an agent with a good reference implementation can genuinely port software in hours, the missing-library problem that killed promising niche platforms in the past stops being fatal, and the set of foundations considered viable for production software gets larger.