Nix

It is hard to pin Nix to one specific category of tools. It can be used simply as a package manager—install the binary and run nix-env -iA nixpkgs.python314, and you'll get Python 3.14 on your system. However, what if you need to use Python only once and don't wanna install it? You could run nix-shell -p python314 and get a temporary shell with Python. Wanna add more packages, customize their settings, and set up environment variables for one project? Declare it all in a flake.nix file, run nix develop, and now you've got a reproducible development environment you can share with your teammates. Moreover, you are guaranteed to have exactly the same environment, across re-runs and different operating systems, without any implicit dependencies but Nix itself.

What is Nix?

At its core, Nix is a build tool, a cross-platform package manager built around it. Unlike other such tools, Nix ensures that builds are reproducible, meaning that for identical inputs, you'll get identical binaries as the output. Not only does it improve reliability, but this strategy allows for more fine-grained caching mechanisms to speed up consequent builds. You might say, aren't Docker images like that as well? If you run docker pull python:3.14, you will get an image of Python 3.14, but its authors can update or change its dependencies and push a new image with the same 3.14 tag, potentially breaking your setup. Even if you use a digest hash instead of the tag, this still doesn't guarantee that every rebuild of a Dockerfile with that Python image will produce the same output, as there are usually other dependencies e.g. installed via apt-get. In contrast, Nix ensures reliability on all levels of the dependency tree¹. As with Docker, Nix has an official package repository called nixpkgs with over 140 000 packages and counting.

How does it work?

For starters, Nix comes with its own programming language. It is declarative and purely functional, meaning that there are no side-effects or undeclared inputs influencing its execution. Every package, be it executable or library, is defined as a Nix program, and running it creates a folder containing the cryptographic hash of the package's whole dependency tree. The dependencies themselves are not stored with the package—they get their own folders tagged with hashes. All these folders reside in the Nix store, a directory only Nix can write into. If, for example, program-a and program-b both depend on different versions of library-c, the Nix store will contain two versions of the library, avoiding any conflict (goodbye DLL hell). If the version is exactly the same, the programs will share library-c, avoiding duplication. Moreover, you can push Nix packages into a shared cache storage from which other developers, CI/CD actions, and runtime environments can pull pre-built binaries, as they're guaranteed to be identical to those built with the same configuration from scratch.

Enter NixOS

What if you apply the same approach not just for individual software packages, but for the whole operating system? NixOS does just that. It's a Linux distribution where everything—kernel modules, filesystem partitioning, user management, software configuration, even /etc/hosts file—is defined using Nix². Moreover, any change in configuration and the subsequent rebuild creates a new snapshot of the OS called generation, so if anything breaks, you can simply roll back to the previous OS state in no time. Need to manage several different OS setups with shared parts? There's nothing to stop you from splitting the config into several files and import them for each setup as needed.

It is common for an OS to grow in size as packages are installed, updated, and removed, leaving a lot of stray files behind and creating a thriving market for apps such as CleanMyMac. Since every dependency in NixOS is traceable, identifying and removing unused packages is trivial, and Nix comes with a garbage collector to do the job for you. In practice, it's generally good to keep as many packages as the space allows, since they won't have to be re-built if you happen to need them later on³.

The downsides of Nix

It cannot be all roses and rainbows, right? As with any powerful tool—especially one which has spun out of a PhD dissertation⁴—there's a lot of initial learning to do, and currently there's no single beginner-friendly resource to ease the process. Additionally, the Nix tooling ecosystem is vast and there are always multiple ways of achieving the same goal. Some software depends on assumptions not applicable to NixOS, like expecting certain programs under /usr/bin folder. Such issues are solvable, but they do take time to figure out. Fortunately, there are higher-level Nix tools that provide a good middle ground between flexibility and ease of use⁵.

Summary

With all this in mind, we definitely recommend to get curious about Nix, yet without false hopes of it solving every problem in software package management there is. Nix is a great tool that is starting to be noticed by the industry, but even a great tool might not be the right one in certain situations. If you don't seem to struggle with "it worked on my machine"–type issues, and your current software provisioning and configuration management setup works well for you, Nix might not be worth the investment. This is largely the case for us at Kiwee, so we're putting Nix in the Assess ring as a promising technology for further evaluation.

---

Footnotes

1. It must be noted that Nix and Docker serve slightly different purposes and thus cannot be compared on the same terms; in fact, there are many advantages of using them in tandem. ↩

2. With the notable exception of the home directories—although there are Nix-based tools for that too! ↩

3. Smart garbage collection strategies can be specified, e.g. "If disk space is <5GB, remove up to 10GB of the oldest unused packages from the Nix store." ↩

4. Nix was initially developed 20 years ago by Eelco Dolstra during his PhD at Utrecht University. ↩

5. One such project is devenv, a comprehensive solution for defining and sharing per-project developer environments without the drawbacks of containerization common with e.g. Docker Compose setups. ↩