Sly-Harvey's NixOS configuration: a flake with hosts, dev shells and rollbacks

What this repository is and how it is organised

This is a personal NixOS configuration, and the README says so in the title, My NixOS Configuration, with the topics listing the technology in plain terms: NixOS plus Hyprland, with flakes, home-manager and dev-shells. The repository description adds that it is a NixOS and Hyprland setup with flakes, home-manager and dev-shells.

The layout is the interesting part, because it is a generic structure rather than a pile of scripts. The root holds flake.nix and flake.lock, the Nix entry points that define the outputs and pin the inputs. A hosts directory holds one directory per machine. A modules directory holds the reusable NixOS modules, and an overlays directory holds package overlays, with a pkgs directory alongside it for local packages. The dev-shells directory holds the development environments, and install.sh and live-install.sh are the entry points for installation.

The host model is what makes the configuration scale past one laptop. Every host lives in its own directory with the same three files: variables.nix holds host-specific variables, host-packages.nix lists the packages installed on that host, and configuration.nix holds the module imports for the host plus any extra configuration. The README asks you to check and adjust those three files before installing, which is a reasonable instruction because they are the only per-machine knowledge in the repository.

The repository is MIT licensed, with the licence file at the root, and the last push was on 2026-10-13. The README also points at a Ko-fi link, which tells you the maintainer is the person this configuration is written for, and that is the first thing to weigh before adopting it as a starting point.

Installing: clone, adjust, run install.sh

The installation instructions allow two starting points, a running system or the NixOS live installer, and they recommend the minimal ISO from the NixOS website.

The first steps are the familiar ones.

git clone https://github.com/Sly-Harvey/NixOS.git ~/NixOS
cd ~/NixOS

The installer is a single script.

./install.sh

What that script does is described in the README: the install and rebuild scripts automate the setup process, including hosts, username, and applying the configuration, and they automatically generate the hardware-configuration.nix file based on the detected hardware. That last point removes the single most tedious step of a manual NixOS install, where you normally boot a live environment and hand-generate a hardware configuration for the machine you are on. The script reads your system and writes the file, which is the approach that makes an unattended install plausible.

A second script, live-install.sh, sits next to install.sh in the root, which suggests the same automation is available for the live installer path where there is no existing system to detect.

Managing hosts: the Default template and the nixosConfigurations block

Adding a machine is the operation you will do most often, and the README offers an automatic and a manual route. The automatic route is to run the installer again and select or create another host, which is the path to take when you want the generated hardware configuration for a new physical machine.

The manual route is for a machine you already know. The steps are to copy the hosts/Default directory to a new directory such as hosts/Laptop, edit that host's variables.nix and host-packages.nix, and then register the host in flake.nix. The registration is a small block.

  nixosConfigurations = {
    Default = mkHost "Default";
    Laptop = mkHost "Laptop";
  };

The block assigns each host name to a helper called mkHost, so the per-host directory name is the identity used everywhere else. Once the host is registered, the README instructs you to track the new directory with git, and then rebuild with the new hostname, using either nixos-rebuild or nh. After the rebuild the host name is recognised implicitly, which means the hostname-specific commands work without extra flags.

git add hosts/Laptop

The two rebuild tools are both supported, and the README mentions that once rebuilt you can use either the shortcut or the rebuild command. Keeping both paths alive is a practical choice: nixos-rebuild is the upstream tool that will always exist, while nh is the newer helper that people tend to prefer once they know it.

Rebuilding and rolling back to a previous generation

Applying configuration changes is what the whole setup exists for, and there are four documented ways to do it.

The shortest path is the keyboard shortcut Super plus U, which is what a graphical session is for. There is a rebuild script as well, and then the two command-line tools with the host name filled in. Replace the placeholder with the name of your host, for example Laptop, in either case.

Rollback is the part that distinguishes a NixOS setup from a reinstall script, and it is unusually ergonomic here. Listing generations is one command.

list-gens

Rolling back to a specific generation is another.

rollback N

Because NixOS keeps every configuration as an immutable generation on the store, going back to a working state is a matter of naming the generation number rather than restoring files. The README's example uses 69, which is a hint about how quickly the generation counter moves on a machine that rebuilds often. The pair of commands is what makes an aggressive workflow safe: apply a change, and if the result is broken, move back a generation instead of debugging a machine you cannot log into.

Development shells exposed as flake templates

The dev-shells directory turns language toolchains into something you can start a project from, and the mechanism is the one people expect from flakes but rarely find configured for them.

A new project can be created from one of the templates directly.

nix flake init -t ~/NixOS#<TEMPLATE_NAME>

Or the template can be applied to a directory you already have, which is the more useful of the two for an existing codebase.

nix flake new -t ~/NixOS#<TEMPLATE_NAME> <PROJECT_NAME>

The templates themselves are defined in dev-shells/default.nix, with the README naming Python and Node among the languages covered. Entering the shell then takes the standard nix develop command inside the project directory.

cd <PROJECT_NAME>
nix develop

The direnv integration is the detail that makes this pleasant in daily use: if you are using direnv, the allow command activates the shell automatically when you enter the directory. Without direnv the benefit is smaller, since you have to remember to enter the shell. With it, a project directory carries its own toolchain, and a teammate who clones the same repository gets the same environment without a README paragraph explaining which versions to install.

The combination with the host model is what makes the whole thing coherent. The machine is described by its flake, and the project is described by the same flake, so a single lock file governs both the desktop and the development environment it hosts.

What to copy, what to replace, and the cost of a personal config

The honest reading of this repository is that it is one person's taste expressed in Nix, and the parts that generalise are not the parts that look most personal. The structure generalises: one directory per host with three files, a modules directory for shared configuration, overlays for local packages, a dev-shells directory, and a script that automates the parts of an install that are tedious. That layout scales from one laptop to a small fleet, and it is what you would design yourself if you had to.

What does not generalise is the content. The package list, the Hyprland theme, the keybindings and the wallpaper are the parts that encode one desktop, and the README's own credits table shows where the aesthetics come from: Hyprland-Dots for scripts and Waybar templates, HyDE for additional scripts, rofi for launcher styles, dev-templates for the development templates and Vimjoyer for NixOS tutorials. That is a useful list to read as a starting point for your own sourcing, and it is also a reminder that the visual layer of this configuration is assembled from other people's work rather than designed here.

The second cost is the learning curve, and it is real. Nix is a different model from a package manager, the failure modes are unfamiliar, and the first rebuild on a broken configuration can be disorienting for someone who has never seen a generation before. The rollback commands mitigate that, and so does the fact that the configuration is a Git repository you can read before you install it.

The alternative worth weighing is writing a minimal NixOS configuration yourself, which is a few dozen lines, and adding hosts and shells as the need appears. That path avoids inheriting someone else's opinions and avoids the theme layer entirely, at the cost of designing the same structure from scratch and doing the hardware configuration step by hand. For a single experimental machine that is usually the right trade. For several machines and a shared team environment, a configuration with this much structure already written is the better starting point.

Editorial conclusion

This configuration is a good template for a team that wants its machines to be reproducible from a flake, and the per-host layout plus the rollback commands are the parts worth copying. It is the wrong starting point for a general-purpose OS image, since the package list, theme and keybindings encode one person's preferences. Verify first that you edit the three files the README points at before installing, that the flake lock file matches what you want to pin, and that your target host name appears in the nixosConfigurations block before you rebuild.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Sly-Harvey/NixOS on GitHub