a unikernel
/ YOO-nee-ker-nel /
A normal application sits on top of a full operating system with thousands of features it never uses - dozens of drivers, a multi-user permission system, a shell, support for hardware you do not have. A unikernel throws all of that away and asks: what if we compiled the application together with only the exact operating-system pieces it actually needs, into a single, tiny, special-purpose machine image that boots and runs that one program and nothing else?
Concretely, a unikernel is built from a library OS: the operating-system functions - a network stack, a filesystem, a memory allocator, a scheduler - are provided as libraries that you link directly into your application, picking only the ones it uses. The result is one image, with your code and its OS support fused together, that runs in a single address space at a single privilege level. There is no separation between user mode and kernel mode here, and no system call boundary - calling the network stack is just an ordinary function call, because it is all one program. You typically run that image directly on a hypervisor as a lightweight virtual machine. The payoff is a tiny attack surface (no shell, no extra services, no unused drivers for an attacker to reach), fast boot, and low overhead.
It matters as a clean idea for specialized, single-purpose deployments - a network function, a microservice - where the generality of a full OS is pure cost. But be candid about the trade-offs that have kept unikernels niche. The very lack of a user/kernel boundary that makes them fast also means a bug in the application can corrupt the 'kernel' parts, since there is no isolation between them - the single address space cuts both ways. They typically run only one process, so you cannot use familiar multi-process tools; debugging and operational tooling are thinner than for a normal Linux; and you must have a library-OS implementation of every OS feature your app depends on. The honest summary: elegant and genuinely useful for the right narrow workload, not a general replacement for a conventional OS.
normal stack: app --syscall boundary--> full Linux kernel (drivers, shell, users, ...) unikernel: [ app + only the OS libraries it uses ] = one image, one address space -> calling the network stack is a plain function call; no user/kernel boundary, no extra services
A unikernel fuses the app with only the OS libraries it needs into one single-address-space image - tiny and fast, but with no internal isolation.
The single address space that makes a unikernel fast also removes the user/kernel protection boundary, so an app bug can corrupt the OS code it is fused with - isolation cuts both ways. Combined with single-process limits and thin tooling, unikernels suit narrow, specialized workloads, not general-purpose use.