# A NixOS and Hyprland flake set up as a daily driver > linux-nixos-hyprland-config-dotfiles is a personal NixOS flake with Hyprland, the Catppuccin Macchiato theme and a long list of desktop components, plus Podman, Tailscale and a hardening layer. The author says plainly that it is not minimal and that the unstable channel trades stability for current software. **XNM1/linux-nixos-hyprland-config-dotfiles** — Linux 🐧 configuration based on NixOS ❄️, Hyprland, and Catppuccin Macchiato theme 😸 for a consistent, complete, and customizable experience. 🚀 - Repository: https://github.com/XNM1/linux-nixos-hyprland-config-dotfiles - Stars: 950 · Forks: 54 - Language: Shell - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/xnm1-linux-nixos-hyprland-config-dotfiles ## The README warns you off before it sells you in The About section describes the repository as the author's NixOS flake configuration featuring the Hyprland window manager and the Catppuccin Macchiato theme, used as a daily driver for work and programming, primarily in Rust. The invitation at the end is unusually open: use it in its entirety or borrow specific components. Then there is the note, and it is the most useful paragraph in the document. The configuration is not minimalistic or lightweight and may require disk space and knowledge to understand, and if you are looking for something simpler it may not be suitable for you. That honesty is a design decision about who the repository is for. A dotfiles repository that is a personal configuration is a working artefact rather than a teaching resource, and this one says so. The consequence for an adopter is that reading the tree is part of installing it. There is no installer that hides the choices, no minimal preset, and no documentation that walks through each decision, so a person who does not already know how a NixOS flake is wired will spend their first afternoon reading rather than clicking. The rest of the page is structured as a table of contents with sections for components, features, Tailscale, installation, keybindings, Fish shell aliases, AI tools and services, notes for Rust developers, and Yubikey support on NixOS. The breadth of that list is itself a description of the configuration. ## The component table is the real specification Instead of a feature narrative, the README gives a table that reads like a list of parts, and it is the fastest way to understand the scope. The foundation is NixOS with the Zen kernel, the Fish shell, Wayland as the display server and Hyprland as the compositor, with Waybar as the bar and Dunst for notifications. The launcher is Rofi-Wayland, the editor is Helix, the terminal is Kitty with Starship for the prompt, Avizo handles the on-screen display and Hyprsunset provides the night gamma shift. Fastfetch is the fetch utility. The theme is Catppuccin Macchiato, with Colloid-teal-dark and Numix-Circle icons and JetBrains Mono with a Nerd Font patch for the font. Media is Pear Desktop and Spotify, the file browser pair is Thunar and Yazi, and the browser list is Qutebrowser, Brave, Vimium, NightTab and Stylus. Mimetypes are handled by MPV, Imv and Zathura, with Swappy as the image editor. The tool list continues with the details that separate a configuration from a wallpaper: Grim and Slurp for screenshots, Wl-screenrec for recording, Hyprpicker for colour picking, and a three part clipboard stack of Wl-clipboard, Cliphist and Wl-clip-persist. Idle and lock are Hypridle and Hyprlock, the logout menu is Wlogout, and the wallpaper is handled by Hyprpaper. Boot is graphical with Plymouth and Catppuccin-plymouth, and the display manager is Greetd with Tuigreet. The README states that the full list of utilities is in the system configuration files in the nixos directory, and the repository layout confirms the split, with a nixos directory and a home directory, plus a lefthook.yml and a .gitleaks.toml at the root. The home directory is the user-level half of a NixOS flake, and the nixos directory is the system half, so borrowing one component means copying one file from one of two places. ## Podman over Docker, with a documented way back One configuration decision is explained at length, and it is the kind of thing most dotfiles repositories leave implicit. The system uses Podman instead of Docker for containerisation, and the README gives the reasons: rootless and daemonless containers, easier migration to Kubernetes, availability of pods, compatibility with systemd, and better security for distrobox. That is a considered list rather than a preference, and the last two items are the ones that bite in practice, because rootless and daemonless is a different operational model from a background daemon you can systemctl. More useful is what the README says to do if you disagree. To use Docker instead of Podman, comment out the Podman section in the nixos/virtualisation.nix file and uncomment the Docker section, and the configuration is pointed at a Docker setup on NixOS for the details. That is the pattern the whole repository follows. Nothing is hidden behind a wrapper, every choice is a file you can edit, and the README names the file that holds each decision. For an adopter this is a real advantage, because the difference between a configuration you can adjust and one you have to accept is usually a matter of whether the author told you where to look. The same honesty appears in the package sources. The configuration is built on a flake, described in the README as an experimental feature of the Nix package manager, on nixpkgs unstable, with rust on the stable channel, and the Nix User Repository is listed as currently disabled. The mixture of an experimental mechanism, an unstable package set and a stable compiler is a deliberate three-way choice rather than a single stability setting. ## Hardening is on by default, not opt-in The security posture of the configuration is stated in one note, and it is worth reading as a list of services you inherit. The system enables AppArmor and additional hardening through kernel LSMs, and it runs security services such as Fail2Ban and USBGuard. Firejail is preinstalled for sandboxing desktop applications. That is four distinct layers: mandatory access control through AppArmor, kernel-level security modules, a network intrusion tool that bans addresses, a device policy that controls what USB hardware may attach, and a per-application sandbox for the graphical programs you actually use. Notably, none of this is described as optional. There is no line in the README telling you to turn on AppArmor, and the setup is presented as the state of the system rather than as a suggestion. For someone adopting a configuration wholesale, that is a meaningful difference from a bare window manager setup, and it is one of the reasons the configuration is described as complete rather than minimal. It also changes what you have to read. USBGuard in particular imposes a policy on device access, and Fail2Ban maintains a ban list that can lock you out of a service you are trying to reach from an address it does not like. The README does not document how to reverse either of these, so anyone who adopts this configuration should look at the corresponding files in the nixos directory before they need to, rather than after. The container story ties in here as well. Podman running rootless and daemonless, and distrobox for development environments, means the sandboxing story is consistent across the system, and Firejail covers the desktop applications that containers do not. ## Tailscale is mesh networking without routing Tailscale is the networking piece, and the README is specific about how it is configured. It is enabled through the file nixos/vpn.nix, with the tailscale CLI installed. Routing features are disabled, and the configured Tailscale UDP port is allowed through the firewall. The README then moves into the authentication step after a system rebuild, which is the part that matters operationally, because a rebuilt machine is a new node until it authenticates again. Disabling routing is a meaningful choice rather than a default. A Tailscale node that does not route means the machine joins the mesh and can be reached by the other nodes, but it does not forward traffic for anyone else and does not carry exit traffic. That is a smaller attack surface and a simpler mental model, and it suits a laptop that needs to be reachable from the rest of the mesh without becoming a gateway for the rest of the network. The firewall exception is the other half of the configuration. Allowing the Tailscale UDP port is what lets the node participate in the mesh at all, and it is the kind of setting that has to match what the rest of your network expects, which is why the file that holds it is named in the README rather than buried. Tailscale sits in the component table as the mesh VPN entry, which tells you it is treated as a normal part of the system rather than an add-on, and it is the one component with a dedicated README section, presumably because the authentication step after every rebuild is the part a new user will hit first. ## Unstable nixpkgs is the price of current software The features section lists four properties, and the first of them is reproducibility, which is where the interesting tension sits. The configuration is described as reproducible, built on NixOS, so it can be reproduced on other machines and give a consistent setup. It is also consistent, since nearly every component is styled to the Catppuccin Macchiato theme. It is complete, with a wide range of components comparable to the completeness of MacOS or Windows, and it is customizable, since the files are meant to be edited. Reproducibility here means the configuration, not the software. The base is nixpkgs unstable, and the README's own warning is that this emphasis on the newest software may impact the stability of the system. The text about staying on the forefront of technology and receiving the most recent software advancements promptly is the trade stated plainly, and the warning that follows it is the other side of the same coin. That trade has a concrete shape on a desktop. A compositor, a bar or a keybind library can change behaviour between one rebuild and the next, and a Wayland session that will not start after an update is a bad afternoon. The author's position is that this is acceptable, and for a daily driver that tracks upstream closely it is a defensible one, but it means the configuration cannot be treated as something you install once and forget. The README also shows what happens when a decision needs to be reversed, as with the nur repository being listed as currently disabled. The disabled entries are marked in the text rather than removed, which keeps the history of the choice visible in the configuration itself. ## Where this configuration is the wrong choice There are honest reasons to pass on this repository, and most of them come from it being a personal artefact. The first is the size. The README says it is not minimalistic or lightweight and may require disk space, and the component table backs that up with roughly thirty named programs. A person who wants a window manager, a terminal and a file manager will find far more here than they asked for, and every extra service is another thing to configure, another thing to update and another thing that can be the reason a rebuild behaves differently. The second is the knowledge requirement. This is a flake, which the README itself calls an experimental feature of the Nix package manager, and it is a personal configuration with no explanation of why each choice was made. Adopting it wholesale means adopting decisions whose rationale exists only in the author's head, and when the unstable channel moves a package, you are debugging someone else's preference. The third is the release situation. The repository has no GitHub releases, so there is no tagged version to point Nix at. The last push was on 2026-10-18, so the tree is being worked on, but a flake reference to a branch means a rebuild can pull in changes you did not review. The README's own note that the screenshots do not reflect the latest version of the system's appearance, is a small hint of the same thing. The fourth is specific hardware. The configuration lists Wayland, Hyprland, a specific set of applications and utilities, and a graphical boot with Plymouth, and none of the README discusses which graphics hardware it was written against. A configuration that assumes a particular kind of machine will not carry to another one without edits, and the details of those edits are in the nixos directory rather than in the documentation. The licence is MIT, which is permissive and short, and the repository includes a .gitleaks.toml, so secret scanning is part of the workflow. That file matters more than usual here, because a configuration that people copy tends to carry machine specific values, hostnames or credentials with it. ## Conclusion This configuration fits a person who already uses NixOS and Hyprland and wants a complete, themed desktop they can reproduce on a second machine, and it fits someone who wants to borrow one component, since the tree is split into readable configuration files under nixos and home. It does not fit a newcomer looking for a lightweight setup, since the README says so directly, and it does not fit a machine that needs a stable channel, since nixpkgs unstable is the base and the author warns that the newest software may affect stability. Before adopting it, read the component table against your own hardware, check the switch in nixos/virtualisation.nix if you want Docker instead of Podman, and confirm that the nixpkgs unstable pin still builds on your machine before making it your daily driver. ## FAQ ### What is in the linux-nixos-hyprland-config-dotfiles repository? It is a NixOS flake configuration for a Wayland desktop built around Hyprland with the Catppuccin Macchiato theme, using the Zen kernel and Fish shell, and including Waybar, Dunst, Rofi-Wayland, Helix, Kitty with Starship, Greetd with Tuigreet, Podman and Tailscale. The repository is split into a nixos directory for system configuration and a home directory for user configuration. ### How do I switch this NixOS configuration from Podman to Docker? The README says to comment out the Podman section in the nixos/virtualisation.nix file and uncomment the Docker section. Podman is used by default because of rootless and daemonless containers, easier migration to Kubernetes, pods, systemd compatibility and better security for distrobox. ### Does this configuration use the unstable Nix channel? Yes. The base is nixpkgs unstable with rust on the stable channel, and the Nix User Repository is listed as currently disabled. The README warns that the emphasis on the newest software may impact the stability of the system, so the configuration trades stability for current versions. ### What security features does this NixOS setup enable? The README states that the system enables AppArmor and additional hardening through kernel LSMs, runs security services such as Fail2Ban and USBGuard, and preinstalls Firejail for sandboxing desktop applications. Containers run with Podman rather than Docker, which the README links to rootless and daemonless operation and better security for distrobox. ## Sources - [Issues](https://github.com/XNM1/linux-nixos-hyprland-config-dotfiles/issues) - [License: MIT](https://github.com/XNM1/linux-nixos-hyprland-config-dotfiles/blob/main/LICENSE) - [README](https://github.com/XNM1/linux-nixos-hyprland-config-dotfiles/blob/main/README.md) - [XNM1/linux-nixos-hyprland-config-dotfiles on GitHub](https://github.com/XNM1/linux-nixos-hyprland-config-dotfiles) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xnm1-linux-nixos-hyprland-config-dotfiles