finix: a NixOS-shaped experimental OS with finit as pid 1

An OS built to argue with NixOS, not to replace it

finix is described in one line as a daily-drivable experimental OS, featuring finit as pid 1, to explore the NixOS design space. The phrase to hold onto is explore the NixOS design space, because that is the stated purpose, and the readme then lists the specific questions the author wanted answered.

The list is not a feature list. It is a set of open problems in NixOS itself: the evaluation speed regression tracked in nixpkgs, the fact that NixOS always imports all modules, modular services, decoupling services using structured typing, NixNG, sixos which is a Nix OS without systemd, and nixbsd. Each entry links to the issue, the pull request or the discussion where the question lives.

What makes finix a response to those questions rather than a commentary on them is that the system is actually run. The readme says that now that finix is running on the author's laptop there is a working base for experimentation, and more to come.

The current configuration is the one piece of concrete information that tells you what the project has actually committed to. It runs with finit instead of systemd as the init system, with seatd instead of elogind as the seat manager, and with mdevd instead of eudev as the device manager, and it uses niri as the Wayland compositor.

That substitution list is the interesting design statement. All four are replacements for systemd-adjacent components, and the theme is that a NixOS-style system does not need systemd to be a usable desktop. The primary language is Nix, the licence is MIT, the default branch is main, the last push was on 2026-10-21, and there are no GitHub releases.

The repository layout is that of a Nix flake project rather than a conventional source tree: a flake.nix, default.nix, shell.nix, lon.nix with a lon.lock, a cachix.nix, and directories for modules, overlays, pkgs, docs, tests and assets. There is also an IDEAS.md at the top level, and a statix.toml, which is the configuration for the Nix static analysis linter.

finit as pid 1, and what a service definition looks like in Nix

finit is the init system, and the readme gives an example of defining a finit service in Nix, which is where the difference from a systemd NixOS becomes visible.

{ config, pkgs, lib, ... }:
{
  finit.services.network-manager = {
    description = "network manager service";
    runlevel = "2345";
    conditions = "service/syslogd/ready";
    command = "${pkgs.networkmanager}/bin/NetworkManager -n";
  };
}

The shape is a NixOS module, which is the part that has not changed. The function head takes config, pkgs and lib, and the option path is finit.services.network-manager with a set of attributes under it.

What has changed is what the attributes mean. There is a description string, a runlevel given as a string of digits, a condition expressed as a path, service/syslogd/ready, and a command built from the package set. The runlevel and the condition are the finit concepts: a service declares which runlevels it belongs to, and declares what has to be ready before it starts. In a systemd module the equivalent information would be expressed as unit types, ordering dependencies and a wanted-by target, and the mapping between the two systems is precisely the work a port like this involves.

That comparison is the heart of the project. A systemd unit encodes dependency and ordering relationships in the unit file syntax, and the NixOS systemd modules translate those into a generated unit. With finit, the dependency information is expressed directly in the Nix option set, so the declarative layer and the init system share one vocabulary instead of needing a translation layer.

The finit project itself lives at finit-project.github.io, and the readme links it as a separate thing, which is the right relationship: finix configures finit, it does not reimplement it.

No disk image yet, so installation starts from a NixOS ISO

The getting started section is where the project is most candid about its state.

finix does not yet have a disk image available to download. Installation has to take place from a standard NixOS image, which can be downloaded from the NixOS download page, and you may burn either the minimal image or the graphical image, with the steps remaining the same in both cases.

That means there is no one-click path. The user boots a standard NixOS installer, and the finix configuration replaces the init system, the seat manager and the device manager on the running system. The installation guide is on the project's documentation site at the Installation page, and the readme credits @xZecora for writing the referenced examples, which live in a separate finix-community/examples repository.

The documentation site is also where the option search lives, at the finix options search page, which lists the available configuration options. For a system where the configuration surface is the product, a searchable option index is one of the more useful pieces of documentation, and it is linked from the See also section alongside the finit project site and two community repositories: finix profiles and finix community modules.

