Nix: a package manager built on a content-addressed store

The problem Nix solves: package management as a pure function

Conventional package managers mutate a shared filesystem. Installing a library writes into /usr/lib, upgrading a compiler overwrites the previous one, and two projects that need incompatible versions of the same dependency end up in a conflict that the user resolves by hand. Nix takes the opposite position. A package build is treated as a function of its inputs, and the result is placed in a store where it cannot collide with anything else. The README describes the project as "a powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible", and the word reproducible is doing the real work in that sentence. The audience is developers and system administrators who have been burned by an upgrade that broke an unrelated program, or who need the same software tree on a laptop, a CI runner and a server without drift between them. It is not aimed at someone who wants the smallest possible change to a standard distribution. Nix asks you to accept a new model of where software lives before it gives you anything back.

How the store, the Nix language and derivations fit together

The architecture visible in the repository is a C++ core (src/) that implements the store, the evaluator and the command line, wrapped by documentation in doc/ and a test suite in tests/. The model works in two stages. First, a Nix expression written in the Nix language describes what should be built: which sources, which compiler, which dependencies. Evaluating that expression produces a derivation, a description of a build action rather than the build itself. Second, the derivation is realised, and the output is written into the store under a path derived from the hash of its inputs. Because the path encodes the inputs, two derivations with different dependencies never produce the same store path, which is why installing one version of a library cannot overwrite another. The repository also carries flake.nix and flake.lock at the top level, so the project builds itself with the flake mechanism it ships. Topics on the repository list declarative-language and functional-programming alongside c-plus-plus, which matches the split: the evaluator is a functional language, and the store is the runtime that language targets.

Getting Nix and building the repository from source

The README carries no install commands. It sends readers to nix.dev for installation instructions and beginner tutorials, and to the Nix manual for full reference documentation, so the practical first step is opening that installation page rather than copying anything out of the repository. What the repository does show is how the project builds itself. There is a flake.nix and a flake.lock at the top level, alongside default.nix and shell.nix, and the README points to the manual's section on setting up a development environment and building Nix from source. The build system is Meson: meson.build and meson.options sit in the repository root, with the supporting glue in nix-meson-build-support/. That arrangement creates a bootstrap problem worth naming. Contributing to Nix requires a working Nix, because the development environment is expressed in Nix itself, so a new contributor has to install the tool before they can build the tool. The CI configuration lives in .github/ and ci/, and the test suite in tests/, which is where a change to the evaluator or the store is most likely to be exercised.

Garbage collection is manual, and that is a real cost

Every build and every ephemeral shell leaves content in the store. Nothing removes it automatically. The related searches around this project include "nixos nix gc", which suggests the collection step is a common source of confusion, and the mechanism behind it is straightforward: store paths accumulate until you run garbage collection, and until then disk usage grows with every experiment. On a workstation where you try packages casually, this is the most likely first surprise. The store is also not a normal prefix, so anything that hardcodes a path like /usr/bin or /lib will not find it there. Programs that expect a conventional filesystem layout need patching, and the repository's packaging/ and misc/ directories exist partly because that patching is a recurring job. This is the strongest argument against adopting Nix on a machine where you want the smallest possible deviation from a stock system.

Nix compared with NixOS, and with a conventional manager

The most common confusion around this project is the boundary between Nix and NixOS, and the search data reflects it: "What is the difference between Nix and NixOS?" and "nixos vs nix" both appear. The distinction is structural. Nix is the package manager, and it runs on Linux and other Unix systems, including on top of an existing distribution. NixOS is a Linux distribution built on Nix, described in the README as one "that can be configured fully declaratively". You can adopt Nix without touching your bootloader; adopting NixOS means the whole system configuration becomes a Nix expression. Compared with a conventional manager such as apt, the difference is not speed or package count but where state lives. apt installs into system directories and tracks one version per package. Nix installs into the store and permits many versions side by side, at the cost of the store's size and the need to learn the Nix language before you can express anything beyond a shell invocation. The README also points to Nixpkgs, which it calls the largest free software repository in the world, as the package collection the ecosystem draws on.

Licence, build requirements and what upgrading involves

Nix is released under the LGPL v2.1, per the COPYING file and the README's licence section. For most users this changes nothing: running the package manager, or building packages with it, is not the same as modifying and redistributing Nix itself. If you fork the evaluator or link it into another product, the LGPL's terms on modification and relinking apply, and that is a question for your own legal review rather than something this article can settle. On maintenance, the repository is not archived and the last push was on 2026-09-21. Building from source is documented in the Nix manual's development section, which the README links, and the repository layout supports it: meson.build and meson.options at the top level, nix-meson-build-support/ for the build glue, and default.nix and shell.nix for a development environment expressed in Nix itself. That last detail is worth noticing. Contributing to Nix requires a working Nix, which makes the bootstrap step the first real hurdle for a new contributor.

Editorial conclusion

Nix suits engineers who already accept a declarative build model and want package installations that do not mutate shared system state, and it is the right starting point for anyone who intends to move on to NixOS or Nixpkgs. It is the wrong tool if you want a drop-in replacement for apt or dnf on a single machine, because the Nix language and the store model have to be learned before the first useful expression. Before adopting it, read the installation page at nix.dev and the manual's development section on building Nix from source, since the README points to both and documents neither.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-2.1
3. NixOS/nix on GitHub
4. Project website
5. README