Introducing the Determinate Nix Installer

Installing Nix on non-NixOS is a non-trivial problem that, sadly and by definition, can’t be solved by Nix itself. The official installer for Nix is a Bash script that’s been successfully used countless times in various settings. But we’ve felt for some time that the official installer has shortcomings that make Nix onboarding more challenging than it needs to be. Today we’re excited to announce a bold new solution: the Determinate Nix Installer.

The Determinate Nix Installer is an opinionated alternative to the current install scripts and supports several platforms, including macOS (Intel, ARM), Linux (Intel, ARM), and Windows via WSL2. It also works automatically inside Docker and Podman containers and even supports SteamOS on Valve’s Steam Deck.

The opinionated part is that the Determinate Nix Installer installs Nix with Nix flakes and the unified CLI enabled in nix.conf. Although flakes and the unified CLI remain experimental features of Nix, we’re confident that new users should adopt them now and that more seasoned Nix users should start making the transition.

The Determinate Nix Installer also stores an installation receipt (for uninstalling) at/nix/receipt.json and a copy of the install binary at /nix/nix-installer.

You can give it a try by running the following in a terminal:

curl --proto '=https' --tlsv1.2 -sSf -L | sh -s -- install



The current Nix install scripts do an excellent job but are challenging to maintain. Subtle differences in the shell implementations and specific characteristics of bash scripts make it difficult to make meaningful changes to the installer.

We began discussing a vision for a new installer internally. Later, we saw the installer discussion here on the NixOS Discourse and enthusiastically joined the Nix installer working group.

We take the core tenets of Nix very seriously. True to our name, we want to make software systems as determinate as possible. Making Nix installation robust, seamless, and trivially reversible is a crucial part of that. We wanted to experiment with the idea of an installer in a more structured language and see if this could be a worthwhile alternative. This release is a significant step in that direction.

Above all, we want our installer to work in any environment where Nix can work its magic, including in continuous integration and deployment environments. We provide a GitHub Action for the Determinate Nix Installer but it should be adaptable to any CI system.

So far, our explorations have been fruitful, so we wanted to share what we have and seek broader feedback. We appreciate that it must prove itself in various scenarios and we’re eager to collaborate with the Nix community to build that confidence.

You can read more on the rationale for the Determinate Nix Installer on our blog. We welcome feedback and contributions from the Nix community via the project’s GitHub repository.

We’ve licensed it under the GNU Lesser General Public License v2.1—the same license for Nix itself—which should provide little obstruction to eventually making it the official installer if that’s what the community desires. We’ve also released it as a Rust library that anyone can use.

All that remains is to thank everyone who collaborated on this project and provided feedback to help us get to where we are today.


The asciinema preview doesn’t seem to be linking to asciinema correctly

1 Like

Oops, fixed, thank you!

Why not move that into an argument/env variable/etc and the installer would be unopinionated.

Also I miss in the readme that disabling the sandbox is not fully supported and that all possible issues without it cannot be fixed.


I used this installer on a Chromebook a while ago and it was a nice experience. Thanks for this.


This is awesome :trophy:

I’ve been enjoying Nix + Home Manager on my Fedora Silverblue spins for a few months now (the tandem works quite well), and was waiting for Flakes to “graduate” before allocating time to learn it.

It seems to me that with DNI (?) the time has finally came.


I finally had an opportunity to really give this a go since we’re using Nix flakes to distribute software for a new project at work and we want the path from Nix-less Windows and macOS developer workstations to running the desired software locally to be as simple and reliable as possible.

We’ve still got more exploring and testing to do, and we have run into one small bug on WSL (which I’ll report soon!), but so far I’m really happy with it. Having a low-friction path to a flakes-enabled Nix in WSL and Docker has been super helpful.


I just wanted to say thank you so much for this! Loving everything about this so far. In particular the following have made this easier to onboard workmates onto Nix:

  • Having flakes and nix-command enabled by default removes a step from initial setup.
  • Having a way to provide extra configuration makes it easy to provide a custom substituter for our tooling during installation, rather than having an extra config file editing step.
  • During interactive installation, the concisely presented plan followed by a single confirmation step makes it clear to see what will happen without parsing a ton of verbose output.
  • The non-interactive installation option makes it easy to base other custom tooling on top of Nix.

In general, this tool has made it easy to land a Nix installation with our team’s necessary features and substituter enabled in a single command :ok_hand:

Would love to see this (or something like it) become the default installer some day :pray:


Hey everyone, by way of update: we released our installer and GitHub Action three months ago. I took a look at our diagnostic data, and found that over 90% of our installations on GitHub Actions complete in fewer than 14s:

(as a note on Y axis: we’re sampling the dataset, and the Y axis reflects that. We see thousands of installs every day :).)

If I only look at Nix on macOS in CI, the picture is not as good – most of the installations take 30-50s:

But I’m fairly confident the performance of our installer on macOS on GitHub Actions is going to improve significantly as our 0.9.0 installer rolls out. That introduces the use of auto-uid-allocation, and the performance impact on Linux is stunning, making 100% of installs complete in fewer than 5s:

Anyway, thought that might be interesting to look at. We’re still cautiously and slowly rolling out 0.9.0, and I can take another look at its performance when we’ve gathered more data.