fufexan/dotfiles is a personal NixOS flake that happens to export packages

In-house configs, and the author's own description of them

The About section is two sentences and both of them matter. In-house baked configs for Home-Manager and NixOS, borrowed bits sprinkled on top, using flakes and flake-parts.

That is a much more useful description than a dotfiles repository usually gets, because it tells you exactly what to expect. This is not a theme, a template or a general purpose module. It is one person's working configuration, structured in a way that other people can read, with pieces taken from other people's configurations and credited for it.

The credits are concrete. The Resources section lists configurations the author learned from and copied, including colemickens' nixcfg, flake-utils-plus, gytis-ivaskevicius' nixfiles, Mic92's dotfiles, NobbZ's nixos-config, privatevoid-net's infrastructure, RicArch97's nixos-config and viperML's dotfiles. And the People section names the individuals whose work inspired the configuration, from DieracDelta and hlissner through tadeokondrak, viperML, Xe and yusdacra, with the note that there are surely more.

The licence is MIT, and the primary language is Nix, with the repository described as a NixOS system config and Home Manager user config. The last push was on 2026-10-14 and the repository has no GitHub releases, which is the natural consequence of it being a personal configuration rather than a distributed package.

The flake exports packages you can run directly

The unusual thing about this configuration, from a user's point of view, is that it is consumable. The flake exports several packages, and the readme gives two ways to find them and one way to run them.

To see what is exported, you run a flake show command against the GitHub reference.

nix flake show github:fufexan/dotfiles

The About section offers the same command as the way to see an overview of the flake outputs.

To run one, you use nix run with the package name after a hash.

nix run github:fufexan/dotfiles#<packageName>

Running straight from a GitHub reference rather than from a local checkout is the part worth pausing on. It means you are evaluating somebody else's configuration without touching your own setup, and whatever it pulls in lands in the store rather than in your system profile.

That is a much lower risk way to try a dotfiles repository than cloning it and running home-manager switch against your own machine, and it is the reason the exported packages are structured the way they are.

Wiring the packages into another configuration

The documented path for using the packages rather than running them is to add the flake as an input and reference the package from your own system packages list.

# flake.nix
{
  inputs.fufexan-dotfiles = {
    url = "github:fufexan/dotfiles";
    inputs.nixpkgs.follows = "nixpkgs";
  };
}

# configuration.nix
{pkgs, inputs, ...}: {
  environment.systemPackages = [
    inputs.fufexan-dotfiles.packages."x86_64-linux".<packageName>
  ];
}

Two details in that snippet are the whole integration story. The first is the attribute path, packages."x86_64-linux".<packageName>, which tells you the packages are exposed per system, so a configuration built for aarch64 and one for x86_64 resolve different attributes and you have to know which one you are asking for.

The second is inputs.nixpkgs.follows = "nixpkgs", which tells the flake to take nixpkgs from your own configuration rather than pinning its own. Without that line you end up with two nixpkgs in the same evaluation, and the mismatch that follows is a class of bug that is miserable to diagnose.

This is the pattern that makes a personal configuration usable by other people without turning it into a supported distribution, and it is a good pattern to copy even if you never use this repository.

The layout separates hosts, system and home

The Contents section lists six directories and each one has a single clear job.

hosts/ is host-specific configuration, so each machine has its own entry rather than a shared file with conditionals inside it. home/ is the Home Manager config, the part that manages the user environment and the programs inside it. lib/ holds helper functions, the small utilities that the rest of the configuration depends on. modules/ is for exported NixOS modules. pkgs/ holds package definitions, the things this configuration builds that are not in nixpkgs. system/ is the NixOS configuration common between hosts.

That split is the interesting part of the design. The separation between system and home is the standard one for a machine with multiple users or with a system configuration shared between hosts, and the separation between system and hosts keeps the shared part free of machine-specific conditionals.

The repository tree also holds things that are not in the Contents list. There is a flake.nix and a flake.lock, an fmt-hooks.nix file, an .envrc file, a secrets/ directory and a .tack/ directory. The .envrc file is the direnv marker that lets you enter the development environment of a directory, which is what makes the lock file and the tooling available without a global nix profile. The secrets/ directory is the place where the configuration keeps the things it does not commit.

