Unikernels are practical again because AI ports the libraries, one post argues

A blog post titled 'unikernels were hard. key word: were.' recounts a pub-side phone conversation between its author and Justin Cormack, who worked on MirageOS and Unikernel Systems back in the day. Cormack is running a series of conversations on unikernels for his newsletter, and the author was first up. Cormack's edited transcript is published at Ignore Previous Directions. The conversation covered Mirage, Orleans, Haskell, Nix and more.

The author defines a unikernel as the idea that the application is the operating system. There is no userland: if you want a web server, DNS or email, there is nothing to fork or spawn, so you write those things as libraries inside the application. That was the friction. Cormack recalls that while Mirage was being built it had a TCP stack and an HTTPS stack but almost nothing for storage, and drivers were pulled out of NetBSD so they could run in userspace. The author first ran into unikernels around 2015, after building a team of Haskellers and finding MirageOS through OCaml. His thesis is that hard concepts such as Nix, Bazel and unikernels are now in the model weights, so you can prompt for them and drop the dogma that they are hard.

The second argument is that the operating system is design debt. The author says multi-user operating systems exist because forty years ago a human operator sat in front of one, and applications were then put on top. Applications get popped, and a shell in a popped userland application is, in his words, a VIP butler service for exfiltration. With a unikernel the attack surface is much smaller: if the functionality is not in the application there is no next hop. He adds that with no shell and no interpreter, the model weights have nothing that knows what to do next, which turns a drive-by attack into a targeted one that needs your source code.

Cormack pushed back. Attack-surface reduction is something people are very fuzzy about: you can remove the shell from a Linux container, yet almost every Linux environment still has something that is effectively an interpreter, you can execute a new program without a writable filesystem, and memory safety and gadgets remain concerns. The author accepts this but points to twenty-six years of the industry chipping away at attack surface, from 'don't put the compiler on production' to build and production containers to Chainguard, instead of ensuring there is no attack surface.

On the classic objection that a unikernel needs a Stripe library and OCaml has none, the author says you now run a loop to port the Go library to OCaml. Cormack's example: building minimal Linux images for appliances, he needed an XFS filesystem. Rather than pull in xfsprogs, he had an agent write mkfs.xfs in Rust with byte-for-byte identical output and every flag interpreted. It reverse-engineered the on-disk formats one by one, with tests across block sizes, in a few hours. The author says this works because the original tool is a golden oracle: generate filesystems at different sizes with both implementations and diff them. For storage he recommends the turbopuffer approach, with S3 as primary storage, a local NVMe block cache and an LRU for hot data, and notes Cormack is a fan of 'S3 for everything'.

The post also praises Nix: NixOS machine tests that spin up a fleet of machines, and overlays for fixing broken upstream packages or supply chain problems. On security it offers two choices: seL4, a formally verified operating system, for those sending satellites into space, and unikernels for everyone else. Early unikernel designs ran everything at a single privilege level, but the author says that in 2026 this is a prompt away from being fixed if you want ring separation. He notes that upstream Linux now expects weekly kernel patching, and that the week they recorded, someone popped KVM (essentially Firecracker) and collected $50,000 from Vercel and a few other vendors.

The author then describes his own project. About seven months before the post he went deep on unikernels to check his mental model, and built a Mirage folder of libraries: an NTP client ported from another language, an NTP server based on RADclock with ideas from TigerBeetle's handling of time, a network stack, DNS, HTTP clients and servers, structured logging, OTel, Anthropic and OpenAI clients, payments via Airwallex, a generic retry library for back pressure, and a PII wrapper at the logging boundary. The most ambitious piece is Spaceleans, Microsoft Orleans ported to OCaml and running as a unikernel: a distributed actor system that merges many machines into one addressable heap. Cormack called it Erlang-esque. The author says he did all of it in a week, will probably never release it, and that it falsified the idea that unikernels are hard.

