Dentritic
Updated: August 4, 2026
Flips the script on using Nix.
Instead of host focus first in flake.nix a dendtritic pattern focus first on aspects/features.
It moves modules to toplevel. It can have more or less framework. You make the decision.
Table of Contents
What is Dentritic?
Can be community focused, sharable and layerable. (pull other dentritic repos into yours, vice versa)
Dendritic is a configuration pattern - a way-of-doing-, not a library nor a framework.
It is using flake-parts to create dendtritic modules. These are standalone in a way.
.nix files are no longer darwin || nixos || home-manager configurations, or a package.
They are instead only flake-parts modules!!
There are no specialArgs or extraSpecialArgs either!
Instead of using specialArgs or extraSpecialArgs, modules utilize toplevel or a let binding. toplevel looks something like this:self.nixosConfigurations.${hostname};
flake parts provides flake.modules.
.
being a type of configuration, like nixos, darwin, homeManager, nixvim, etc. is a feature that is configured for one or more of these classes.
vic/import-tree is commonly used. Imports all flake-parts modules that are in the modules directory.
This means we no longer need to import files manually.
Why use Dentritic?
Natively cross-platform.
Easier to discover bug && fix. We can test a specific feature instead of an entire flake.
Feature Centric instead of Host Centric Logic moved from flake.nix into composable configurations with simplicity by stating features.
Can be used for many systems and purposes without becoming a complex monolith.
No restrictions on how nix files are organized or named.
Can define your own options at the flake-parts level. Sharable values across
Everything related to a feature is included in the same nix file || directory. (bye bye sprawl)
Each feature can be handled in its own design pattern as needed, providing massive flexibility:
- Simple Aspect: Direct, one-to-one configuration mapping
- Multi Context Aspect: Same feature, different behaviors per host/user/environment
- Inheritance Aspect: Hierarchical configuration with clean overrides
- Conditional Aspect: Toggle features based on predicates
- Collector Aspect: Aggregate configurations from multiple sources
- Constants Aspect: Centralized, type-safe configuration values
- DRY Aspect: Eliminate repetition without obfuscation
- Factory Aspect: Generate configurations programmatically