Have you ever broken an environment by updating a package, or spent hours reproducing a colleague's setup? Nix is a package manager that removes these problems at the root. Every package is isolated, versioned and reproducible: two machines configured the same way get the same packages, at the same path.
This guide lays the foundations: you will understand what Nix brings compared with classic package managers, how the various building blocks of the ecosystem fit together, and in which concrete cases to adopt it.
What you will learn
- Place Nix in the landscape of Linux package managers
- Identify the three facets of Nix: manager, language and philosophy
- Understand the key concepts: store, hash, profiles, generations
- Compare Nix with apt, dnf, Homebrew, asdf, mise and Docker
- Decide when to adopt Nix, and when it is not the right choice
In what context?
Nix answers problems that every administrator or developer meets sooner or later:
- You run servers and a library update breaks a production service, with no
way back with
apt. - Your team shares a project, but everyone has different versions of Python, Node.js or Terraform, the famous "it works on my machine".
- You are trying a tool for 5 minutes and do not want to install it permanently on your system.
- You are preparing a CI/CD pipeline and need an environment identical between your workstation, the build server and production.
- You manage several projects that depend on incompatible versions of the same library (the dependency hell).
If one of these scenarios sounds familiar, Nix probably has something to offer you.
What Nix actually solves
The problem: fragile, non-reproducible systems
Traditional package managers, apt, dnf, pacman, share the same
model: packages are installed into shared directories (/usr/bin,
/usr/lib). This model has three structural weaknesses.
Dependency conflicts. When two programs need different versions of the same library, the system can only keep one. Installing one breaks the other.
No reliable way back. apt upgrade modifies files in place. If the update
breaks something, there is no "undo" button that restores the previous state.
Non-reproducibility. Two machines installed "more or less the same way" drift apart over time: updates done on different dates, packages added by hand, PPAs or third-party repositories... The final state is unpredictable.
The Nix answer: isolation, immutability, reproducibility
Nix takes a radically different architecture. Every package is stored in its own directory, identified by a unique hash:
/nix/store/aaaa1111...-python-3.12.0//nix/store/bbbb2222...-python-3.10.0//nix/store/cccc3333...-openssl-3.0.0//nix/store/dddd4444...-openssl-1.1.1/Two versions of Python coexist without conflict. Every package refers to its exact dependencies by their path in the store: two packages that use the same OpenSSL version share the same directory, two packages that want different versions each point to their own. No file is modified in place, so nothing can be overwritten by an update.
Nix as a package manager
This is the first facet of Nix and the most immediately useful. Nix can be installed on any Linux distribution and on macOS, alongside the native package manager.
What Nix does differently
The table below sets Nix against classic package managers on the points where the difference shows in daily work. The two rows that really change the game are version coexistence and rollback: they explain why a team adopts Nix despite its learning curve.
| Feature | apt / dnf | Nix |
|---|---|---|
| Version coexistence | No, one version per package | Yes, as many versions as needed |
| Rollback | No native mechanism | Instant rollback by generation |
| Temporary installation | No | Yes, nix shell loads a tool without installing it |
| Reproducibility | Depends on the date and the repositories | Same inputs, same store path (hash) |
| Impact on the system | Modifies /usr/lib, /usr/bin | Only touches /nix/store |
More than 100,000 packages
The nixpkgs repository (pronounced "nix-packages") is one of the largest software repositories in the world. It contains more than 100,000 packages, regularly updated by an active community.
Nix as a programming language
The second facet of Nix is less visible but fundamental: Nix has its own functional programming language, used to describe how to build and configure packages.
You do not need to master the language to use Nix day to day. But as soon as you want to create your own development environments or understand how a package is built, the language becomes essential.
What the Nix language lets you do
- Describe a development environment in a
shell.nixfile: Python 3.12 + requests + Flask + a linter, all of it reproducible. - Define a package: its sources, its dependencies, its build options, in a Nix expression.
- Factor and modularise: import files, create reusable functions, compose configurations.
A declarative paradigm
With classic managers, you give instructions (imperative paradigm):
# Imperative: "do this, then this"apt install python3pip install requests flaskThe final state depends on the order of the commands, on what was already installed, and on the date of the last system update.
With Nix, you describe the desired state (declarative paradigm):
# Declarative: "here is what I want"{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell { packages = [ pkgs.python312 pkgs.python312Packages.requests pkgs.python312Packages.flask ];}Nix works out how to reach that state. Two machines evaluating this expression with the same nixpkgs version get the same environment.
Nix as a philosophy: the three pillars
Beyond the manager and the language, Nix embodies a software management philosophy built on three pillars.
Pillar 1, Reproducibility
Everything in Nix is designed to be deterministic. The hash of every package is computed from all of its inputs: source code, dependencies, build options, compiler.
Hash = f(sources + dependencies + options + compiler)If the inputs are identical, the path in the store is identical, and the built result is too in the vast majority of cases, byte for byte. This is what lets two independent machines produce the same environment without any coordination, and lets the binary cache serve an already built package instead of recompiling it.
Pillar 2, Isolation
Every package lives in its own directory under /nix/store/. It modifies
no system directory such as /usr/lib, and only sees the dependencies it
references explicitly. This isolation removes dependency conflicts by
design.
Pillar 3, Atomicity and rollback
Every operation creates a new generation (a snapshot of your profile). The previous state stays intact. If something goes wrong, a rollback restores the previous state in one command. There is no corrupted intermediate state.
The ecosystem around Nix
Nix is the foundation on which several complementary projects rest.
| Project | Role | Relationship with Nix |
|---|---|---|
| Nix | Package manager + language | The core of the ecosystem |
| nixpkgs | Repository of 100,000+ packages | The reference library |
| NixOS | Declarative Linux distribution | Complete system driven by Nix |
| Home Manager | Declarative management of dotfiles | Configures the home directory with Nix |
| Flakes | Dependency system + lock file | Stronger reproducibility |
| Cachix | Shared binary cache | Speeds up builds in CI/CD |
Nix vs NixOS: do not confuse them
Nix (the package manager) installs on any Linux distribution or on macOS. You keep your current system, Debian, Ubuntu, Fedora, and add Nix on top.
NixOS is a complete Linux distribution where the whole system is configured by Nix expressions: kernel, services, network, users. It is a much stronger commitment.
Flakes in a word
Flakes are a major evolution of the Nix ecosystem. They add a
flake.lock file that freezes the exact versions of all dependencies (like
package-lock.json in JavaScript or Cargo.lock in Rust).
In practice, flakes solve the problem of classic channels: instead of depending on a nixpkgs branch that moves over time, you reference a precise commit, locked in the lock file.
We cover them in detail in the guide Understand and use flakes.
Comparing Nix with existing tools
Nix vs apt / dnf
This is the most useful comparison, because apt and dnf are the managers you already know. Remember that Nix does not necessarily replace apt: it aims at a broader scope (languages and dev tools, not just system packages) and adds rollback and the declarative approach, at the cost of a longer learning curve.
| Criterion | apt / dnf | Nix |
|---|---|---|
| Scope | System packages only | System + languages + tools |
| Versions | A single installable version | Multiple versions side by side |
| Rollback | No | Yes, by generation |
| Declarative | No (except Ansible/Puppet on top) | Natively |
| Learning curve | Low | Medium to high |
Nix vs Homebrew
Homebrew is simple and popular on macOS. Nix is more powerful but more
complex. Homebrew installs into /opt/homebrew/ on Apple Silicon Macs,
/usr/local/ on Intel Macs and /home/linuxbrew/.linuxbrew/ on Linux, with a
classic model: one version per formula, no isolation by hash and no
rollback.
Nix vs asdf / mise
asdf and mise manage versions of development tools (Node.js, Python, Terraform...). Nix goes further: it also manages system libraries and C dependencies, and lets you describe complete environments.
If all you need is to switch between Node 22 and Node 24, asdf or mise are enough. If you need a reproducible environment with system dependencies, Nix is the right choice.
Nix vs Docker
Docker isolates at the container level (processes, filesystem, network). Nix isolates at the package level (in the store). The two are complementary:
- Docker: runtime isolation, deployment, orchestration
- Nix: build isolation, reproducible dependencies, development environments
Nix can even build minimal Docker images without needing Docker during the build.
When to adopt Nix, and when not to
Nix is a good choice if
- You manage development environments shared between several people and want to guarantee they are identical.
- You need several versions of the same tool side by side.
- You want to be able to go back to a previous state after an update that breaks something.
- You build CI/CD pipelines and need reproducibility.
- You are curious and ready to invest time in a durable tool.
Nix is probably not necessary if
- You run a simple server with apt and have never had a reproducibility problem.
- You are looking for a "plug-and-play" tool with no learning curve.
- Your team does not have time to learn a new paradigm.
- You only use Docker containers to isolate your environments and that is enough for you.
Glossary of Nix terms
The Nix ecosystem comes with its own vocabulary, and it is often what puts people off at first. Keep this table at hand: the three terms to anchor first are the store (where everything is stored), the generation (what makes rollback possible) and the flake (the project unit that freezes dependencies), the others make sense once those are understood.
| Term | Definition |
|---|---|
| Store | The /nix/store/ directory where Nix stores every package, each in a folder identified by a unique hash |
| Hash | Fingerprint computed from the sources and dependencies, guarantees uniqueness and reproducibility |
| Profile | Set of symbolic links pointing to the packages you use, your "view" of the store |
| Generation | Numbered snapshot of your profile after each change, enables rollback |
| Channel | Branch of the nixpkgs repository (classic way of managing package sources) |
| Nixpkgs | The main community repository, with more than 100,000 package definitions |
| Flake | Nix project unit with a flake.lock that freezes dependencies (gradually replacing channels) |
| Derivation | The build recipe of a package in the Nix language |
| NixOS | Complete Linux distribution where the whole system is configured by Nix expressions |
| Home Manager | Tool that manages user configuration (dotfiles, shell, applications) declaratively through Nix |
Key points
- Nix is three things: a package manager, a functional language, and a philosophy based on reproducibility.
- Every package is isolated in
/nix/store/with a unique hash, no dependency conflict is possible. - Rollback is native: every change creates a generation, and you can go back instantly.
- Nix coexists with your distribution: it installs on Debian, Ubuntu, Fedora or macOS without breaking anything.
- nixpkgs holds more than 100,000 packages and is one of the largest software repositories in the world.
- The learning curve is real: allow a few days to feel comfortable, a few weeks for the language and flakes.
Knowledge check
Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Install Nix on Linux: single-user and multi-user mode
A new full quiz with random questions
Work again only on the questions you missed