A Nix flake where every host imports every module and the module decides

Every module is imported everywhere, and gates itself

The architecture is the interesting part of this configuration, and the README says so directly. Most NixOS configurations use selective imports, where each host cherry-picks which modules to include. This flake does the opposite. Every module is imported by every host, and each module decides internally whether to activate based on typed host metadata. The author calls this the broadcast-and-gate pattern, and the stated benefit is that there are no import lists to maintain and no per-host module selections. You drop a self-gating module into a directory and every relevant host picks it up automatically. The cost is equally clear and worth naming: the person reading the configuration has to open a module to find out which machines it applies to, rather than reading a list that says so at a glance.

A module that evaluates to nothing when its condition is false

The mechanism for gating is lib.mkIf, driven by metadata from the noughty module system. The README's example is a module that activates itself on workstations, so servers and virtual machines ignore it. It sets boot.plymouth.enable to true, and the surrounding module header takes the standard config, lib and ellipsis arguments. The important property is that a module whose condition is false evaluates to nothing, with zero cost and zero side effects, and the README notes that the Nix module system handles this natively. That last point matters: this is not a new evaluation model bolted on top of Nix, it is a use of the existing one. The conditions can be as specific as needed, covering workstation versus server, laptop versus desktop, GPU vendor, display layout, user identity and freeform tags, and they can be combined, so a module that applies only to a named person's workstations with an NVIDIA GPU is a single line.

noughty turns a systems registry into typed NixOS options

The metadata layer is what makes the gating style work, and it is a project within the repository. Every host is registered in a system registry file, lib/registry-systems.toml, which is read by flake.nix, with each host's properties recorded: what kind of system it is, its platform, form factor, GPU vendors, displays and freeform tags. The noughty module system then turns that registry into typed, overridable NixOS options under config.noughty, with derived booleans like host.is.workstation, host.is.laptop and host.gpu.hasNvidia computed automatically. The registry file is a data file rather than a list of Nix expressions, which means a host's identity can be edited in one place, and the derived options are computed once rather than repeated as conditionals in every module.

One flake covering NixOS, nix-darwin and Home Manager

The scope is a single Nix flake managing NixOS, macOS and Home Manager across all the author's systems from one repository, and the directory structure shows how that is laid out: a common directory, separate darwin, nixos and home-manager directories, a modules directory, overlays, pkgs, lib, secrets, plus flake.nix and flake.lock at the root. The Home Manager side has a _mixins directory holding the universally imported modules, including an agentic subdirectory with an assistants tree. The repository also carries a .sops.yaml and a secrets directory, and the topics list includes sops-nix, so secrets are handled with SOPS rather than committed in the clear. There is a justfile, a .envrc for direnv, a flakehub reference, and a nix-flake-checker setup, so the configuration is checked as a flake rather than only as a set of files.

A justfile that generates and then verifies the assistant catalogue

The justfile shows the repository's working habits, and it is the closest thing to a command reference here.

default:
    @just --list --unsorted

Recipes are declared with a shell shebang and a set of strict flags, and they lean on nix eval to read values out of the flake. The update-assistant-catalogue recipe evaluates lib.assistantCatalogue commandsMarkdown, agentsMarkdown and skillsMarkdown and writes the results into the tracked README files under the assistants directory, and the check-assistant-catalogue recipe builds a check target from the current system to verify the tracked catalogue still matches its sources. The logic is inverted from the usual generate-then-hope-for-the-best pattern: there is a check that can fail in CI, which means the generated documentation cannot silently drift from the code. The export-agentic-dots recipe builds a review tree of public assistant resources and records the source revision, appending a dirty marker when the working tree is not clean.

A dotfiles repository that is really a working environment

The README includes a table of the machines under management, with hostname, board, CPU, RAM, primary and secondary GPU, role, operating system and state, and the hostnames follow a Star Wars naming scheme with workstations and servers named after Sith Lords and the virtual machines after TIE fighter series. The list spans Framework desktops and laptops, ThinkPads, a Mac Mini M2 Pro, a Steam Deck, QEMU and Lima virtual machines, and servers including one with a Threadripper 3970X and an RTX 3090. A couple of entries are marked as under construction, and one is a dual boot system where the NixOS install takes the Sith Lord name and the other operating system takes the public-facing persona. The point of including all of it is scale. A configuration that handles twenty machines, several operating systems, laptops and desktops, workstations, servers and virtual machines is a better demonstration of whether the broadcast-and-gate model scales than a two-host example would be.

BlueOak licensed, dated releases, and honest advice for newcomers

The licence is BlueOak-1.0.0, which is a permissive licence with a stated goal of reducing friction around use. The project is not archived and the last push was on 2026-10-19, with a release tagged v26.5.20261010 on 2026-10-13, so the versioning follows a date-based scheme that changes often. The README also does something most dotfiles repositories do not: it tells you not to use this as your starting point. For someone setting up their own Nix configuration it recommends a different repository, nix-starter-configs, as a foundation, and describes this one as the deep end. That is useful framing, because the self-gating pattern and the noughty module system are unusual enough that copying the code without the mental model would be painful.

Editorial conclusion

Wimpy's nix-config is worth reading for anyone who wants to see a large Nix configuration with many machines under one repository, and the noughty module system is the part worth borrowing. It is not a starting point for a first Nix setup, since the README itself points new users at a different repository for that, and it is a personal configuration with the author's own conventions. Verify first that you can live with the self-gating model, because it inverts the selective-import style most Nix configurations use, and read the justfile recipes before you start editing modules, since the assistant catalogue is generated and checked by nix build rather than edited by hand.

Frequently asked questions

Official sources

1. Issues
2. License: BlueOak-1.0.0
3. README
4. Releases
5. wimpysworld/nix-config on GitHub