The presence of both a profiles repository and a community modules repository tells you something about how the project expects to grow. The profiles are curated configurations, and the community modules are the pieces that do not belong in the core tree. This is the same split NixOS itself has between nixpkgs and the modules that consume it.

The readme also lists the environments finix initially ran in, which is a useful signal about how the system was developed. It ran in an incus container, in an nspawn container, on virtualbox, and with x11. The author notes that none of those methods have been attempted in some time, because the project moved to real hardware and a Wayland compositor.

The cachix binary cache, and what it saves you

Building a Nix system means building a lot of packages, and a binary cache turns that into downloads. finix publishes one, and the readme is direct about the arrangement: a binary cache is generously provided by the cachix free tier offering.

Configuring it is a nix-daemon settings block.

Two settings, and both are security-relevant rather than cosmetic. The substituters list adds the cache as a source of prebuilt binaries, so Nix fetches a compiled artifact instead of compiling the source on your machine. The trusted-public-keys list adds the cache's signing key, which is what tells Nix that the binaries it is about to download were signed by someone it has been told to trust.

Trusting a binary cache means trusting the person who runs it, because a compromised cache can serve a modified binary that Nix will verify as correctly signed. That is why the public key is spelled out in the readme and why the two lines travel together: adding a substituter without adding its key gives you no usable binary cache, while adding the key is the explicit act of trusting the cache operator.

The cachix.nix file at the top level of the repository is the cache's own configuration, so the repository holds both ends of the arrangement.

For a project that asks users to install from an ISO and build a custom operating system, a working binary cache is what makes the difference between an afternoon and an evening, and it is the piece of infrastructure that a small experimental OS project cannot easily do without external help.

What finix is for, and where a normal NixOS still wins

Two limitations are visible and one is structural.

The first is the obvious one, that there is no disk image and no supported installation path of its own, so the friction of getting onto the system is measured in reading a documentation page rather than downloading a file. For an experimental system whose author calls it experimental and describes it as running on the author's primary laptop, that is the intended audience rather than a defect, but it does mean the project has no way to reach users who will not read a configuration guide.

The second is the seat and device layer. The substitution of seatd for elogind and mdevd for eudev is exactly where a from-scratch desktop breaks: session management, device access permissions, the login screen, and hotplug all have to work before the compositor is usable. A project that has replaced three such layers has replaced the parts that touch the kernel most directly, and the ones that fail tend to fail in ways that are hard to diagnose from a configuration file.

The structural limitation is the scope of the question. finix explores whether the NixOS design space can be occupied without systemd. It is not trying to be a smaller or faster NixOS, and it is not trying to compete on the packaging breadth that nixpkgs provides. Every one of those seven linked topics is a question about NixOS itself, and finix is the vehicle for answering them.

Against a normal NixOS, the difference in approach is therefore philosophical rather than technical in the usual sense. A standard NixOS gets its configuration model from Nix and its service supervision from systemd, and the two are bridged by generated unit files. finix keeps the configuration model and replaces the supervisor, so the question is whether the same declarative layer can be expressed directly in an init system that was not built for it.

The NixNG, sixos and nixbsd projects named in the readme are attempts at the same question from other directions, and the fact that finix links all of them rather than competing with them is a good sign about how the project sees itself: one more experiment in a space several people are exploring.

For a user who wants a working Nix-based desktop today, nixpkgs and a standard NixOS image remain the answer. For a developer who wants to find out what happens when systemd is removed from the equation, finix is a working example rather than a paper.

Editorial conclusion

finix fits a developer who already knows Nix and wants to explore whether a NixOS without systemd can be driven as a primary desktop, and it does not fit a user looking for a supported general-purpose system or a ready-made image, since installation starts from a NixOS ISO and the documentation site carries the procedure. Before installing, read the Installation page on the documentation site, and plan for the fact that the project describes itself as an experiment running on the author's primary laptop rather than a distribution with support commitments.

Frequently asked questions

Official sources

1. finix-community/finix on GitHub
2. Issues
3. License: MIT
4. README