On most Linux distributions, the state of your system is the sum of every command you have ever run on it: packages installed and removed, files edited in /etc, services enabled. Reproducing that machine elsewhere means remembering all of it.

NixOS takes the opposite approach. The entire system is described in configuration files, and the operating system is built from that description. Change the file, rebuild, and the system matches it. Every build is kept, so any previous version is one command, or one boot menu entry, away.

The Nix store

Everything in NixOS rests on the Nix package manager and its store. Packages are not installed into /usr/bin and /usr/lib. Each one lives in its own directory under /nix/store:

/nix/store/9kqz3...-firefox-156.0/
/nix/store/a1b2c...-openssl-3.5.2/
/nix/store/x7y8z...-openssl-3.0.15/

The prefix is a hash of every input used to build the package: its source, its build script, its compiler, and the exact store paths of all its dependencies. Change anything, including a dependency three levels down, and the hash changes, producing a new path.

Several useful properties follow from that one idea:

• Multiple versions coexist. Two versions of OpenSSL, or two builds of the same version with different options, simply have different paths. There is no dependency hell of the kind where two programs need incompatible versions of one library
• Nothing is overwritten. An upgrade builds new paths next to the old ones
• Builds are reproducible. The same inputs produce the same path, and binaries can be fetched from a cache instead of built locally when the hash matches
• Programs find their dependencies by exact path, not by searching /usr/lib, so they cannot accidentally pick up the wrong library

Your PATH and /run/current-system are built from symlinks into the store, which is how the familiar ls and firefox commands still work.

configuration.nix

On NixOS, the system is defined in /etc/nixos/configuration.nix, written in the Nix language:

{ config, pkgs, ... }:
{
  imports = [ ./hardware-configuration.nix ];

  networking.hostName = "dorkbox";
  time.timeZone = "America/Chicago";

  users.users.alice = {
    isNormalUser = true;
    extraGroups = [ "wheel" "networkmanager" ];
  };

  environment.systemPackages = with pkgs; [ git htop ripgrep neovim ];

  services.openssh = {
    enable = true;
    settings.PasswordAuthentication = false;
  };

  networking.firewall.allowedTCPPorts = [ 22 ];

  system.stateVersion = "26.05";
}

That file installs packages, creates a user, enables and configures SSH, and opens the firewall port. The services.openssh.settings block becomes sshd_config; you do not edit files in /etc directly, because NixOS generates them.

Apply it with:

sudo nixos-rebuild switch

Generations and rollback

Every nixos-rebuild switch produces a new generation, a complete snapshot of the system configuration, and adds it to the boot menu.

sudo nixos-rebuild switch --rollback       # go back one generation
sudo nix-env --list-generations --profile /nix/var/nix/profiles/system

If an update breaks booting, choose the previous generation from the boot menu. It is the equivalent of the Btrfs snapshot rollback other distros bolt on, except it is built into how the system works rather than layered on top.

Old generations use disk space until you collect them:

sudo nix-collect-garbage --delete-older-than 14d

Flakes

The traditional setup pulls packages from a channel, a moving pointer to a version of the Nixpkgs repository. That means two machines built from the same configuration a week apart can differ.

Flakes fix that by pinning every input, including Nixpkgs itself, to an exact revision in a flake.lock file. Commit your configuration and lock file to Git, and any machine can rebuild the identical system. Flakes are still formally marked experimental, but a large share of the community uses them, and most current guides assume them.

sudo nixos-rebuild switch --flake .#dorkbox
nix flake update       # move pins forward deliberately

Nix without NixOS

The package manager works on almost any distribution and on macOS. It installs into /nix and does not touch the host’s package manager. The most popular use is per-project development shells:

nix shell nixpkgs#nodejs_22 nixpkgs#postgresql_17
# a shell with exactly those tools, gone when you exit

With a shell.nix or flake.nix in a repository, every contributor gets the same compiler and tool versions, which solves the problem that Distrobox and Toolbox solve with containers.

Home Manager extends the same idea to your user environment, managing dotfiles and user packages declaratively, an alternative to the tools in our dotfiles guide.

The trade-offs

The Nix language is a real learning curve. It is a small, lazy, functional language, and error messages can be hard to read. Most of the learning is not Linux; it is Nix.

The filesystem layout is unusual. Software that assumes /usr/lib or /bin/bash exists, such as downloaded binaries and some installer scripts, will not run as-is. There are workarounds (nix-ld, steam-run, FHS environments), but “download and run” is harder than elsewhere.

Generic Linux guides need translation. An instruction to “edit /etc/ssh/sshd_config” becomes “set the equivalent option in configuration.nix.”

Disk usage is higher, because old generations and multiple versions persist until collected.

In exchange you get atomic upgrades, trivial rollback, a system you can recreate from a Git repository, and one of the largest package collections of any distribution.

Who it is for

NixOS rewards people who manage several machines, want their configuration in version control, or tinker a lot and want a guaranteed way back. It is also popular with developers for reproducible environments.

For a first Linux install, a conventional distribution from our distro guide for beginners is gentler. If rollback safety is what attracts you, the immutable distributions such as Fedora Silverblue offer a similar safety net with less to learn.

Frequently Asked Questions

What makes NixOS different from other distributions?

The whole system, including packages, services, users and settings, is described in configuration files and built by the Nix package manager. Every rebuild creates a new generation, older generations stay bootable, and packages live in isolated paths under /nix/store rather than being mixed together in /usr.

What is the Nix store?

The Nix store is the /nix/store directory where every package lives in its own directory named after a hash of all its inputs. Because the name changes whenever any input changes, many versions of a package can coexist without conflict, and nothing overwrites anything else.

How do I roll back a bad NixOS update?

Run sudo nixos-rebuild switch —rollback to return to the previous generation immediately. If the system will not boot, choose an older generation from the boot menu, since every generation that has not been garbage collected remains a bootable entry.

Are Nix flakes required?

No. Flakes are an optional feature, still marked experimental but very widely used, that pin every input to an exact revision in a lock file. They make a configuration reproducible across machines and time. Traditional channel-based configuration still works.

Can I use Nix without NixOS?

Yes. The Nix package manager installs on almost any Linux distribution and on macOS. It keeps everything under /nix, so it does not interfere with the host package manager, and it is a popular way to get reproducible development environments.

Is NixOS good for beginners?

It is harder to learn than a conventional distribution because you configure everything through the Nix language and many guides written for other distros do not apply directly. Its rollback safety is forgiving, but most people are happier learning Linux on a conventional distro first.