# Determinate Nix Installer: a Rust installer that plans, applies and reverses a Nix install

> Determinate Nix Installer replaces the upstream shell script with a Rust binary that builds a plan before it touches your system, and can uninstall what it created. Here is how the planners work, how to install it, and where it stops being the right tool.

**DeterminateSystems/nix-installer** — Install Nix and flakes with the fast and reliable Determinate Nix Installer, with over 7 million installs.

- Repository: https://github.com/DeterminateSystems/nix-installer
- Website: https://determinate.systems
- Stars: 3,704 · Forks: 104
- Language: Rust
- License: LGPL-2.1
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/determinatesystems-nix-installer

## The problem: installing Nix without a shell script you cannot undo

The upstream way to install Nix is a shell script that inspects the machine and performs whatever steps it decides are needed. Determinate Nix Installer takes a different route. It is a Rust program, published as the nix-installer crate, that separates the decision from the action. A planner inspects the environment and produces a plan; the installer then executes that plan. The README states that the installer works across macOS, Linux, Windows Subsystem for Linux (WSL), SELinux and the Valve Steam Deck, and that it supports uninstalling Nix. That last point is the one that changes daily practice. If you have ever tried to remove a Nix installation that was created by a script, you know the answer is usually a manual sweep of /nix, profile files and daemon units. Here the README gives a single command: /nix/nix-installer uninstall. The audience is therefore not only newcomers. It is also CI engineers who install Nix on ephemeral runners and want the install to be a step they can reason about, and platform teams on Fedora Silverblue, SteamOS or WSL2 where the standard script has historically needed special handling.

## Planners, plans and the --init decision

The architecture visible in the repository is small and legible. src/ holds the Rust implementation, tests/ holds the test suite, and the binary is named nix-installer. The README explains the model directly: the installer installs Nix by following a plan made by a planner. Planners are selected by platform, so there is a linux planner and others, and each planner has its own options and defaults that mostly overlap. You can list them with /nix/nix-installer install --help and inspect one with /nix/nix-installer install linux --help. The option that matters most in practice is --init. On a normal Linux host the planner uses systemd, which gives you a multi-user installation. In a Docker container, a GitLab CI runner or a WSL2 instance without an init, you pass --init none, and the README is explicit about the consequence: only root, or users who can gain root privileges, can run Nix. That is a real fork in the road, not a detail. It decides whether your build user can call nix directly or has to go through sudo -i. Options can be supplied as command arguments or as environment variables, which is what makes the same installer usable from a shell pipeline and from a script. The README shows NIX_BUILD_GROUP_NAME and --nix-build-group-id as an example of that pairing. Because the plan is produced before execution, the tool can also be inspected and tested without running it, which is why the repository carries a tests/ directory alongside the source.

## Installing Determinate Nix and running a first build

The README gives a one-liner for just about any supported system. It downloads the installer and passes install as the subcommand. On macOS the README notes a separate macOS package that uses this installer behind the scenes and provides a graphical interface, so the command below is the path for Linux, WSL2 and anyone who prefers the terminal.

```bash
curl -fsSL https://install.determinate.systems/nix | sh -s -- install
```

By default this installs Determinate Nix, which the README describes as enabling flakes. Once it finishes, the installer is at /nix/nix-installer, and that is the path you use for later operations. To see which planners your platform offers and what options they take, run the help subcommand:

```bash
/nix/nix-installer install --help
/nix/nix-installer install linux --help
```

When you need to change a planner default, the README shows both forms. The environment variable is read by the installer, and the flag overrides or supplies the same value on the command line:

```bash
curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | \
  NIX_BUILD_GROUP_NAME=nixbuilder sh -s -- install --nix-build-group-id 4000
```

The README also documents the GitLab case, where runners are typically Docker based and run as root, so systemd is absent. There the install line adds --init none and --no-confirm, and the profile script is sourced before nix is used:

```yaml
test:
  script:
    - curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install linux --no-confirm --init none
    - . /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh
    - nix run nixpkgs#hello
    - nix profile add nixpkgs#hello
    - hello
```

If you are on GitHub Actions instead, the README points at determinate-nix-action. The action is tagged for every Determinate release, so DeterminateSystems/determinate-nix-action@v3.5.2 installs Determinate Nix v3.5.2, while the major-version tag tracks the newest release in that series:

```yaml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: DeterminateSystems/determinate-nix-action@v3
      - name: Run `nix build`
        run: nix build .
```

## Where the installer is the wrong tool

