“Works on my machine” isn’t a bug—it’s a business model. It’s what happens when your developer environment is an artisanal snowflake, assembled from shell history, undocumented installs, and whatever your laptop decided to keep. Dev containers help, but they’re still a packaging strategy around an inherently mutable reality. Nix takes the opposite approach: define the world you need, lock it down with cryptographic hashes, and make it reproducible everywhere—from a teammate’s laptop to CI.

If you’ve spent more time debugging environment drift than debugging code, this is the pivot you’ve been looking for.

Why developer environments keep breaking⌗

In most teams, “the dev environment” is a pile of assumptions:

  • The “right” Node or Python version is installed… somewhere.
  • OS-level libraries exist… on some machines.
  • Tooling plugins match… mostly.
  • Your local ~/.config and ~/.cache don’t accidentally influence runtime behavior.
  • Someone’s favorite workaround didn’t get written down, because it “only matters on this one distro.”

Even with Docker, the story doesn’t fully change. Containers give you a clean filesystem and a repeatable filesystem layout, but they often rely on:

  • A base image that drifts over time (even when you “pin” vaguely).
  • Build steps that can introduce nondeterminism (apt repositories, network timing, transitive dependency churn).
  • A “container for dev” that still depends on the developer to pull the right tags, mount volumes correctly, and set env vars.

Net result: you trade one class of pain for another. The real issue is not packaging—it’s declaration and isolation.

Nix flips the model: declare everything, isolate it⌗

Nix is built on a simple, radical premise: the environment should be derived entirely from inputs you declare, not from what happens to exist on a machine.

Instead of “install these things and hope,” Nix treats each dependency—system libraries, language runtimes, compilers, build tools, CLIs—as something that can be represented precisely. Those definitions are versioned and stored in a content-addressed way: when your inputs change, the resulting environment changes too, and Nix knows exactly how.

The crucial part isn’t just that it installs dependencies. It’s that it produces an environment that is:

  • Deterministic: same declared inputs → same environment.
  • Isolated: dependencies don’t leak into each other or rely on global state.
  • Composable: you can build new environments by combining precise pieces.

That’s why Nix feels different. It doesn’t ask developers to follow instructions. It asks them to accept a specification.

Reproducibility with Nix flakes: the “it works in CI” factor⌗

Where teams really feel the pain is the transition from “local works” to “CI passes.” Nix flakes address that by turning your environment definition into a first-class artifact you can reference across machines.

A “flake” is essentially a reproducible bundle: you define inputs (like specific package sources) and outputs (like a dev shell). Then you let Nix resolve and build the exact dependency graph.

Here’s the practical payoff: your CI pipeline can use the same environment definition your developers use locally. That means the question stops being:

  • “Why does CI fail when it works here?”

…and becomes:

  • “Which input changed, and what exactly did it change?”

You can also pin versions tightly. When you upgrade something, you upgrade intentionally, and the diff is real—because Nix computes the new closure from your new inputs.

If you’ve used Docker with “latest” tags or a half-pinned base image, you already understand the temptation that reproducibility battles. Nix makes that temptation less productive.

A concrete workflow: nix develop for instant parity⌗

Let’s say you’re building a service with a Rust backend and a Node-based toolchain (common in modern stacks). In a README-driven world, your setup might be spread across:

  • language version managers (sometimes conflicting),
  • OS package installs for shared libs,
  • global npm installs,
  • special environment variables that “you’ll see in the docs.”

In a Nix world, you specify those requirements once. Then the developer experience becomes boring—in the best way.

A developer runs:

  • nix develop

…and gets a shell with the right Rust toolchain, the Node version you declared, and any system libraries your builds require. No “install this, then reboot, then run this script.” No “wait, you’re on the other minor version.” The environment is built from a dependency graph rather than a set of vibes.

Practical advice for making this stick⌗

If you’re adopting Nix, don’t try to boil the ocean on day one. Start with the highest-friction parts:

  1. Put build tools under Nix first: compiler, language runtime, and core build dependencies.
  2. Then add OS libraries that previously lived in “install on Ubuntu/Debian” instructions.
  3. Finally add dev conveniences (formatters, linters, test runners, CLIs).

This incremental approach matters because teams often resist the learning curve when they don’t see immediate benefits. Your first win should be: “I can stop explaining setup.”

Dev containers aren’t wrong—but they’re incomplete⌗

Dev containers are a good idea: they make the environment portable and reduce host-specific differences. But they tend to be procedural. You write steps; the result depends on the state of registries, network availability, and how carefully you pin versions.

Even when you’re disciplined, you still get friction:

  • Rebuilding images for small changes can be slow.
  • Updating base images can introduce subtle drift.
  • You can end up with two sources of truth: the Dockerfile and the README, or the Dockerfile and your CI scripts.

Nix doesn’t eliminate every form of overhead—nothing eliminates all cost in software. But it targets the real defect: “the environment isn’t defined as a pure function of inputs.”

In other words, Docker can help you ship a known filesystem. Nix aims to ship a known world.

And once you’ve experienced a nix develop that consistently lands you in the right environment, the “works on my machine” genre starts to look like legacy software.

The learning curve: steep, but worth designing around⌗

Nix has a reputation for being difficult, and that’s not entirely unfair. You’re stepping into a new way of thinking:

  • Instead of installing things globally, you define them.
  • Instead of relying on mutable state, you embrace immutability and composition.
  • Instead of a linear “do these commands,” you specify a graph.

But the learning curve softens fast if you treat Nix like infrastructure, not like magic. A few strategies that work in real teams:

  • Template your flake outputs: standardize a “dev shell” pattern and reuse it across repos.
  • Document the interface, not every internal detail: developers shouldn’t need to memorize the whole Nix language to run the shell.
  • Make upgrades explicit: when you bump a dependency, it should be obvious which input changed.
  • Keep your scope tight: define exactly what the build and dev tooling needs, no more.

If you do this right, developers mostly interact with a stable command set, not a novel programming language.

And yes—initial setup will feel awkward. But awkwardness tends to fade when the payoff is immediate: fewer environment bugs, faster onboarding, and fewer CI “surprises.”

Conclusion: reproducibility is a feature, not a ritual⌗

Reproducible development environments aren’t a luxury for elite teams—they’re a foundation for velocity. Dev containers reduce drift, but Nix tackles the root cause: environments should be derived from declared inputs and isolated with cryptographic precision.

Once your team stops treating setup as tribal knowledge and starts treating it as a versioned artifact, the entire development workflow tightens. nix develop becomes less like a tool and more like a contract: the environment you run locally is the one you build, test, and deploy against.

That’s the future—because it’s the only future where “works on my machine” stops being a recurring headline.