by jchw | 2025-06-09 00:04:30+00:00
I think you may be overthinking things. In brief;

Nix is two things: a functional programming language called Nix, and a package manager written in C++ that compiles and installs packages written with Nix expressions. Nix the language itself, and it's implementation.

Nixpkgs is a repository of Nix packages. It also contains NixOS, which is also just a bunch of Nix.

NixOS is a Linux-based operating system built on Nix. It is configured using NixOS modules, a configuration system of sorts built on top of the Nix programming language. A NixOS system is literally a single big Nix package built from NixOS modules that depends on a bunch of other packages.

If this still seems too complicated it would probably be better to just dive in and mess with it so you can physically see what's going on.

> current problem is taking a homelab server into “production” and all I really want is a way to write down a state I want the services on it to be in, have that in a git repo and be able to regenerate this server after loosing it (in a first step without any data backup). I’m still, after 2 months (wall clock, call it maybe 3 days actually getting into this project), not sure if that’s a thing Nix tries to cover! (I think it does, but..)

Yes that does sound like something NixOS can cover. Obviously, you will still need backups for your mutable data (databases, files, etc.), but if you are able to encapsulate the entire setup of a server into a NixOS config you can indeed throw a machine out the window and have a new one set up and booting the exact same services in minutes.

This is pretty much the original thing that drew me into NixOS, especially because at the time I was highly interested in qemu GPU passthrough setups and I really liked how with Nix all of the complicated setup bits could be expressed in a single file, with about 20 lines of Nix, all accounted for and version controlled. A lot better than just hoping you remember to keep things documented.

I won't lie, learning NixOS and using it for a real machine setup was very painful for me at first. I struggled with many things over time. Still, I really think because the scope of things these projects do is huge it's really easy to overcomplicate things. All of the explosive scope of Nix comes from relatively simple primitives applied in large systems.

I really don't want to encourage people to suffer with Nix if they feel like it's just too convoluted and hard to work with. I am not trying to convey that Nix is simple or easy on the whole. I was only ever trying to explain why I felt the issues raised by this post were confusing to me, not trying to tell people that Nix is generally easy. I think a lot of replies genuinely continue to misunderstand this, but the point of saying that it's easy to do that in Nixpkgs is not to dunk on people who struggle with Nix, it's to say that it's not clear why Nixpacks would struggle with these particular issues. You can literally just split the /nix/store paths into separate OCI layers. There is no obvious reason why this strategy can't be used, and the blog post doesn't go into the background behind it. I bet there actually is background, it's just left unsaid.