Nix is a package manager that runs on any Linux distribution and on macOS. Unlike APT, DNF or Pacman, every package is isolated in /nix/store/ with its exact dependencies, so two versions of Python or OpenSSL coexist without conflict. Every change creates a reversible snapshot, and a single declarative file is enough to reproduce an identical environment on any machine. This section covers 12 progressive guides, from a first look at the ecosystem to flakes and DevOps use cases.
What this section covers
The twelve guides follow each other in the order of the table, from a first contact with the ecosystem to flakes and team usage. The Level column gives the expected background: the first four guides assume no knowledge of Nix, the last three assume you have written your first Nix expressions.
| # | Guide | What you learn there | Level |
|---|---|---|---|
| 1 | Understand the Nix ecosystem | Where Nix fits, its three facets (manager, language, philosophy), comparison with apt, Docker and asdf | Beginner |
| 2 | Install Nix on Linux | Single-user or multi-user, Determinate Installer, enabling the modern commands and flakes | Beginner |
| 3 | Store, profiles and generations | How Nix stores, isolates and versions every package; rollback and garbage collection | Beginner |
| 4 | Modern commands: shell, profile, search, run | nix search, nix shell, nix run, nix profile: the main path for managing your packages | Beginner / Intermediate |
| 5 | Classic commands: nix-env, nix-shell, nix-build | nix-env, nix-shell, nix-build, nix-channel: understanding existing setups and legacy code | Intermediate |
| 6 | Nix language basics | Types, functions, attrsets, let-in, with, inherit: what you need to read and write Nix | Intermediate |
| 7 | Write a first NixOS configuration | configuration.nix, packages, services, users, nixos-rebuild switch, first modularisation | Intermediate |
| 8 | Reproducible development environments | mkShell, Python withPackages, Node.js, Rust, shellHook, direnv | Intermediate |
| 9 | Import, factoring and pinning | Modularise your Nix files, freeze nixpkgs with fetchTarball, multi-file structure | Intermediate / Advanced |
| 10 | Understand and use flakes | flake.nix, inputs, outputs, flake.lock, nix develop, nix build, migrating from shell.nix | Advanced |
| 11 | DevOps use cases | Team devShell, GitHub Actions and GitLab CI pipelines, nix flake check, updating flake.lock | Advanced |
| 12 | NixOS: install and evaluate a first system in a KVM VM (in French) | From Nix to NixOS: declarative system, flakes, disko and a first configuration in a KVM VM | Advanced |
Why Nix
Managing packages with traditional tools raises problems that every administrator and developer ends up meeting. Nix solves them structurally:
| Common problem | With apt / dnf | With Nix |
|---|---|---|
| Two projects require different Python versions | Conflict, a single system version | Native coexistence in /nix/store/ |
| An update breaks a production service | Rollback impossible or risky | Back to the previous generation in one command |
| "It works on my machine" | Versions depend on the installation history | Same declarative file = same result everywhere |
| Trying a tool without polluting the system | Manual installation + cleanup | nix shell nixpkgs#tool, nothing remains afterwards |
| Reproducing a CI environment identical to the dev workstation | Fragile installation scripts | flake.lock locks every dependency |
The key concept: Nix computes a cryptographic hash from everything that goes into building a package (sources, dependencies, compiler, options), before building anything. The same inputs therefore give the same store path on every machine, which lets the binary cache serve the already built package. A result identical to the byte is the goal and the most frequent case, not an absolute guarantee: a build that embeds a date or a random order can still vary.
Who this training is for
These guides are designed for:
- System administrators who want reproducible environments, reliable rollback and clean management of several versions of the same tool.
- DevOps engineers and SREs who want to standardise development environments, make CI/CD pipelines reliable and distribute consistent tooling to the whole team.
- Developers who spend time setting up Python, Node.js or Rust on every machine instead of coding.
Prerequisites: be comfortable with the Linux command line and with basic system administration (environment variables, PATH, package management). No prior knowledge of Nix is needed, the first guide starts from scratch.
Recommended path
Path A, Discovery: follow guides 1 to 4 in order. You will understand the ecosystem, know how to install Nix, find your way around the store and use the modern commands day to day. Allow about 2 hours.
Path B, System configuration and environments: after path A, continue with guides 6 (language), 7 (NixOS configuration) and 8 (development environments). You will know how to declare a complete NixOS system and create reproducible shell.nix files for your projects. Allow 3 to 4 more hours.
Path C, Flakes and production: add guides 9 (factoring), 10 (flakes) and 11 (DevOps use cases) to modularise your configuration, lock dependencies with flake.lock and integrate Nix into your CI/CD. This path assumes a good grasp of the previous guides.
The key concepts of Nix
Nix introduces its own vocabulary, which is worth knowing before diving into the guides:
| Concept | Role |
|---|---|
Store (/nix/store/) | Directory where each package is stored with its dependencies, identified by a unique hash. Nothing is modified in place, every version coexists. |
| Profile | Set of symbolic links pointing to the active packages. Your PATH points to the profile, not directly to the store. |
| Generation | Snapshot of your profile at a given moment. Every installation or removal creates a new generation. Rollback restores a previous generation. |
| Nixpkgs | The main Nix package repository, more than 100,000 packages, the largest package repository in the world. |
| Derivation | The "build recipe" of a package: sources, dependencies, build steps, all hashed to guarantee reproducibility. |
| Flake | Composition unit with locked inputs (flake.lock). Replaces channels for reproducibility guaranteed across machines. |
| Channel | Classic method (pre-flakes) for pointing to a nixpkgs branch. Still used but gradually replaced by flakes. |
Common Nix pitfalls
The six pitfalls below catch almost every beginner. None of them breaks the machine, but each one wastes time: a store that grows forever, a profile that has become unreadable, a flake that rejects a file that is nonetheless there. The last column points to the guide that covers the fix in detail.
| Pitfall | Impact | Fix |
|---|---|---|
Mixing nix-env and nix profile | Corrupted profiles, invisible packages | Pick a single mode, preferably nix profile (guide 4) |
| Never running the garbage collector | /nix/store/ grows indefinitely (50 GB+ easily) | Schedule nix profile wipe-history then nix store gc (guide 3) |
Forgetting git add with flakes | nix develop does not see untracked files | Always git add before nix build or nix develop (guide 10) |
Using <nixpkgs> without freezing the version | Different results depending on the machine and the channel | Pin with fetchTarball (guide 9) or move to flakes (guide 10) |
Copying a shell.nix without understanding the language | Impossible to diagnose or adapt | Learn the basics of the Nix language (guide 6) |
Ignoring nix flake check in CI | Structure errors not detected | Add nix flake check to the pipeline (guide 10) |
Key points
- Nix isolates every package in
/nix/store/with a unique hash, no "dependency hell". - Profiles and generations allow an instant rollback after any change.
- The modern commands (
nix shell,nix develop,nix build) are gradually replacing the classic ones (nix-env,nix-shell). - The Nix language is functional and declarative: you describe the desired state, Nix works out how to get there.
- Flakes lock dependencies with
flake.lockfor reproducibility guaranteed across machines. - Nixpkgs holds more than 100,000 packages, the largest package repository in the world.