Nanos: the unikernel that runs one application per VM

What problem Nanos solves, and who it is for

A general-purpose Linux guest carries a lot that a single service never touches: an init system, a package manager, a login stack, a shell. Nanos removes that layer by design. The README describes it as "a new kernel designed to run one and only one application in a virtualized environment", and lists the constraints plainly: it is a single process system, it does not run multiple programs, and it has no concept of users or remote administration over SSH.

That makes the target audience narrow and specific. If you ship one service per VM and you control the build, Nanos turns the guest into a launcher for your binary. The repository topics point the same way: edge, microservice, sandbox, unikernel. The project also points readers at CHARTER.md for the reasoning behind the constraints, which is worth reading before you assume a missing feature is an oversight rather than a decision.

The people this is not for are just as clear. Anyone who needs to log into a box, run a cron daemon, install a package at runtime, or host several processes on one machine is outside the design. Nanos is not a smaller Linux; it is a different contract between the kernel and the application.

How Nanos works: one process, bootloader plus kernel plus klibs

The build produces three kinds of artifact. The Makefile's kernel target builds the bootloader and the kernel, and the release target copies boot.img, a UEFI loader (bootx64.efi on x86_64, bootaa64.efi on aarch64) and kernel.img into a release directory, alongside a klibs directory. Klibs are the loadable pieces that add functionality the base kernel does not carry, and the release rule copies everything from the platform bin directory except test binaries, debug files and the kernel itself.

Third-party code is vendored rather than assumed to be on the host. The Makefile fetches ACPICA, a NanoVMs fork of lwip for networking, and a NanoVMs fork of mbedtls, each pinned to a branch or tag. That means a build pulls network dependencies at make time, and it means the TLS and network stack you get is the one the project pins, not whatever your distribution ships.

For normal use you do not assemble those pieces by hand. The README is explicit that ops, the build tool at ops.city, is the intended path: "Please use the ops build tool to run your applications with Nanos unless you plan on hacking on Nanos itself." ops supplies defaults, handles image construction, and, according to the README, can deploy to public clouds including AWS, GCE and Azure. The coupling is acknowledged in the README, which notes ops is "currently highly coupled to Nanos". If you are not modifying the kernel, ops is the interface; the Makefile is for kernel work.

Installing Nanos and running a first example

The quick start in the README installs both ops and nanos with one script. It is the supported entry point for application work.

curl https://ops.city/get.sh -sSfL | sh

After that, the README directs you to the ops-examples repository for ready-to-use examples of applications running on Nanos. That is where the first real run belongs: pick an example, build it with ops, and boot it. The README does not spell out the per-example commands, so the exact invocation comes from ops-examples rather than from this repository.

If you intend to build the kernel itself, the Linux dependency list is short. The README gives this command for the base toolchain.

sudo apt-get install qemu-system-x86 nasm golang-go

For the test suite it adds ent and ruby. Go is only needed for certain examples, not for building the kernel. After the toolchain is in place, the kernel is built with a single make target.

make kernel

Examples live under test/runtime, and the Makefile defaults TARGET to webg. Running the default example with hardware acceleration is one command, and the same command without acceleration is the fallback when KVM or HVF is unavailable.

make run
make run-noaccel

To run a specific example, you set TARGET on the command line, for example make TARGET=<example> run. The README warns that running inside a VM already is "a bad idea" because you lose hardware acceleration; the project supports KVM on Linux and HVF on macOS. If you want to develop against a released kernel rather than a fresh build, the README documents copying boot.img and kernel.img into a versioned directory under ~/.ops, plus the klibs if you need them.

The constraints you inherit: no users, no SSH, no second process

The limitations are stated up front rather than discovered later, which is unusual and useful. There is no user model, so there is no privilege separation inside the guest and no login. There is no SSH, so remote administration in the usual sense does not exist. There is no support for running multiple programs, so a sidecar process, a supervisor or a shell for debugging is not part of the picture.

That shapes debugging. When something fails, you cannot log in and look around. The repository carries gdbinit files for x86-64, aarch64 and riscv64, which suggests kernel-level debugging is the intended path, and the test suite is run with make test-noaccel. Neither of those helps you inspect a running application the way an SSH session would.

