The Nix moment

A few weeks ago, GitHub announced that Dependabot now supports Nix. Add a nix entry to your dependabot.yml configuration file and Dependabot will begin updating your flake dependencies automatically. We at Determinate Systems built update-flake-lock for this a few years ago because nothing like it existed, and now GitHub itself has come out of the woodwork to provide effectively the same once-rather-niche functionality.

To people outside the Nix community, this may seem like a fairly standard feature update. But I see it instead as crucial validation for the Nix ecosystem and a clear signal that Nix has become mainstream tooling.

This development has prompted me to reflect a bit on why Nix is reaching this inflection point and what kind of future this all points to. Spoiler alert: it’s an extremely promising one.

The convergence

What I see happening right now is a convergence of trends conspiring to make Nix the tool for our current paradigm. It has a lot to do with AI but factors like adoption, supply chain security, and hardware can’t be overlooked.

Nix code is becoming cheap to write

AI-backed platforms like Claude, ChatGPT, and Replit have changed how engineers learn and use tools. Unlike even a year ago, Nix is now a “promptable” rather than a “learn-it-all-up-front” tool, which has dramatically reduced the friction of onboarding and everyday use.

This is a pivotal development because I have to admit: even as a long-time Nix advocate, I certainly haven’t loved every moment I’ve spent writing Nix expressions. I’ve more than tolerated writing Nix because of the superpowers it’s given me, but it took a good bit of effort to get comfortable with it.

Fast forward to now. Most models I’ve used are quite capable of authoring flakes and even much more complex bits of Nix logic from scratch. I may need to tweak a few things or tell the LLM to modify this or that bit, but I’m never blocked or bogged down That winding path that I took to learning the Nix language? Future users of Nix will be able to bypass it.

Even better, because of the determinate nature of how Nix works—both the language and derivations—you pretty much always get a straightforward Boolean, yes-or-no answer to the “did it work?” question. Operations like nix build, nix eval, and nix flake check either totally succeed or totally fail. Just wild that a tool that’s over 20 years old ended up providing exactly the kind of brisk, clear-cut feedback cycles that are optimal for LLMs.

Complexity and supply chain risk are skyrocketing

The sheer number of software projects and repositories and pull requests and everything else is now exploding in our industry due to the rise of agentic AI. This is an exciting development but it comes with the downside that dependency graphs are becoming murky in alarming ways. It’s now so cheap to write libraries, modules, tools, and even whole frameworks that provenance is a more pressing problem than ever before.

I see Nix as uniquely well poised to tackle this problem not by accident but by virtue of its core design. Unlike virtually all build tools, Nix sandboxes your builds and forces you to explicitly declare the entire graph of dependencies across languages and toolchains. These dependency graphs are called closures in Nix parlance and they can encompass both how an artifact is built and, optionally, what comes along with it at runtime.

And because Nix always “thinks” in terms of closures, everything is completely introspectable. Point it at a package and it shows you the build instructions for that derivation (and for any derivations inside that derivation, and so on ad infinitum). Need to fetch something from a random URL? You can, but at the price that you need to specify a hash for it, and if the contents behind that URL ever change, the build fails.

Nix essentially counters mushrooming dependency graphs with top-to-bottom transparency. It doesn’t make software supply chains invulnerable, of course, but it gives you a far tighter grip on the problem than any other major tool does.

Big name adoption

For the first 20 or so years of its existence, Nix had a toehold mostly amongst smaller companies staffed by forward-thinking engineers. Most of those companies are still happily using it but their ranks have swelled to include household names like Shopify, Anthropic, Google, and Replit.

This is encouraging because it means more resources and attention for Nix, but I also think that it’s shifting the whole perception. If Fortune 500 and even Fortune 50 companies are investing in Nix then it really isn’t a plucky upstart anymore. It’s now an established option and on its way to becoming, dare I say, a safe one, and it’s possible that we’ve already crossed the famous chasm in the technology adoption curve.

Hardware is back

For a long while it felt like the world of hardware had been winnowed down to cloud servers, laptops, and mobile devices. This has really shifted in recent years with an explosion in edge devices, robotics, defense systems, and autonomous vehicles, largely driven by new GPUs from companies like NVIDIA and mobile/edge chips from companies like Qualcomm.

Integrating software and hardware is famously difficult, and it’s made even harder when operating systems and build tools are unpredictable and imprecise (see: widely used Linux distributions using Bash scripts as a “build tool”). But people have quietly been using Nix to integrate software and hardware into a cohesive unit in flight simulators, weapons systems, submarines, and other machinery for over a decade. Most of these systems are running NixOS, but some are already using a more minimal platform from Determinate Systems called Minnows, which I’ll say more about below.

As with the supply chain, I firmly believe that Nix is in a unique position to support ever more software on an ever-expanding array of chips and boards.

Where the path leads from here

When I consider all of these trends together, GitHub’s validation of Nix as mainstream software delights me but it doesn’t surprise me. The rapid growth in software, hardware, and generated code are creating pains that Nix feels purpose-built to solve down to its fundaments: pinned Nix inputs with flakes, sandboxed builds, deterministic evaluation and realisation. These building blocks weren’t built with the AI era in mind but gosh, it sure almost feels like it.

Other tools pull off some of these things for a particular language (uv for Python comes to mind) but only Nix unifies all of this and eliminates the “works on my machine” problem across languages, tools, and platforms (we had a lot to say about the “works on my machine” problem in our most recent webinar). Nix has always been a potential strategic differentiator and now it’s becoming a real one.

My prediction is that Nix’s foothold in our industry is set to expand exponentially. The dramatically reduced cognitive costs of using both Nix the language and Nix the tool due to LLMs will spur tons of organizations to try out Nix in a careful, exploratory capacity. Not all of them will take the plunge, at least at first, but more and more of them will over time when they see what Nix is doing for their competitors’ engineering orgs. And at some point we’ll experience the next major “Nix moment” when Nix becomes like Git, where if you’re not using it, people will wonder which Nix-shaped thing your org is using instead.

The role of Determinate Systems

GitHub’s announcement has me buzzing with excitement for the future. And to put it mildly, I am thrilled that we at Determinate Systems are leading the charge. We’ve known in our gut that this time would come, but even we couldn’t have anticipated just how fundamentally right Nix would end up being.

The work of the Nix community, in the form of upstream Nix and related projects like Nixpkgs and NixOS, has of course been beyond foundational in making Nix the right tool—and paradigm—for this moment. But what that foundation still needs is a thick layer of unification and vision. And that’s precisely what we’re doing at Determinate Systems:

• In the domain of hardware, we’re working on a fresh new framework for building lean, secure, production-ready Linux systems using Nix. It’s called Minnows (I mentioned it in passing above) and it’s a clean break from NixOS specifically geared toward the expanding world of hardware.
• For the supply chain, we recently announced Determinate Secure Packages, a variant of Nixpkgs with continuous monitoring for CVEs, explicit SLAs for vulnerability patching, support for FIPS, and much more. We’re also working on related a tool called FlakeBOM that enables you to generate SBOMs in CycloneDX format for all of the outputs of a Nix flake.
• Determinate Nix, our downstream distribution of Nix, is built for large organizations with demanding security and compliance requirements.

I encourage you to check out our work, but I think my point stands even without it: the situation is ripe with possibilities and the Nix moment is truly upon us.