The closing visible sections cover language choices. The author likes OCaml for agents: functors, .mli files as compact context, good tooling and fast compile times. Cormack mostly writes Rust, where agents do well, but compile time is the tax on back pressure: when compilation is slow each hallucination is expensive. His S3 clone is about a million lines of Rust, and with four agents compiling at once they fight over disk and CPU, so you spend more on fast machines than on tokens. The author is wary of running Haskell in production because of space leaks that only show up there. The available text of the post breaks off mid-sentence in the discussion of Zig.

Key facts

• The author argues unikernels were hard because every service, from storage to Stripe clients, had to be written as an in-application library; AI agents now make porting those libraries cheap.
• Justin Cormack had an agent write mkfs.xfs in Rust with byte-for-byte identical output in a few hours, using the original tool as a golden oracle to diff against.
• The security case: with no shell and no interpreter, a popped application has no next hop; Cormack pushed back that attack-surface reduction is something people are very fuzzy about.
• The author says he built Spaceleans, Microsoft Orleans ported to OCaml running as a unikernel, in a week, and probably will not release it.
• Cost caveat from Cormack's Rust work: his S3 clone is about a million lines, and four agents compiling at once fight over disk and CPU.

Why it matters

The post makes a specific argument about why an old idea might be worth a second look: the cost that kept unikernels niche was the work of writing missing libraries and drivers, and coding agents lower that cost. The author goes further and calls the conventional operating system design debt, left over from an era when a human operator sat at a multi-user machine. If his premise holds, the case for running one application as its own operating system gets stronger, mainly on security grounds. It is a framing piece, not a release or a result.

Who it affects

Teams that run services on Linux containers and spend effort patching and hardening them are the audience the author has in mind; he notes enterprises spend a lot of time patching and that upstream now expects weekly kernel patching. Developers already working in OCaml, Rust or Nix are the closest fit, since the post leans on those ecosystems. It also speaks to people choosing infrastructure staffing: the author contrasts fifty AWS-certified engineers managing AWS with two people using Nix and Hetzner.

How to use it

The post offers a practical pattern rather than a product. When a unikernel lacks a library, have an agent port it from another language and loop until it works; where an original tool exists, use it as a golden oracle and diff outputs across sizes and flags, as Cormack did with mkfs.xfs. For storage, use S3 as primary storage with a local NVMe block cache and an LRU for hot data, provided latency is not the constraint. Use NixOS machine tests to exercise network rules against your application, and overlays to fix broken upstream packages. For OCaml, the author finds .mli files efficient context for agents. Spaceleans is not available: the author says he will probably never release it, and no code or repository is given.

How solid is it

This is a first-person opinion piece. No benchmarks, measurements or independent evidence are offered that unikernels are more secure or faster; the evidence is anecdote: Cormack's mkfs.xfs rewrite and the author's own week-long Spaceleans build. The claim that having no shell or interpreter leaves nothing for model weights to act on is the author's assertion. The text does not say Cormack endorses the author's wider conclusions; he is reported pushing back on the attack-surface claims. The KVM compromise is mentioned without a CVE or a name, and the text does not call the $50,000 a bug bounty explicitly. The available text of the post is also cut off in the section on Haskell and Zig.

Risks and caveats

Cormack's objections stand in the post: removing a shell does not remove every interpreter-like capability, programs can run without a writable filesystem, and memory safety and gadgets remain. Early unikernel designs ran the application and OS in one privilege level, and the author's fix, ring separation, is described only as a prompt away. Agent-written ports carry the usual risk that they are only as good as the tests and oracle behind them, which the author's examples handle by diffing against the original. There is also a cost angle from Cormack's Rust work: slow compilation makes each hallucination expensive, and four agents compiling a roughly million-line codebase compete for disk and CPU, so you may spend more on fast machines than on tokens. The author also says he does not feel good running Haskell in production because of space leaks that only show up there.

“Unikernels were hard. Key word: were. Now we have AI.”

— From the post 'unikernels were hard. key word: were.'