Overview

Nix takes a radically different approach to package management: every package is built from source with all inputs hashed, and packages with different inputs get different store paths (/nix/store/hash-name-version). This means no conflicts, full reproducibility, and atomic rollbacks. Increasingly popular among teams that need identical dev environments across Linux and macOS.

Installation

# Multi-user install (recommended)
sh <(curl -L https://nixos.org/nix/install) --daemon

# Enable flakes (modern Nix)
echo 'experimental-features = nix-command flakes' >> ~/.config/nix/nix.conf

Dev Shells with Flakes

The modern way to define per-project environments:

# flake.nix
{
  description = "Node.js development environment";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
      in {
        devShells.default = pkgs.mkShell {
          buildInputs = with pkgs; [
            nodejs_20
            nodePackages.pnpm
            postgresql_16
            redis
            awscli2
          ];

          shellHook = ''
            echo "Dev environment loaded"
            export DATABASE_URL="postgresql://localhost/myapp_dev"
          '';
        };
      }
    );
}

# Enter the dev shell
nix develop

# Or with direnv (auto-activate on cd)
echo "use flake" > .envrc
direnv allow

Running Tools Without Installing

# Run a tool without permanently installing it
nix run nixpkgs#cowsay -- "Hello Nix"

# Open a temporary shell with tools
nix shell nixpkgs#httpie nixpkgs#jq

# Try a new Node version without switching your default
nix run nixpkgs#nodejs_22 -- --version

Home Manager (User Config)

Manage your dotfiles and user packages with Nix:

# ~/.config/home-manager/home.nix
{ config, pkgs, ... }: {
  home.packages = with pkgs; [
    ripgrep
    fd
    bat
    lazygit
    gh
  ];

  programs.git = {
    enable = true;
    userName = "Your Name";
    userEmail = "[email protected]";
    extraConfig.init.defaultBranch = "main";
  };

  programs.zsh = {
    enable = true;
    autosuggestion.enable = true;
  };
}

Nix vs Other Env Managers

Concrete Use Case: Cross-OS Reproducible Dev Environment

Imagine two developers working on the same project — one on macOS, one on Ubuntu. They need identical versions of Python 3.12, Node.js 22, PostgreSQL 16, and a specific AWS CLI version. Without Nix, the macOS developer might get a slightly different Python patch version or PostgreSQL path, leading to “works on my machine” bugs.

The problem solved by Nix + direnv:

# flake.nix
{
  description = "Python + Node monorepo";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
      in {
        devShells.default = pkgs.mkShell {
          buildInputs = with pkgs; [
            python312
            python312Packages.pip
            python312Packages.venv
            nodejs_22
            nodePackages.pnpm
            postgresql_16
            redis
            awscli2
            git
            curl
          ];

          # Set environment variables automatically
          env = {
            PYTHON_VERSION = "3.12";
            NODE_VERSION = "22";
            DATABASE_URL = "postgresql://localhost/myapp_dev";
            AWS_REGION = "us-east-1";
          };

          shellHook = ''
            echo "🐚  Dev environment ready (Python $PYTHON_VERSION, Node $NODE_VERSION)"
            # Auto-create venv if it doesn't exist
            if [ ! -d ".venv" ]; then
              ${pkgs.python312}/bin/python -m venv .venv
              echo "📦  Created virtualenv"
            fi
            # Activate venv (Nix-provided python)
            source .venv/bin/activate
          '';
        };
      }
    );
}

# .envrc (enable auto-activation on cd)
use flake

# direnv blocklist to prevent accidental system-wide python
watch python python3 .venv

How it works in practice:

# Developer A (macOS) clones the repo
git clone https://github.com/team/project.git
cd project
direnv allow
# Output: 🐚  Dev environment ready (Python 3.12, Node 22)
# python --version → 3.12.4
# node --version → 22.14.0
# pnpm --version → 9.x.x

# Developer B (Ubuntu) clones the same repo
git clone https://github.com/team/project.git
cd project
direnv allow
# Output: 🐚  Dev environment ready (Python 3.12, Node 22)
# python --version → 3.12.4  (identical!)
# node --version → 22.14.0  (identical!)
# pnpm --version → 9.x.x    (identical!)

The flake.lock file is committed to version control. When either developer runs nix flake update, everyone gets the same locked versions. No more “works on my machine” — the environment IS the lock file.

Sharing the lock across the team:

