Nix: Reproducible Development Environments (Once You Survive the Learning Curve)

Every developer has lived the same small tragedy. A new colleague clones the repo, follows the README, and nothing works. The wrong version of Node. A missing system library. A make that needs a tool nobody documented because it has been on the lead’s laptop since 2019. Hours vanish. Nix exists to make this entire category of misery go away, and it does, eventually, after putting you through a learning curve that I will not pretend is gentle.

1 What Nix actually is

Nix is a package manager, but describing it that way undersells what makes it strange and powerful. Where apt or brew mutate a shared global state — installing version 18 of something overwrites version 16 — Nix builds every package in isolation and stores it under a hash of its complete dependency graph. Two versions of the same library coexist happily because they live at different paths in the Nix store. Nothing is installed globally in the conventional sense; instead, environments are assembled by linking the exact store paths you asked for.

The consequence is reproducibility that other tools only gesture at. If two people build from the same Nix expression, they get bit-for-bit the same dependency tree, because the inputs are pinned by hash all the way down. “Works on my machine” stops being a defence and starts being a guarantee that extends to everyone else’s machine too.

2 The dev shell, which is the part you want

You do not need to convert your operating system to NixOS or rewrite your build to get value here. The gateway drug is nix develop with a flake. A flake is a single file that pins exactly which version of the entire package set you depend on, and declares what your shell should contain:

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11";

  outputs = { self, nixpkgs }:
    let pkgs = nixpkgs.legacyPackages.x86_64-linux;
    in {
      devShells.x86_64-linux.default = pkgs.mkShell {
        packages = [
          pkgs.nodejs_20
          pkgs.postgresql_15
          pkgs.jq
        ];
      };
    };
}

Commit that flake.nix and its generated flake.lock to the repo. Now anyone who runs nix develop drops into a shell with precisely Node 20, Postgres 15, and jq on their PATH — the same versions, on Linux or macOS, today or in two years. The flake.lock file pins the nixpkgs revision by commit hash, so even “the latest patch of Node 20” is frozen until you choose to update it. There is no global install, no version manager, no contamination of the host. Leave the shell and your system is untouched.

Pair it with direnv and a one-line .envrc containing use flake, and the environment activates automatically the moment you cd into the directory. That combination — flakes plus direnv — is genuinely the closest I have come to development environments that simply work.

3 The part nobody warns you about enough

Now the honesty. The Nix language is a lazy, functional, untyped language that you will fight. Its error messages are notorious; a misplaced semicolon can produce a wall of output that points nowhere useful. The documentation has improved but is scattered across a wiki, a manual, blog posts, and tribal knowledge, and you will frequently find three ways to do something with no clear signal as to which is current. Flakes themselves were experimental for years and still require enabling a feature flag:

mkdir -p ~/.config/nix
echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf

Packaging your own software that does something unusual — a binary that expects libraries at hardcoded paths, say — drags you into Nix’s purity model and the patching it demands. This is where afternoons go to die. The store’s hashed paths that give you reproducibility also break every assumption a normal binary makes about where things live.

4 Is it worth it?

For a solo project on one machine, probably not. The payoff scales with the number of people and machines that have to agree, and a team of one agrees with itself for free.

For a team, or for anyone who maintains more than two or three projects with conflicting toolchains, the calculus flips hard. The reproducible dev shell alone, ignoring everything else Nix can do, has saved me more onboarding pain than any wiki page ever could. New contributors run one command and are productive, which is a small miracle if you have ever written a setup guide.

My advice is to ignore NixOS and the deep end entirely at first. Learn exactly enough to write a flake.nix dev shell for one real project, wire up direnv, and live with it for a month. If it sticks, the rest of the iceberg will still be there. If it doesn’t, you have lost a weekend and gained a genuinely reproducible environment for that one repo, which is not a bad trade for the worst-designed best idea in packaging.