The platform support is also narrower than a Linux guest's. The README says you can build and run on macOS and Linux, with KVM on Linux and HVF on macOS for acceleration. Building on macOS means installing a specific toolchain through Homebrew taps, including a NanoVMs fork of qemu, and the README recommends running the latest qemu to avoid issues. On ARM-based Macs the dependency list differs from Intel-based ones. None of this is hidden, but it does mean the build environment is part of the adoption cost.

One more practical constraint sits in the Makefile: the kernel target fetches vendored dependencies over the network at build time. An offline or air-gapped build needs those repositories available some other way.

Where Nanos is the wrong tool

Choose something else if your application is not one process. A service that forks workers, shells out to a helper binary, or expects a package manager at runtime will not fit, because the README states Nanos does not run multiple programs. A container runtime on a shared host solves that problem with a much larger surface area, and that trade is deliberate.

Choose something else if operators need to get into the machine. No users and no SSH means the recovery story for a misbehaving instance is redeploy, not log in and fix. Teams whose incident response starts with an SSH session should treat that as a hard blocker rather than a gap to work around.

Choose something else if you need a general-purpose guest for compatibility reasons. Nanos targets a single application in a VM, and the README frames the constraints as the point of the design, not as a roadmap of missing features. If your workload needs the Linux userland, you need Linux.

Finally, be careful about nested virtualization. The README calls running Nanos inside a VM already "a bad idea" because hardware acceleration is lost, and notes that running it in VirtualBox on a Mac is slow and hard to configure. If your only environment is a VM, the experience will not represent production.

How Nanos differs from a container runtime

The closest familiar alternative is a container runtime on a Linux host, and the difference is where the isolation boundary sits. A container shares the host kernel and isolates processes with namespaces and cgroups; the guest operating system is the host's, and the container carries a userland. Nanos goes the other way: each application gets its own kernel inside a virtual machine, and that kernel does nothing except run the one process.

That changes what you have to trust and what you have to maintain. There is no shared kernel between tenants, so a kernel vulnerability is not automatically a cross-tenant path, and there is no host userland inside the guest to patch. The flip side is that you no longer have the container ecosystem: no image registry workflow by default, no exec into a running container, no sidecars. You also give up the ability to run several processes per instance, which many deployments rely on for logging agents or proxies.

The README's own framing supports this reading. It lists the constraints on Nanos compared to "a general purpose operating system such as Windows or Linux" as the defining characteristic. The comparison is not about which is faster in the abstract; it is about how much guest software you are willing to operate. Nanos asks for less, and in exchange it asks you to give up the tools that assume more.

Maintenance, upgrades and licence

The repository is not archived, and the last push was on 2026-09-21, which is three days before this writing. The most recent release is 0.1.56, dated 2026-09-21, following 0.1.55 on 2026-04-26 and 0.1.54 on 2025-06-05. The gap between 0.1.55 and 0.1.54 is roughly eleven months, and the gap between 0.1.55 and 0.1.56 is roughly five months, so release cadence is not uniform. Plan upgrades around releases rather than around a fixed schedule.

For application work, the upgrade path runs through ops, which the README says is highly coupled to Nanos. That coupling means the ops version and the Nanos version move together in practice; the README's development idiom of copying boot.img and kernel.img into a versioned ~/.ops directory shows the version directories are the unit of switching. If you build the kernel yourself, the vendored dependencies pinned in the Makefile (ACPICA, the NanoVMs lwip fork, the NanoVMs mbedtls fork) are part of what changes between builds, so a rebuild is not only a kernel change.

The licence is Apache-2.0, which is a permissive licence with an explicit patent grant. The repository also carries a SECURITY.md and a CHARTER.md. Whether the vendored third-party components carry compatible terms is something to check in their own repositories, since this article is not legal advice and the Makefile only shows where they are fetched from.

Editorial conclusion

Adopt Nanos when your workload is one static or self-contained binary per VM and you want the guest to do nothing else: install ops, run an example from ops-examples, and confirm the image boots under KVM on Linux or HVF on macOS before committing. Do not adopt it for multi-process hosts, shared-user machines or anything that needs SSH administration, because the README states Nanos has no user concept and no remote administration. Before rolling it out, verify that your language runtime and its dependencies produce a working image, and check whether the klibs you need ship with the release you install.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. nanovms/nanos on GitHub
3. Project website
4. README
5. Releases