# dxflake: a NixOS config that discovers every module and gates it behind flags > dxflake is a personal NixOS flake from dxcently that auto-discovers every module under modules/ and lets each host enable features with dx.* flags. The design is a deliberate half-step toward the dendritic pattern, and it is honest about what it does not do. **dxcently/dxflake** — my private nixos configurations, always will be a WIP - Repository: https://github.com/dxcently/dxflake - Stars: 29 · Forks: 1 - Language: Nix - License: GPL-3.0 - Published: 2026-08-21 · Updated: 2026-08-21 · Language: en - Canonical page: https://hysenlabs.com/projects/dxcently-dxflake ## What dxflake actually solves dxflake solves the maintenance problem of NixOS configurations that grow a long list of imports. The README describes a machine as no longer a long confession, just a handful of wishes. The core idea: instead of editing import lists in every host file, flake.nix discovers every .nix file under modules/ automatically and feeds it to every NixOS configuration. Optional features are not imported selectively; they are imported everywhere but disabled by default, waiting for a flag. The target user is a single NixOS user with multiple machines who is tired of hostname conditionals and import bookkeeping. The repository names three hosts: chiyo, a laptop with Intel iGPU; osaka, a workstation with AMD GPU; and sakaki, a headless server. This is a personal configuration, not a framework for general audiences, and the README says it will always be a work in progress. ## The mechanism: discovery plus gating Two moving parts carry the whole design. Discovery: flake.nix uses lib.filesystem.listFilesRecursive from nixpkgs to enumerate every .nix under modules/, minus any path that contains an underscore. So a file named foo.nix is imported into every host; renaming it to _foo.nix hides it from discovery without deleting it. Gating: because import no longer means active, each optional module wraps its config in lib.mkIf on a flag that defaults to off. A host turns on a feature by setting dx..enable = true, not by importing the file. The README gives the example of a dendrite, a single module like bluetooth.nix or git.nix, that carries both system config and home-manager config behind the same flag. The home-manager part works because home-manager.users.${username} is a NixOS option, not because of a multi-output module system. ## The nucleus, dendrites, and aggregations Modules are split by scope, not by host. The nucleus is a directory, modules/nucleus/, that contains the floor every host gets unconditionally: system.nix, networking.nix, user.nix, security.nix, boot.nix, packages.nix, openssh.nix, sops.nix, tailscale.nix, and more. It declares no toggle, so it always applies. Dendrites are single-idea modules that sleep until a flag wakes them. Aggregations are role flags, not folders. modules/aggregations.nix declares dx.aggregations.{desktop,hyprland,gaming,server}; each dendrite that belongs to a role gates itself on that role with lib.mkIf config.dx.aggregations.desktop. A host file then is just imports = [ ./hardware.nix ] plus a short set of dx.* flags. The README gives sakaki as a host that wishes only server, and osaka as one that wishes desktop, hyprland, gaming, and server. This structure means you can read a host file and know the machine's purpose without tracing imports. ## How it differs from the pure dendritic pattern The README does something rare: it names a reference pattern and explains exactly where this flake diverges. The pure dendritic pattern, from mightyiam/dendritic, uses flake-parts as its foundation and import-tree for discovery. A single file in that pattern registers into every flake output: nixosConfigurations, homeManager, perSystem packages, devShells. dxflake takes only the first pillar, auto-enumeration of the tree, and does it with listFilesRecursive, which ships in nixpkgs, so there is no new dependency. It stops short of pillar 2, which is flake-parts and multi-output registration. The README's table makes the split clear: foundation is nixpkgs.lib.nixosSystem instead of flake-parts; discovery is listFilesRecursive instead of import-tree; scoping is option flags instead of options or selection; and system plus home is carried in one dendrite via home-manager.users.${username}. The author's judgement is that the flake-parts paradigm change only pays off across outputs a single-target NixOS config does not ship. That is a defensible trade-off, but it means this flake cannot register a devShell or a package from the same module tree without extra work. ## Getting it running: what the README supports The README's install section is truncated in the material, so the exact commands are not fully visible. What is confirmed: this requires NixOS, and the flake is invoked through the standard nixos-rebuild switch --flake .# pattern, because each host is a nixosConfiguration. The host files import ./hardware.nix and then set dx.* flags. To enable a feature, you edit the host file to add, for example, dx.aggregations.desktop = true, or dx.bluetooth.enable = true, depending on the module. To disable a module entirely without deleting it, rename it with a leading underscore, such as foo.nix to _foo.nix. The README gives no command for initial setup, no hardware-configuration.nix generation step, and no mention of sops-nix setup beyond listing sops.nix in the nucleus. Anyone adopting this would need to read the actual host files and adapt the hardware imports to their own machines. The lack of a full install walkthrough is a real gap for a newcomer. ## Genuine limitations and failure modes The most obvious limitation is that auto-discovery imports every .nix under modules/ into every host. That includes modules whose dependencies are not present on a given machine. The gating via lib.mkIf prevents the config from activating, but the import still evaluates the file. If a module references a package or option that does not exist in the host's nixpkgs revision, evaluation can fail even when the flag is off. The README does not address this failure mode. Another limitation: the pattern only feeds nixosConfigurations. You cannot use a dendrite to define a devShell or a package in the same flake output, because the foundation is nixosSystem, not flake-parts. The README acknowledges this by saying it stops one pillar short. Also, the repository is explicitly a private WIP, with no releases and no homepage. There is no promise of stability, no changelog, and no issue tracker mentioned. For a production multi-user setup, that is a risk. For a single user's personal machines, it is acceptable. ## A real alternative: the pure dendritic pattern with flake-parts The direct alternative is the pure dendritic pattern that dxflake references. That pattern uses flake-parts as the foundation and import-tree for discovery. The key difference is that a single file in that pattern registers into multiple flake outputs at once: nixosConfigurations, homeManager, perSystem packages, and devShells. So if you need a module that defines both a NixOS service and a matching devShell or package, the pure pattern handles it in one file. dxflake cannot do that without adding flake-parts and changing the paradigm. The trade-off is that flake-parts is an additional dependency and a conceptual shift from plain nixosSystem. The README's own comparison table makes this concrete. If your needs are limited to NixOS configurations, dxflake's simpler foundation is fine. If you want your modules to reach beyond NixOS, the pure pattern is the more complete answer. ## Maintenance cost and license implications Maintenance cost is low in one sense: you never maintain import lists, because discovery is automatic. But you do maintain flags. Every optional module must define its own dx.* option and wrap its config in lib.mkIf. That is boilerplate, and the README does not show a helper to generate it. The nucleus is unconditional, so any change there affects all three hosts; there is no flag to soften that. The README says the flake is always a WIP, which is a signal that changes can land anytime. The license is GPL-3.0. That means if you distribute a modified version, you must share the source under the same license. For a personal config that you never distribute, it has no practical effect. If you plan to publish your own flake based on dxflake, you must comply with GPL-3.0 terms. The README does not mention a contribution guide or a code of conduct, and there are no releases, so the upgrade path is simply following the main branch. ## Conclusion Adopt dxflake if you run NixOS on a few machines, want to drop import lists entirely, and are comfortable with a personal, single-maintainer config that is explicitly a work in progress. Skip it if you need multi-output registration (packages, devShells, perSystem) or if you want a battle-tested community pattern; the README itself says it stops one pillar short of the pure dendritic approach. Before using it, verify that the GPL-3.0 license fits your distribution plans and that the auto-discovery of every .nix under modules/ does not pull in files you meant to keep inactive. The concrete next step is to clone the repo, read hosts/chiyo/hardware.nix, and run nixos-rebuild switch --flake .#chiyo on matching hardware. ## FAQ ### Can you explain what Nix flakes are and how they work? In this repository a flake is the entry point for a private NixOS configuration. flake.nix holds the inputs and one line per host, flake.lock pins them, and lib/composition.nix does the real work by gating and selecting modules before any module graph exists. ### What is flake slang drug? The repository does not discuss that term. dxflake is a NixOS configuration whose flake.nix carries inputs and one line per host, with a catalogue at modules/default.nix naming each capability by hand. ### Is flake a good fish to eat? No fishing content appears here. The project is software: a Nix configuration built around four hosts, one shared user account, and a two pass gate and select composition step that never reads an unselected file. ## Sources - [Official README](https://github.com/dxcently/dxflake#readme) - [Project repository](https://github.com/dxcently/dxflake) - [README](https://github.com/dxcently/dxflake/blob/main/README.md) - [Releases](https://github.com/dxcently/dxflake/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dxcently-dxflake