Unikernels, without the marketing

TL;DR

A unikernel is your app compiled together with only the OS pieces it really needs, producing a tiny binary that boots inside a microVM (e.g., Firecracker/KVM).
Result: fast starts, small footprint, and stronger isolation than containers, at the cost of trickier tooling and ops around it.

When I saw Prisma put “serverless” and “no cold starts” in the same breath for Prisma Postgres, my Lambda scars tingled 😄

I had to see what was under the hood! And the trail leads to unikernels, single-purpose operating systems that boot in milliseconds because they include only what the app needs.

Prisma Postgres runs on Unikraft, one of the most mature takes on the idea. Unikraft compiles your app together with just-enough OS components into a tiny image that runs on a hypervisor like KVM or Xen. The expected result is a near-instant startup, tight isolation, very small footprints, and ⟦security⟧!
Let’s see how that works.

What a unikernel is / isn’t

A unikernel is: a single-purpose OS+app image. You pick only the needed libraries (network stack, libc, drivers), link them with your code, and ship one small binary.

A unikernel isn’t: a general-purpose Linux distro with init, package manager, shells, SSH, and dozens of services you might never use.

Because the image is minimal, the boot path is short and the memory/CPU footprint is small. And also the “snapshot/restore” logic (see below).

Mental model

Containers: start a process in a shared kernel; initialize your whole runtime and framework.
Unikernels: resume a tiny VM that already has your runtime warmed and only the code it needs.

Why cold starts can be “milliseconds”

Tiny images: less stuff to load, fewer init steps
MicroVMs: launch quickly via KVM with a “minimal device” model
Snapshot/restore: the platform can pre-initialize the VM, snapshot it, store, and later resume that already-warmed state on demand.
That turns a cold start into mostly “restore RAM + run”. Neat! 😎

Trade-offs

The balance sheet looks something like this:

Pros

Fast start/resume. Great for scale-to-zero and bursty workloads.
Likely a save on idle. Fast cold starts let you scale to zero without user-visible lag.
Performance per watt/€/$/₴: less OS overhead and fewer context switches mean better throughput on the same hardware.
Security posture: reduced attack surface vs. a full OS. The “living off the land” tactics become harder – there’s simply less “land” to live off.

Cons

You may pay in migration/time-to-first-byte of tooling: adapting build pipelines, observability, and incident workflows takes real effort. Tooling and debugging are less familiar than “ssh into a container”.
Language/runtime support varies. Not every stack is turnkey.
Packaging, observability, and local dev loops will definitely need new habits.
Your team may or may not like that.

In comparison with VMs and containers

VMs: full general-purpose OS per guest. Great isolation. Heavier to boot and patch.
Containers: share the host kernel. Lightweight. Isolation is good but not hardware-enforced. You’re still carrying a userspace OS.
Unikernels: your app + a minimal, library-OS runtime compiled together. Hardware-level isolation from the hypervisor. Very small image, fast boot. Minimal attack surface.

When to use vs when to skip

When unikernels make sense

Serverless-style workloads where latency matters and traffic is spiky.
Single-purpose services: API gateways, auth token minting, feature flags, small data processors.
Edge deployments where resources are tight and cold starts hurt.

When to skip

Big, stateful apps needing a full OS userland.
Teams that depend on shelling in, live patching, or heavy in-place debugging.
Heterogeneous stacks without good unikernel support.

Architecture patterns that work well

In practice, unikernels shine when treated as stateless compute: push all state to external services like DBs, object storage, queues, and let the kernel do pure work. Build immutable images so that dependencies and the runtime are baked in. Deployments become a matter of rolling forward or rolling back to a versioned image.

For blast-radius control, use per-tenant isolation: make a micro-VM per tenant or per class of request and enforce quotas and network policy at the hypervisor boundary.

Finally, ship to the edge: build once, distribute tiny images across PoPs, and rely on configuration or feature flags to adapt behavior at runtime.

Developer experience: build – run – operate

Build: app code links against a library OS (network stack, filesystem shims, timers).
Image: the output is a bootable artifact (tens of MB).
Run: launch it on a KVM/Firecracker/Xen host (cloud or on-prem). No guest OS to boot since the app is the OS.
Operate: use the hypervisor/host for lifecycle (start/stop/scale), and your platform for metrics/logs.

⛳️ Expect a learning curve: your team may need time and investment to build these skills.

Final thoughts and links

Unikernels compile an application together with only the OS components it needs into a tiny image that runs in a microVM (e.g., Firecracker/KVM), enabling near-instant starts, small footprints, and strong isolation. Millisecond-level “cold starts” come from minimal images, fast-launching microVMs, and snapshot/restore of pre-warmed states.

Compared with VMs and containers, unikernels trade general-purpose flexibility for a minimal library-OS runtime and a smaller attack surface. They fit spiky, serverless-style or edge workloads and small, single-purpose services, especially with stateless designs, immutable images, per-tenant isolation, and edge distribution.

The flip side is a learning curve and ecosystem gaps: tooling, observability, debugging, and language/runtime support often require new habits and investment. The good news is that platforms such as Unikraft can abstract much of this complexity.

Learn more

Note: This post is not sponsored by or affiliated with Prisma or Unikraft.

Unikernels, without the marketing

TL;DR