The diversity and endless possibilities in the Linux ecosystem are one of its strongest features (or the main obstacle to its widespread adoption) — depending on who you ask. But that’s not today’s focus. Instead, we’re looking at something brand-new that touches one of the most fundamental parts of any system: the boot process.
A new init system called Nitro has reached its first public release, adding another option to the already diverse ecosystem of process supervisors for Linux, currently dominated by systemd. The main driving force behind it is Leah Neukirchen, maintainer of the systemd-free Void Linux, a distro betting on runit as its init system.
She designed Nitro to be tiny, flexible, and easy to configure, focusing on the basics of what an init system should do: bring up services, keep them running, and restart them if they fail. Unlike larger alternatives such as systemd, Nitro sticks to a simple process supervision model while staying small enough to build and run as a static binary.
Its design highlights include:
- RAM-only state – Keeps all state in memory, making it work cleanly on read-only root filesystems.
- Event-driven – Operates without polling, using an efficient event-driven model.
- Deterministic runtime – Zero memory allocations once running, avoiding fragmentation and runtime surprises.
- Safe resource usage – Guarantees no unbounded file descriptor growth during runtime.
- Minimal footprint – Distributed as one self-contained binary, with a single optional helper tool for system control.
- Simple configuration – No build or compile steps required; services are just directories with scripts.
- Robust supervision – Supports automatic, reliable restarting of services on failure.
- Logging flexibility – Offers per-service logging, defaults, and even chains spread across multiple services.
- Clock independence – Works without requiring a properly set system clock.
- Cross-platform – Can also run on FreeBSD via “/etc/ttys,” handling standard file descriptors automatically.
- Tiny static binary – Especially small when built with musl libc.
In practice, Nitro does what all init systems must: sit at PID 1 and make sure the rest of the system comes alive and stays running. Where it differs is in its emphasis on being small, scriptable, and flexible without pulling in extra layers of functionality. Okay, but what really sets it apart from other lightweight init systems, like rinut or s6, for example?
In short, while runit and s6 already cover lightweight init and supervision needs, Nitro carves out its space by focusing on deterministic, polling-free operation with minimal runtime overhead. Where s6 adds modular complexity and runit takes a pragmatic three-stage init design, Nitro aims for an even smaller footprint with reliability baked in.
So, in my view, this new child in the init systems space is not designed to challenge complex giants like systemd in mainstream Linux distros. Instead, it fits into specialized use cases: lightweight containers, embedded systems, and minimal environments where small, deterministic binaries are preferred over large, feature-rich frameworks.
Whether it can build real momentum is something only time will tell, but we’ll definitely be keeping an eye on how this new project takes shape.
Nitro’s first release is now available on GitHub, where you can also find detailed technical information about it.