The clearest limitation is stated by the project itself. The README says you can use Determinate Nix Installer to install upstream Nix if you wish, but that this is not a supported configuration. If your requirement is a supported upstream Nix installation, this is not the tool for it. The second constraint follows from --init none. Containers and init-less environments are supported, but the README warns that under --init none only root or users who can gain root privileges can run Nix, and it illustrates the point with sudo -i nix run nixpkgs#hello. A Docker image where a non-root build user runs nix is therefore not what this configuration gives you. The Docker row of the platform table lists no multi-user support at all, only root. The third constraint is about flakes in containers. The README warns that if you want to add a flake.nix you must first declare a working directory such as /src in your Dockerfile, because you cannot lock a flake in a directory that does not exist. That is a Dockerfile ordering problem, not an installer bug, but it catches people who copy a flake into an image and expect nix flake lock to succeed. Finally, uninstalling is a command, not a guarantee: the README documents /nix/nix-installer uninstall, and the README does not document rollback for a partially applied plan, so the safe assumption is that a failed install is diagnosed through the troubleshooting guide in docs/troubleshooting.md rather than reversed automatically.

## How it differs from the upstream shell script and from nix-installer-action

The comparison that matters is with the upstream Nix install script. Both end with Nix on the machine. The difference is the sequence. The upstream script decides and acts in the same pass, which makes it short to read and hard to review in advance. Determinate Nix Installer produces a plan first, exposes the planner options as flags and environment variables, and ships an uninstall path. That plan step is also why the tool can support macOS upgrades, which the README lists as a feature: the installer knows what it placed where, so an OS upgrade does not orphan the installation. The second comparison is with determinate-nix-action, which is not really a competitor. It is the packaging of this installer for GitHub Actions, tagged per Determinate release. If you are already on Actions, the action is the shorter path; the installer binary is what you reach for on a workstation, a GitLab runner or a container image. The third comparison is between the two Nix distributions this tool can place on disk. Installing Determinate Nix is the default and the supported path, and it enables flakes. Installing upstream Nix through the same binary is possible but unsupported, which means you get the installer's plan and uninstall mechanics without the vendor's backing for the resulting system.

## Licence, upgrades and the cost of staying current

The crate metadata in Cargo.toml declares license = "LGPL-2.1", and the repository carries a LICENSE file at the top level. LGPL is not the same as a permissive licence: if you embed or link the nix-installer crate into your own program, the terms that apply to that combination are a question for your own legal review, not something this article can settle. Using the binary to install Nix on your machines is a different situation from redistributing a modified installer. On upgrades, the README gives two routes. If you installed Determinate Nix, you upgrade it with sudo determinate-nixd upgrade. The alternative is to uninstall and reinstall with a different version of the installer. The version cadence is visible in the release history: v3.22.5, v3.22.4 and v3.22.3 all landed in September 2026, and the last push to the repository was on 2026-09-20, so the project is moving quickly. That pace has a cost for anyone pinning it. On GitHub Actions the action's tags absorb it, since a specific tag such as DeterminateSystems/determinate-nix-action@v3.5.2 pins the Determinate Nix version. For a curl pipeline you have to pin the installer version yourself, and the README does not describe a versioned URL for install.determinate.systems/nix. That is the gap to plan around if reproducibility matters to you.

## Conclusion

Adopt it if you want a Nix install that can be reviewed before it runs and reversed afterwards, and if you are on Linux, macOS, WSL2 or a container where systemd or --init none matches your environment. Do not adopt it if you need a supported upstream Nix configuration, since the README calls that unsupported, or if you need multi-user Nix inside a Docker container, where only root works. Before rolling it out, read the planner output of /nix/nix-installer install --help for your platform and confirm whether your environment has an init, because that single choice decides whether ordinary users can run nix at all.

## FAQ

### How do I install Nix with Determinate Nix Installer?

The README gives a one-liner: curl -fsSL https://install.determinate.systems/nix | sh -s -- install. By default it installs Determinate Nix, which enables flakes. On macOS the README points to a separate package that uses the installer behind the scenes with a graphical interface.

### What is Determinate Nix Installer used for?

It installs Determinate Nix by following a plan produced by a platform-specific planner, and it can uninstall what it created. The README lists macOS, Linux, WSL2, SELinux, the Valve Steam Deck and Docker or Podman containers among the supported environments.

### Can I run Nix on Windows with Determinate Nix Installer?

The README lists Windows Subsystem for Linux 2 on x86_64 and aarch64 as a stable platform, with multi-user support via systemd. Native Windows is not in the platform table; the supported path is WSL2. Where no init is present, you pass --init none and only root can run Nix.

## Sources

- [DeterminateSystems/nix-installer on GitHub](https://github.com/DeterminateSystems/nix-installer)
- [License: LGPL-2.1](https://github.com/DeterminateSystems/nix-installer/blob/main/LICENSE)
- [Project website](https://determinate.systems)
- [README](https://github.com/DeterminateSystems/nix-installer/blob/main/README.md)
- [Releases](https://github.com/DeterminateSystems/nix-installer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/determinatesystems-nix-installer