DragonOS: a Rust kernel chasing Linux binary compatibility

An independent kernel, not a Linux derivative

DragonOS is described as a 64-bit operating system with a completely independent kernel, developed from scratch in Rust, with Linux compatibility. That combination is the interesting part of the pitch. A kernel written from scratch is not a Linux fork, so it is not constrained by Linux's design history or by the requirement to keep every historical interface alive, and Rust is the language choice the project gives for reliability. At the same time, offering Linux binary compatibility is what would make it usable rather than a curiosity, because the whole Linux software ecosystem assumes a particular syscall and interface surface. The project describes its aim as providing lightweight, high-performance solutions for containerized workloads, and the repository description frames it as designed for serverless scenarios. The target reader is therefore someone building cloud infrastructure, experimenting with kernel technology in Rust, or looking for an alternative to the assumption that a container host must run Linux.

A quarter of the Linux interfaces, stated plainly

The single most important number in the project documentation is its own: DragonOS has implemented approximately 1/4 of Linux interfaces, with the intention of providing 100% Linux compatibility along with new features in the future. That is an unusually candid framing for an operating system project, and it is the number to hold on to. Compared to other systems of similar scale, the project says DragonOS supports eBPF and virtualization, and it is actively advancing container support, cloud platform compatibility, RISC-V support, and porting compilers and application software. eBPF is the feature that most directly connects the project to the cloud world, since it is how you run sandboxed programs in the kernel for observability and networking. Container support is the one that would decide whether a container image can actually run here. The project also publishes a CI dashboard with Linux compatibility data, which is where a serious evaluation should start rather than with the marketing description, because interface coverage is exactly the kind of thing that is easy to claim and hard to check.

The build needs Nix, and the Makefile checks

The build system is where most people meet the project, and the first thing it does is check whether Nix is installed. The Makefile includes env.mk, exports ROOT_PATH and a VMSTATE_DIR under bin/vmstate, detects whether it is running inside a Nix environment, and has a check_nix target that prints an error and exits if the nix command is missing, along with the installation command:

curl -fsSL https://install.determinate.systems/nix | sh -s -- install

The subdirectories are kernel, user, tools and build-scripts, and the default target builds the kernel and the user space. Two other details in the Makefile are worth knowing before you start. The root filesystem is selected by a manifest name under config/rootfs-manifests, with ROOTFS_MANIFEST defaulting to default, and a prepare_rootfs_manifest target resolves it through tools/rootfs_manifest_resolve.sh, passing the architecture through the ARCH variable. There is a check_arch target that runs tools/check_arch.sh to verify the ARCH setting matches the arch field in the chosen manifest, which is the kind of consistency check that saves time when you are cross-building. A SKIP_GRUB variable can bypass the automatic GRUB installation, and it defaults to 1 in CI. The repository also ships a flake.nix and flake.lock, a .devcontainer directory and a .envrc, so a Nix-aware environment is the intended path.

Try it in the cloud before building anything

The project gives you a way in that does not require any local toolchain, and it recommends it. Method 1 is cloud-native development on the CNB platform, described as zero configuration and one-click launch, with no local dependencies required, and the DragonOS Playground is where you start. The playground runs the latest nightly build, and the community news notes it going live on 2025-12-17 with daily nightly build updates. Method 2 is a local build, and the documentation for that is a separate page on the build system. The distinction between the two release channels matters. There are numbered releases, v0.2.0, v0.3.0 and v0.4.0, the last of which was published on 2025-12-22, and then there are nightly builds that track the branch head, and the last push to the repository was on 2026-10-19. If you want a reproducible system to test against, use a numbered release. If you want to see what the project is doing this week, use the playground nightly.

A community project with an open governance document

DragonOS is run as a community rather than by a single company, and the documentation says the open-source community was established in July 2022 and is entirely commercially neutral. The governance is documented rather than implied. There is a community introduction document, a Community Management Team page with contact details for the people who run the community, and separate SIGs and WGs pages where the contact information for the leaders of the specific groups is listed. The README also points at the issues for participation and at a forum at bbs.dragonos.org.cn for progress and tasks. The licence is GPLv2, and the project asks that violations of the open-source licence be reported to [email protected], which tells you that the PMC is a real body with a defined role. Funding is handled through sponsorship, and the project states that sponsorship funds go to event organisation, cloud service expenses and other purposes that benefit the community, with all sponsors publicly acknowledged and Tencent EdgeOne providing CDN acceleration.

Where DragonOS is the wrong tool today

The honest answer is that it is a research and development platform rather than a hosting target, and the project's own numbers say so. With about a quarter of the Linux interfaces implemented, a workload that touches an unimplemented syscall or an unusual interface fails in a way that is tedious to diagnose, and the compatibility dashboard exists precisely because that surface is uneven rather than uniform. The stated goal is large-scale production deployment within five years, which places it years away from the readiness that a production environment needs. The build system is also a real cost: Nix is a prerequisite, the toolchain has to be assembled, and the configuration of the root filesystem manifest and the architecture check is work that a mainstream distribution handles for you. A second limit is scope of hardware. RISC-V support is listed as being actively advanced, which means the non-x86 path is in progress rather than done. The project also does not document, in the repository, what application software has been ported, so a team with a specific application in mind has to check the compatibility data directly rather than assume.

Editorial conclusion

Adopt DragonOS if you are working on operating system research, need an eBPF-capable kernel in Rust, or want to test container workloads against something other than a mainstream Linux, and if you can accept an interface coverage the project puts at about a quarter of Linux. Do not adopt it as a production host today, because the project's own stated goal is large-scale production deployment within five years, and the compatibility work is still in progress. Before you build, read the compatibility dashboard at ci-dashboard.dragonos.org for the specific syscalls your workload needs, and expect to install Nix first, since the build system checks for it and the Makefile refuses to continue without it.

Frequently asked questions

Official sources

1. DragonOS-Community/DragonOS on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases