# nix-config runs NixOS, macOS and plain Linux from one dendritic flake

> MatthiasBenaets/nix-config is a personal multi-platform Nix flake that wires NixOS, nix-darwin and standalone Home Manager through flake-parts and import-tree. It reads well as a reference, but its host names, secret setup and missing release history make it a poor template to copy wholesale.

**MatthiasBenaets/nix-config** — My Personal Nix, NixOS and Nix-Darwin System Configuration Flake

- Repository: https://github.com/MatthiasBenaets/nix-config
- Website: https://www.youtube.com/watch?v=AGVXJ-TIv3Y
- Stars: 743 · Forks: 65
- Language: Nix
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/matthiasbenaets-nix-config

## flake-parts and import-tree do the wiring instead of flake.nix

The configuration covers three different system types at once: NixOS on Linux hosts, nix-darwin on macOS machines, and standalone Home Manager for a Linux host that does not run NixOS. Two libraries carry the structure. flake-parts provides the entry point, and import-tree walks the modules directory and loads everything it finds there automatically. Modules follow the dendritic pattern, so each small module carries its own options instead of being threaded through a central list. The visible consequence is that modules are grouped by feature rather than by target operating system, and every host composes only what it needs. The top level of the repository is short: flake.nix, flake.lock, a modules directory, a shells directory, a Makefile, .sops.yaml, secrets.yaml and a .gitignore. There is no per-host copy of the feature wiring, and no monolithic configuration file to read before understanding the setup.

## Adding a host means creating a directory, not editing flake.nix

The dendritic layout and import-tree combine so that a new machine is a new folder rather than a new edit to the flake entry point. The documented procedure puts a NixOS host under modules/hosts/nixos/ and gives that directory a default.nix. Inside, the file defines the nixosConfiguration for the machine, picks a system string such as x86_64-linux, and assigns a state version. The same file can also register host specific modules and attach Home Manager modules for the host user, so a single new file covers the system layer and the user layer for that machine. The documentation states that the main flake.nix does not need to be modified to register the host, because import-tree picks up the new directory on its own. Once the file exists, the machine is built and activated with the same command used for the existing hosts:

```bash
sudo nixos-rebuild switch --flake .#beelink
```

The cost of that convenience is that discovery happens at evaluation time, so a typo inside the new file surfaces as an evaluation error rather than as a missing entry in a list.

## The host tables describe a personal machine list, not a fleet

Reading the host tables tells you exactly how personal this configuration is. On NixOS there are three entries: beelink, a desktop with Hyprland, the Noctalia shell and Kitty; work, a laptop with the same stack; and vm, which has no window manager and no shell listed. On nix-darwin there are three more: intel, a MacBook on x86_64-darwin with no window manager, m1 and work, both on aarch64-darwin with AeroSpace and Zsh. Standalone Home Manager covers a single host named pacman for any Linux distribution with Nix installed. Two details matter to anyone reading this as a template. The label work appears under both NixOS and nix-darwin, so flake outputs are namespaced by platform rather than by machine name. And the names themselves are personal, so adopting the flake means renaming every host and rewriting the module selections that go with each one.

## The first macOS rebuild starts from a machine with no darwin-rebuild on PATH

The macOS path is the one with the longest bootstrap, and the ordering matters. Nix has to be installed first, which the documentation gives as the standard installer command:

```bash
sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install)
```

Flakes are then enabled by writing the experimental feature line into the user nix.conf, because none of the commands below work without it:

```bash
mkdir -p ~/.config/nix
echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf
```

The first build is deliberately run from the built result rather than from PATH, since darwin-rebuild is not yet available on a fresh machine:

```bash
nix build .#darwinConfigurations.<host>.system
./result/sw/bin/darwin-rebuild switch --flake ~/.setup#<host>
```

After that first pass, the command collapses to a single invocation against the flake URL:

```bash
darwin-rebuild switch --flake ~/.setup#<host>
```

Two commands are part of the same flow and are easy to overlook: installing git from nixpkgs, and cloning the repository into ~/.setup, since both the clone and the flake URL later point at that path.

## Standalone Home Manager needs a GPU service on a generic Linux distribution

The pacman host path assumes a Linux distribution that is not NixOS, which brings extra steps that do not exist for the NixOS hosts. Home Manager is added as a channel from the nix-community archive, updated, and then installed with nix-shell against the home-manager expression:

```bash
nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
nix-channel --update
nix-shell '<home-manager>' -A install
```

The rebuild passes the flake flags directly because the standalone install is not always wired to experimental features:

```bash
home-manager switch --extra-experimental-features 'nix-command flakes' --flake ~/.setup#<host>
```

The documentation also states that NixGL is no longer required on a generic Linux host, but a first rebuild may still need the GPU linked through a service, and the path to that helper is a store path with a placeholder hash that has to be filled in from a real build:

