OSv: a Linux binary compatible unikernel now maintained by volunteers

One unmodified Linux binary per microVM, no recompilation

The design goal is stated in the first paragraph of the README and everything else follows from it: OSv is an open source modular unikernel that runs a single unmodified Linux application as a microVM on a hypervisor, rather than serving a general purpose operating system across a range of physical machines.

The word that matters is unmodified. OSv is not asking you to rebuild your application against a different libc or target a different syscall interface. It runs existing x86-64 and aarch64 Linux binaries as they are, which the README describes as making it a Linux binary compatible unikernel, with a separate wiki page on ABI compatibility for the details.

That design pays off most clearly with managed language runtimes. The README lists the JVM, Python, Node.js, Ruby and Erlang as runtimes OSv can host, plus native code in C, C++, Go and Rust, and native images from GraalVM and from WebAssembly through Wasmer. Each of those is a separate example project in a sibling repository, `osv-apps`, rather than something described but not demonstrated.

The stated boot figure is about 5 ms on Firecracker with as little as 11 MB of memory, and the supported hypervisor list runs from QEMU and KVM through Firecracker, Cloud Hypervisor, Xen, VMware, VirtualBox and Hyperkit, with AWS EC2, Google Compute Engine and OpenStack named as clouds.

capstan for the impatient, scripts/build for the committed

There are two routes to a running image, and the README is direct about which one to pick. The first is `./scripts/build`, a shell script that compiles the kernel from source and fuses it with your application's files. The second is capstan, a separate tool that takes a pre-built kernel and combines it with your application files to produce a final image.

The README's advice is explicit: if you want the least effort, pursue the capstan route. Capstan downloads the pre-built kernel loader, `osv-loader.qemu`, either from the regular OSv releases page or from a nightly releases repository.

If you would rather work from the latest code and you are comfortable with make and a GCC toolchain, the README points at a development environment section further down the same page. The repository root is consistent with that: `Makefile` at the top, `scripts/` for the build driver, `conf/` for build configuration, `core/` for the kernel core, `arch/` for architecture support, `libc/` for the C library layer, `fs/` for filesystems, `modules/` for loadable modules, `apps/` for bundled applications, and `tests/` for the test suite.

The Makefile shows how the two routes meet. Deprecated `make image=` syntax still works by forwarding into the script:

default_target:
	./scripts/build modules=$(modules) $(compat_args)

That module target builds kernel modules rather than images, and the surrounding comments show the project actively steering people away from the old `make` syntax toward `scripts/build`.

musl on top, VFS and scheduler in the middle, drivers at the bottom

The component diagram paragraph in the README describes the layering directly. At the top sits `libc`, described as greatly based on musl. In the middle is the core layer, made up of the ELF dynamic linker, VFS, the networking stack, the thread scheduler, the page cache, RCU and memory management. At the bottom are the clock, block and networking device drivers that let OSv talk to hypervisors.

The repository tree backs that description up in a way you can check. `linux.cc`, `loader.cc` and `runtime.cc` sit in the root as the kernel's core translation units. `exported_symbols/` at the root holds the symbol lists, which is how a Linux binary finds what it expects to find. `musl` appears three times over, alongside `musl_0.9.12` and `musl_1.2.1`, which tells you the libc has been versioned in place rather than swapped.

The original design is documented outside the repository. The README links a USENIX ATC 2014 paper and presentation for the architecture, and a wiki page titled Components of OSv for the current description. It also warns that some of the material at `osv.io` and the project blog may be out of date and suggests asking on the mailing list when in doubt, which is an unusual amount of honesty about documentation drift in a project README.

Filesystem support is more than one filesystem. The root carries a family of manifest skeletons (`bootfs.manifest.skel`, `usr.manifest.skel`, `usr_rofs.manifest.skel`, `usr_ramfs.manifest.skel` and variants), which is how an image is described before it is built, and ZFS code sits in the tree with its own builder assembly file at the root.

Releases two to three times a year, most recently in December 2022