# Commit flake.lock
git add flake.lock
git commit -m "chore: pin dev environment"

# Teammate pulls and updates
git pull
nix flake update  # Only if intentionally upgrading
nix develop      # Gets exact same environment

Nix vs Docker vs devcontainer

	Nix	Docker	devcontainer
Reproducibility	Perfect (content-addressed store)	Near-perfect (image hashes)	Good (Dockerfile + settings.json)
Startup time	Instant (no daemon needed)	5-30s (container cold start)	10-60s (Dev Container opens in IDE)
Host system impact	Zero (tools live in /nix/store only)	Isolated but Docker daemon runs	Depends on Dockerfile
IDE integration	Native (VS Code Remote-Nix, direnv)	VS Code Dev Containers extension	Native (VS Code Dev Containers)
Resource usage	Low (no container overhead)	Moderate (running daemon + containers)	High (full Docker container)
Cross-OS (Linux/macOS)	✅ Full support	✅ Full support	⚠️ Limited (Docker Desktop required on macOS)
Multiple project versions	✅ Side-by-side, no conflicts	✅ Isolated per container	⚠️ Per Dev Container
Rollback	✅ `nix --roll-back`	✅ `docker run <old-image>`	⚠️ Rebuild from Dockerfile
CI/CD parity with dev	✅ Same environment in CI via `nix develop`	✅ Same Dockerfile	⚠️ Dev Container configs vary
Language-level isolation	✅ pkgs.python312, pkgs.python311	✅ Per container	⚠️ System python + venv
Learning curve	Very high	Medium	Low
Binary cache	cachix.org (community + org-specific)	Docker Hub, GHCR	Same as Docker
When to choose it	Reproducible dev envs + config management	Full containerization, microservices	Quick team onboarding in VS Code

Summary of the comparison:

Nix is the strongest for environment reproducibility (content-addressed hashing means no “but the image was rebuilt” surprises), but requires learning the Nix language.
Docker provides stronger process isolation and is the standard for production deployment parity, but adds daemon overhead and macOS performance penalties.
devcontainer is the easiest for teams already in VS Code, but relies on Docker under the hood and the configuration can drift from CI if not carefully managed.

When to Use Nix / When Not to Use Nix

When to use Nix:

Team dev environment consistency is critical. If your team ships bugs because someone has Python 3.11 and someone else has 3.12, Nix eliminates that entire class of problems. Commit flake.lock and every machine is bit-for-bit identical.
You need multiple versions of the same tool side-by-side. Running Python 2 and Python 3, Node 18 and Node 22, PostgreSQL 14 and 16 simultaneously — Nix handles this with zero conflicts because every package lives at a unique hash path.
You practice infrastructure as code. NixOS declaratively defines your entire server OS in a Nix file. Spin up identical machines on any cloud provider.
You want atomic rollbacks. Deploy to production, discover a problem 10 minutes later, roll back to the previous generation in one command. No need to remember how to downgrade.
You want Home Manager for dotfiles. Manage your .gitconfig, shell config, editor plugins, and user packages across machines with the same rigor as your production infrastructure.

When NOT to use Nix:

You need a quick one-off environment. spinning up a Docker container is faster to understand and explain to a newcomer than writing a flake.nix.
Your team is non-technical or resistant to tooling investment. The learning curve is real — expect 2-4 weeks before a new developer is comfortable. If your team can’t invest that time, use Docker Compose or devcontainer instead.
You rely heavily on IDE plugins that expect system binaries. Some VS Code extensions (especially language servers that expect to find python or node on the PATH) work better with direnv integration than others. Check compatibility before committing.
Binary cache misses are unacceptable. If your Nix code needs to compile packages from source (rare, but happens with uncommon platforms or custom patches), build times can stretch to hours. Use cachix or configure Cloudflare’s binary cache to mitigate.
You need production-grade container orchestration. Nix is not a container runtime. For Kubernetes, Docker Swarm, or similar, use Docker/Podman. Nix can build your containers but doesn’t orchestrate them.

	Nix	Docker	mise/asdf	homebrew
Reproducibility	Perfect	Near-perfect	Version-level	Low
Language isolation	✅	✅	✅	❌
Rollback	✅	✅	❌	❌
Learning curve	Very high	Medium	Low	Very low
macOS support	✅	✅	✅	✅

Nix — Reproducible Builds & Declarative System Configuration

✅ Pros

⚠️ Cons