```bash
sudo /nix/store/<sha>-non-nixos-gpu/bin/non-nixos-gpu-setup
```

The same section recommends Flatpak, and the accompanying sysctl changes relax two kernel restrictions. None of this is automatic for the person who clones the repository, which is the main practical cost of using the standalone Home Manager target.

## Secrets sit at the repository root without a documented decryption path

Two files at the top level of the repository carry the secret story: .sops.yaml and secrets.yaml. Their presence tells you the configuration is intended to hold encrypted values that a build can read, and the configuration of .sops.yaml is what binds those values to recipients. What is missing is the explanation. The README does not document how secrets.yaml is encrypted, which key or key management tool the recipient list expects, or how a rebuild obtains the decryption key when it runs. That gap matters more than usual here, because this is a configuration meant to be applied on several machines, and each machine, including the first one, needs access to the same secrets before a switch can succeed. Anyone adopting this repository has to supply that part themselves, and has to be comfortable putting secrets in a flake that will be switched with root privileges.

## The Makefile is the real command surface

A Makefile sits at the repository root and wraps the Nix commands in platform groups. The visible targets cover help, list and show for discovery, nixos, nixos-build and nixos-eval for Linux hosts, the matching darwin, darwin-build and darwin-eval trio for macOS, and home, home-build and home-eval for standalone Home Manager. Dev shells and packages get their own group with shell, develop and run, and maintenance has gc, gc-sudo, optimise, clean and update. The help target is built by grepping the Makefile for its own annotation comments and printing them with grouped headings, using ANSI colour codes and a box drawing frame. The result is that the everyday commands live in one file that regenerates its own help, while the README keeps the longer explanations. One trap: the help output and the group comments use typographic dashes in their decorations, so copying fragments of the rendered output into scripts is a poor idea.

## No releases, no licence, and a last push on 2026-09-23

The maintenance picture is thin. The repository is not archived and its last push was on 2026-09-23, so the work is recent rather than abandoned, but there are no GitHub releases, no version tags to pin against, and no licence file among the top level entries. A personal configuration with no releases means there is no upgrade path beyond pulling the default branch and re-running a switch, and any change can land without a note explaining what broke. The README also points to a separate vanilla branch for a plainer flake setup, which tells you the dendritic version is the opinionated one. The homepage is a video rather than a documentation site. None of this disqualifies the project, but it does place the burden on the reader: there is no changelog to consult, no issue tracker policy to rely on, and no rollback procedure described anywhere in the documentation.

## Conclusion

Adopt the structure only if you are willing to rewrite the host layer, since the machine names, module selections and SOPS secret setup are all personal. Do not expect a supported product: the repository has no GitHub releases, states no licence, and its last push was on 2026-09-23. Before using it, verify the licence terms yourself, decide how secrets.yaml will be encrypted and decrypted on your machines, and confirm that the vanilla branch covers the parts of the setup you actually want to keep.

## FAQ

### How do I add a new NixOS host to MatthiasBenaets/nix-config?

Create a directory under modules/hosts/nixos/, add a default.nix that defines the nixosConfiguration for the machine and registers its host modules, then run the rebuild for that host. The documentation states that flake.nix does not need to be edited, because import-tree loads the modules directory automatically.

### Can MatthiasBenaets/nix-config be used on macOS?

Yes. The flake defines nix-darwin configurations for three hosts, and the documented switch command is darwin-rebuild switch --flake ~/.setup#<host>. On a fresh machine the first build is run through the built result because darwin-rebuild is not yet on PATH.

### How are secrets handled in MatthiasBenaets/nix-config?

The repository root contains .sops.yaml and secrets.yaml, so encrypted values are meant to be read during a build. The README does not document how secrets.yaml is encrypted or how the decryption key reaches a machine during a switch, so that part has to be worked out before adopting the configuration.

### What is the vanilla branch used for?

The documentation points to a vanilla branch for a more conventional Nix flake setup, as an alternative to the dendritic module structure used on the default branch. The configuration described in the article, with flake-parts and import-tree, is the default branch.

### Which dev shells and packages does MatthiasBenaets/nix-config provide?

The shells directory provides a default shell with vim and git, and a neovim shell with a configured Neovim plus git, both reachable through nix develop. The flake also exposes a standalone neovim package built through nixvim, runnable with nix run .#neovim.

## Sources

- [Issues](https://github.com/MatthiasBenaets/nix-config/issues)
- [MatthiasBenaets/nix-config on GitHub](https://github.com/MatthiasBenaets/nix-config)
- [Project website](https://www.youtube.com/watch?v=AGVXJ-TIv3Y)
- [README](https://github.com/MatthiasBenaets/nix-config/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/matthiasbenaets-nix-config