HyDE is the most theme-heavy Hyprland setup going: 70-plus built-in themes, a themed SDDM, its own lock screen, blur and glass effects configured out of the box. It is also Arch-native, and its installer assumes it can write wherever it likes.

HyDE Hyprland Dotfiles on NixOS

HyDE's own README handles this by pointing NixOS users at Hydenix, a home-manager rewrite of HyDE. That is a legitimate approach, and it is not the one I took.

There are two strategies for getting software like this onto NixOS, and the choice between them is the actual content here.

Rewrite the app, or rewrite the environment

Strategy one: rewrite it as Nix. Express every config, every service, every path as Nix modules. Idiomatic, declarative, pleasant to read. The cost is that you now own a fork. Every upstream change has to be ported by hand, and the rewrite drifts from the original until it is a different project that looks like HyDE.

Strategy two: leave upstream alone and fake the environment it expects. Pin HyDE at a commit, run HyDE's own deployer, and build the FHS paths and runtimes its scripts assume into the system. Less pure. But upstream changes arrive by bumping one hash, and what you get is actual HyDE rather than a reimplementation of it.

I went with the second. The whole thing is two files, flake.nix and hyde.nix, and the install is three commands:

cd /etc/nixos sudo curl -fLO https://raw.githubusercontent.com/musabase/hyde-hyprland-nixos/main/flake.nix sudo curl -fLO https://raw.githubusercontent.com/musabase/hyde-hyprland-nixos/main/hyde.nix sudo sed -i "s/CHANGEME/$(whoami)/" flake.nix 
sudo NIX_CONFIG="experimental-features = nix-command flakes" \ nix-shell -p git --run "nixos-rebuild switch --flake /etc/nixos#nixos" 

Reboot into a themed SDDM and you are in. About 20 minutes on my machine.

Those files run as root during the rebuild, so read them before you run them. Both are printed in full in the guide, and pinning a commit instead of main means they cannot change after you have reviewed them.

The four fixes, which are the actually interesting part

Strategy two means the work is in the gaps between what HyDE assumes and what NixOS provides. Four stand out.

HyDE hardcodes FHS paths. /bin/bash, /usr/bin/python3, /usr/share/oh-my-zsh, /usr/bin/rofi. None of those exist on NixOS. Rather than patch every script, create them as symlinks:

systemd.tmpfiles.rules = [ "L+ /bin/bash - - - - ${pkgs.bash}/bin/bash" "L+ /usr/bin/python3 - - - - ${hydePython}/bin/python3" "L+ /usr/share/oh-my-zsh - - - - ${hydeOmz}" ]; 

HyDE builds a uv venv and sources its activate script. A real venv cannot live in the read-only Nix store, so the Python environment comes from nixpkgs and gets wrapped in something that provides a fake activate:

cat > $out/bin/activate <<'EOF' VIRTUAL_ENV=/etc/hyde/python_env export VIRTUAL_ENV case ":$PATH:" in *":$VIRTUAL_ENV/bin:"*) ;; *) PATH="$VIRTUAL_ENV/bin:$PATH" ;; esac export PATH deactivate () { :; } EOF 

The environments are exposed at /etc/hyde/ specifically because /etc survives garbage collection, so HyDE's scripts always find them.

killall does not match Nix wrapper names. HyDE restarts Waybar and Dunst with plain killall waybar. NixOS names the running process .waybar-wrapped, so the call silently fails and your bar never comes back. Fix is a shim that retries with a regex:

${pkgs.psmisc}/bin/killall "$@" 2>/dev/null && exit 0 name="${!#}" set -- "${@:1:$#-1}" exec ${pkgs.psmisc}/bin/killall "$@" -r "^\.?${name}(-wrapped)?$" 

Installed with lib.hiPrio so it wins over the real one.

My favourite: luarocks is installed to satisfy a check. HyDE's activate script refuses to start unless luarocks is on PATH. The Lua modules themselves come from nixpkgs and luarocks never installs anything. It is there purely so the presence test passes.

There is one more worth mentioning because of how it fails. One line in HyDE's theme.switch.sh looks for themes in the read-only system profile, and it gets rewritten with substituteInPlace --replace-fail. The --replace-fail matters: if upstream ever changes that line, the build breaks loudly instead of deploying something subtly wrong.

What this costs you

Being straight about the trade-offs, because the flake makes two decisions on your behalf.

It follows nixos-unstable. Not just for HyDE, for your whole system. HyDE needs a recent Hyprland and Qt, so if you installed from the stable ISO this rebuild moves everything to unstable. Intentional, and rollback from the boot menu works, but you should know going in.

The dotfiles land in $HOME, and a rollback does not remove them. nixos-rebuild switch --rollback undoes every system change cleanly. It does not touch the files HyDE copied into your home folder, because those were copied by a user service rather than built into a generation. Uninstalling is genuinely two steps.

Budget 30GB on root. The install itself is around 20GB.

Also worth knowing: the first login looks half-styled for a few minutes while HyDE imports its theme pack from GitHub. Wait for the "Setup finished" notification before rebooting.

The broader point

NixOS discussions default to the rewrite. Something is not packaged, so you express it in Nix and own the result.

The alternative is cheaper than it looks. Most Arch-native software does not need porting, it needs a handful of paths, a runtime and an environment variable. Build that illusion and upstream runs unmodified, which means you track upstream by changing a commit hash instead of by reading diffs.

The full walkthrough, with both .nix files printed and annotated line by line, the NVIDIA additions, the uninstall steps and a long FAQ, is on my site: How to Install HyDE Hyprland Dotfiles on NixOS.

This completes the set. The same treatment for Caelestia, End-4, JaKooLit and ML4W on NixOS, and a comparison of all five if you have not picked one yet.

If you have taken the rewrite route instead, with Hydenix or your own modules, I want to hear how maintenance has gone over time. That is the part I cannot test from one side of the fence.

Originally published on MusaBase.