Who it's for
People with several machines or outputs whose flake.nix has outgrown a single screen.
Move up when
You want to organise by feature (gaming, desktop, laptop) rather than by machine. That’s the dendritic pattern.
The pour
flake.nix hands over to flake-parts, and each machine becomes its own module:
# flake.nix
{
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";
flake-parts.url = "github:hercules-ci/flake-parts";
};
outputs = inputs@{ flake-parts, ... }:
flake-parts.lib.mkFlake { inherit inputs; } {
systems = [ "x86_64-linux" ];
imports = [ ./hosts/endgame.nix ];
};
}
# hosts/endgame.nix (a flake-parts module)
{ inputs, ... }:
{
flake.nixosConfigurations.endgame = inputs.nixpkgs.lib.nixosSystem {
modules = [ ../configuration.nix ]; # Steam still lives in here
};
}
How it works
flake-parts runs the same module system as NixOS, but one level up: its modules describe the flake’s outputs instead of a machine. That’s why it’s mainly useful once there are several outputs to organise, such as machines, dev shells, packages and checks.
Why people like it
- Your flake is split across files, each one a normal module.
- A large collection of ready-made flake-parts modules for dev shells, formatting, CI checks and more.
- The foundation that the dendritic pattern grew from.
What it costs you
- Another layer between you and the result, and another input to learn.
- Error messages can point into flake-parts itself rather than your file.
- Overkill for one machine.
Regulars brewed this way
An AMD gaming desktop and a Surface Pro tablet from one den config, with every feature written as a reusable aspect.
A polished Hyprland desktop, kept entirely in config.
The personal infrastructure of the person who first wrote up the dendritic pattern, and the reference for what one looks like in practice.
Further reading
- flake.parts - the official docs and module list
Last checked against the projects' own docs: 11 November 2026. These tools move quickly; spotted something out of date? Open a pull request.