The fact that secrets/ exists as a separate directory says the configuration is aware that it will hold a system that has credentials in it, which is more thought than most personal configurations give to that.

Three generations of desktop shell in one repository

The desktop preview section is unusual in how openly it presents the history of the project.

The current widgets are created using Quickshell. The previous version used Ags v1, and that version lives on its own branch, the ags branch. The version before that used Eww, on the eww branch. Each branch holds a complete configuration, and the readme links to them.

This is worth reading as a maintenance policy rather than as clutter. A desktop shell in a declarative configuration is a large surface that changes when the tool changes, and keeping the old branches means that a reader who finds the current one unfamiliar can look at a working alternative rather than starting from nothing.

The screenshots follow the same structure, with a current preview and a details block for previous versions, including a dark and a light variant of the Ags version and two images of the Eww version.

The topic tags describe the shape of the setup: ags, declarative, dotfiles, flake, helix, home-manager, hyprland, nix, nixos and wayland. So the desktop is a Hyprland session on Wayland, the editor is Helix, and the shell and its widgets are Quickshell. That is a coherent modern Linux desktop, and the fact that the whole thing is described declaratively means the environment can be rebuilt from the flake rather than from a list of things someone installed years ago.

flake-parts and the tooling around the flake

The About section names the two build tools that shape the configuration: flakes and flake-parts.

Flakes are the packaging and evaluation format Nix uses to describe an input tree with pinned dependencies, and the flake.lock file in the repository is the record of exactly which revision of every input is used. That is the mechanism behind the reproducibility claim of any Nix configuration, and it is why the README can tell you to run nix flake show against a GitHub reference and get a deterministic result rather than whatever is on the branch today.

flake-parts is a framework for composing flakes from parts rather than writing one large expression. The point of it is that each part is a self-contained piece of the configuration with its own inputs and its own outputs, which scales better than a single file that grows without bound.

The supporting files show the same attention. fmt-hooks.nix is a set of formatting hooks, so formatting is checked by a hook rather than by a command you have to remember to run by hand. The.envrc file is the direnv entry, and.tack/ is a directory whose purpose the readme does not describe.

The pkgs/ directory is the other piece of the structure worth noting, because a pkgs/ directory is where a configuration stops being a dotfiles repository and starts producing software. Packages defined there can be exposed through the flake outputs, which is exactly what the exported packages section describes.

What you actually get if you clone this

It is worth being concrete about the value, because a personal configuration is easy to overrate.

What you get is a working example of a flake structured for a real multi-host machine, with the system and home split done properly, packages exposed so that other people can consume them without adopting the whole configuration, and a documented way to run a package straight from GitHub. The credits section tells you where to look for the other ideas, and the People list is effectively an index of configurations to read next.

What you do not get is a supported distribution. There are no releases, so there is no version to pin, and the configuration is in-house, so the author is not obliged to keep it working for you. The flake-parts structure and the borrowed helpers mean that reading it means reading a mixture of code written here and code adapted from elsewhere, which is a fair trade for a working system and a poor trade if you want something you can trust without reading it.

For a Nix user, the pragmatic approach is to treat it as a reference rather than a base. Copy the directory structure and the integration pattern, take the pieces that solve a problem you have, and leave the rest. The README's own framing, in-house baked configs with borrowed bits sprinkled on top, is an invitation to do exactly that.

Editorial conclusion

Adopt fufexan/dotfiles when you want a working example of a flake structured for personal use with a clear separation between hosts, system and home, and when you are prepared to read the Nix rather than expect a template. Do not adopt it as a maintained distribution, because it is explicitly in-house configuration and the repository has no GitHub releases. Verify first that the exported package you want exists for your system, since the package list is per system, such as x86_64-linux, and that the secrets/ directory and the .envrc and fmt-hooks.nix files are handled the way your own setup expects before you copy them.

Frequently asked questions

Official sources

1. fufexan/dotfiles on GitHub
2. Issues
3. License: MIT
4. README