The stated release cadence is two to three times a year, and the actual record shows how that has drifted. Version 0.55.0, named Stork, shipped on 2020-05-13 and focused on documentation, build system and testing, including a Travis based pipeline publishing nightly artifacts and Docker build toolchain images. Version 0.56.0, Nightingale, followed on 2021-07-19 with a musl upgrade from 0.9.12 to 1.1.24, substantially better aarch64 support, and Virtio-FS with DAX window support for faster reads.

Version 0.57.0, Magpie, published on 2022-12-20, is the most recent release and its contents describe exactly the kind of work a maintenance phase produces: a build mode to hide non-glibc symbols and libstdc++, ZFS extracted out of the kernel into a dynamically linked library called `libsolaris.so`, driver profiles, a mechanism to build a kernel with only the glibc symbols a specific application needs, and experimental lazy stack support. There are also driver work, VFS enhancements and support for the `SO_REUSE_PORT` socket option.

That symbol trimming is the most technically interesting item in that release. Building a kernel that exports only what one application needs is the correct direction for a unikernel, since the whole argument is that you do not carry code you do not use.

The nightly pipeline is still described as active, with every commit to the master and ipv6 branches triggering a full build and publication to the nightly releases repository. The last push to this repository was on 2026-08-17, which is well after the last release.

The project says plainly that it loses to Linux on disk I/O

There is a metrics and performance section and it opens by saying there are no official up to date performance metrics comparing OSv to other unikernels or to Linux. That is a more useful sentence than a benchmark table, because it tells you the author knows the comparison is not settled.

What follows is a specific admission: OSv lags behind Linux in disk-I/O-intensive workloads, attributed partly to coarse-grained locking in VFS around read and write operations, with an issue number given for the detail. On network-I/O-intensive workloads the README says OSv should fare better, and the text cuts off mid-sentence there in the version available.

The 5 ms boot and 11 MB memory figures earlier in the README are the project's own numbers and the surrounding text does not attach hardware or hypervisor configuration to them beyond naming Firecracker.

One framing point: the 5 ms figure is measured on top of a hypervisor, so it is not a comparison against booting a full Linux VM. What the number tells you is how much of the boot cost is kernel, and how much of it is the virtual machine monitor underneath.

A research project that became infrastructure nobody depends on

The maintenance note at the top of the README is the most important paragraph in it. OSv was originally designed and implemented by Cloudius Systems, now ScyllaDB, and is currently maintained and enhanced by a small community of volunteers. The project asks systems programmers to contact it through a Google Group forum, points newcomers at issues labelled good for newcomers, and accepts pull requests.

382 open issues against 4,263 stars is a backlog that no active maintainer is clearing, which is consistent with the volunteer framing.

Two build systems are maintained side by side, a Makefile with a `conf/` hierarchy and a `scripts/` driver, and cmake directories that appear in a few sibling projects. ZFS support is deep enough that it has its own builder in assembly and was extracted into a shared library in the last release, and driver work covers KVM, Xen, VMware, VirtualBox, Firecracker and Cloud Hypervisor.

The honest summary is that OSv solved the hard part, running unmodified Linux binaries in a purpose-built kernel, and then the cloud moved to microVMs that could run those binaries with the kernel you already had. Unikernels remained commercially interesting through Firecracker and the container layer rather than through a standalone OS, and OSv sits beside that outcome with a working system, a documented ABI and a much slower commit cadence than the field it entered.

Editorial conclusion

OSv remains the most complete attempt at a Linux binary compatible unikernel, and the parts of it that mattered most, the ABI work and the managed runtime support, are done and documented in the wiki. What has changed is who is doing the work and how often. A 0.57.0 release in December 2022 after a 2021 and a 2020 release, with the last push on 2026-08-17, describes a project in maintenance rather than development, and the README says as much when it asks volunteers to pick up issues labelled good for newcomers. Start with capstan if you want to run something today, because it downloads a pre-built kernel instead of compiling one, and read the metrics section carefully, since the project's own admission that it trails Linux on disk I/O is the honest part of the performance story.

Frequently asked questions

Official sources

1. cloudius-systems/osv on GitHub
2. Issues
3. README
4. Releases