Hacker News new | past | comments | ask | show | jobs | submit login

Nix makes it really simple and easy to manage several machines. Builds are declarative and reproducible. For my homelab I’ve setup a git repo with config for several VMs: Plex, Bitwarden, torrents, Samba shares, etc. Deploying is as simple as pushing a new commit and then triggering a rebuild on a specific host.

NixOS builds in “generations”. This morning I managed to screw up something and it bricked a VM. No worries, just restart the VM, boot into the previous working generation. Fix my Nix config, commit and push, rebuild again. Easy. I love it for managing my personal stuff.

What I don’t like about Nix? The Nix language kind of sucks, has a steep learning curve, and lacks decent language tooling (LSP etc). If you’re on the beaten path everything is rosy, but as soon as you need to configure something or build a package that no one else has done before, it feels like you need to reverse-engineer Nix just to figure out how to do fairly basic tasks.




> Deploying is as simple as pushing a new commit and then triggering a rebuild on a specific host.

Or you can forgo /etc/nixos and push from your current machine with

    nixos-rebuild switch -v --target-host machine2 --flake .#machine2


This is true, if you have nixos-rebuild available on your current machine.

I just use a script to run the command remotely via ssh and point to the flake in git.


This works sometimes but cross arch builds can be problematic. I use Nix on macOS so I have to use a remote build host (or a VM).


It's possible to push from x86_64 to aarch by setting this in the system configuration:

   boot.binfmt.emulatedSystems = [ "aarch64-linux" ];
With that setting pushing from e.g. laptop to raspberry works. Nix on macOS does not have that setting, but perhaps there's an equivalent.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: