Ein neuer Entwickler fängt am Montag an. Bis sein Laptop das Projekt bauen kann, vergeht der halbe Dienstag: die richtige Node-Version, eine bestimmte PostgreSQL-Version für die Tests, ein Kommandozeilenwerkzeug, das nur in Version 1.4 funktioniert, und eine Umgebungsvariable, die niemand dokumentiert hat. Auf dem Testserver läuft dasselbe Projekt aus anderen Gründen nicht. Dass Software auf dem einen Rechner läuft und auf dem anderen nicht, ist in vielen Teams ein Dauerwitz mit ernstem Hintergrund.

Nix setzt genau hier an. Der Paketmanager behandelt Software wie das Ergebnis einer mathematischen Funktion: Gleiche Zutaten ergeben das gleiche Ergebnis, auf jedem Rechner. Darauf aufbauend beschreibt die Linux-Distribution NixOS ein komplettes Betriebssystem in einer Textdatei. Das Konzept ist über zwanzig Jahre alt, hat aber erst in den vergangenen Jahren breitere Aufmerksamkeit gefunden. Es löst echte Probleme und verlangt dafür ein Umdenken, das nicht jedem Team leichtfällt.

Was Nix ist und woher es kommt

Der Name Nix steht für drei Dinge, was Einsteiger regelmäßig verwirrt:

• Nix, der Paketmanager: Er installiert und baut Software. Er läuft auf praktisch jeder Linux-Distribution und auf macOS, unter Windows über das Windows-Subsystem für Linux (WSL).
• Nix, die Sprache: Eine kleine funktionale Programmiersprache, in der Pakete und Konfigurationen beschrieben werden. Funktional heißt: Ausdrücke berechnen Werte, statt Schritt für Schritt etwas zu verändern.
• Nixpkgs: Die zentrale Paketsammlung, ein großes Git-Repository mit Bauanleitungen für Software. Sie zählt zu den umfangreichsten Paketquellen überhaupt.

Dazu kommt NixOS, eine Linux-Distribution, die das ganze System mit Nix verwaltet, vom Bootloader über Systemdienste bis zu den Benutzerkonten.

Entstanden ist Nix Anfang der 2000er-Jahre an der Universität Utrecht. Eelco Dolstra entwickelte es im Rahmen seiner Doktorarbeit über ein „rein funktionales Modell für die Softwareverteilung“. NixOS folgte als Forschungsprojekt kurz darauf. Heute wird beides von einer großen Open-Source-Gemeinschaft entwickelt, organisatorisch getragen von der NixOS Foundation. Die Leitung des Projekts wurde nach internen Konflikten 2024 neu geordnet, seither gibt es ein gewähltes Steering Committee.

Das Problem, das Nix löst

Klassische Paketmanager wie apt unter Debian und Ubuntu oder dnf unter Fedora verwalten ein gemeinsames Dateisystem. Pakete legen ihre Dateien nach /usr/bin und /usr/lib, und von jeder Bibliothek gibt es in der Regel genau eine Version. Das funktioniert gut, solange alle Programme dieselbe Version brauchen. Daraus ergeben sich aber drei typische Probleme:

1. Versionskonflikte: Projekt A braucht OpenSSL in Version 1, Projekt B Version 3. Auf einem gemeinsamen System muss man sich entscheiden oder zu Hilfskonstruktionen greifen.
2. Schleichende Unterschiede: Ein Server, der zwei Jahre lang von Hand gepflegt wurde, gleicht keinem anderen mehr. Niemand weiß genau, welche Pakete, Einstellungen und Ausnahmen dazugekommen sind. Fachleute sprechen von Konfigurationsdrift.
3. Kein sauberes Zurück: Geht ein Update schief, ist der vorherige Zustand oft nur über ein Backup oder einen Snapshot wiederherzustellen.

Viele Werkzeuge mildern einzelne dieser Probleme: Versionsmanager wie nvm oder pyenv für Programmiersprachen, Container für Anwendungen, Ansible für einheitliche Serverkonfiguration. Nix verfolgt einen grundsätzlicheren Ansatz.

So funktioniert Nix: der Store und das Prinzip der festen Zutaten

Das Herzstück ist der Nix-Store, ein Verzeichnis unter /nix/store. Jedes Paket landet dort in einem eigenen Unterordner, dessen Name mit einer Prüfsumme beginnt, etwa /nix/store/ gefolgt von einer Zeichenkette wie b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-…. Die Prüfsumme berechnet Nix aus allen Zutaten des Pakets: Quellcode, Compiler, Bibliotheken, Bauoptionen. Ändert sich auch nur eine Zutat, entsteht ein neuer Pfad.

Daraus folgen die wichtigsten Eigenschaften:

• Mehrere Versionen nebeneinander: Zwei Programme können unterschiedliche Versionen derselben Bibliothek nutzen, ohne sich zu stören, denn jedes verweist auf seinen eigenen Pfad.
• Vollständige Abhängigkeiten: Ein Paket findet nur die Abhängigkeiten, die in seiner Bauanleitung stehen. Vergessene Abhängigkeiten fallen deshalb beim Bauen auf und nicht erst beim Kunden.
• Binärcache: Weil der Pfad die Zutaten eindeutig beschreibt, kann Nix fertig gebaute Pakete von einem Cache-Server laden, statt sie selbst zu kompilieren. Für Nixpkgs betreibt das Projekt einen öffentlichen Cache, Unternehmen können eigene aufsetzen.
• Atomare Wechsel: Installiert wird zunächst neben dem bestehenden Stand. Erst wenn alles fertig ist, schaltet Nix einen symbolischen Verweis um. Es gibt keinen halbfertigen Zustand.

Eine wichtige Einschränkung: Nix garantiert, dass gleiche Zutaten zu einer identischen Bauanleitung führen. Ob das Ergebnis Bit für Bit identisch ist, hängt zusätzlich davon ab, ob die Software selbst reproduzierbar baut, also etwa keine Zeitstempel einbettet. Daran arbeiten Nixpkgs und andere Distributionen gemeinsam, vollständig gelöst ist es nicht.

Entwicklungsumgebungen: der einfachste Einstieg

Für die meisten Teams beginnt Nix nicht mit einem neuen Betriebssystem, sondern mit einer Projektumgebung. Eine Datei im Repository legt fest, welche Werkzeuge das Projekt braucht. Der klassische Weg ist eine Datei shell.nix:

# shell.nix – Werkzeuge für ein Python-Projekt
{ pkgs ? import <nixpkgs> { } }:

pkgs.mkShell {
  packages = [
    pkgs.python312
    pkgs.uv
    pkgs.postgresql_16
  ];

  shellHook = ''
    echo "Python-Umgebung bereit"
  '';
}

Der Befehl nix-shell im Projektordner öffnet eine Shell, in der genau diese Programme verfügbar sind. Verlässt man die Shell, sind sie wieder weg, das restliche System bleibt unberührt. Für einen schnellen Test genügt sogar nix-shell -p htop, ohne Datei.

Angenommen, ein Team pflegt drei Kundenprojekte mit unterschiedlichen Node- und PostgreSQL-Versionen. Mit je einer solchen Datei pro Repository wechselt jeder Entwickler per Ordnerwechsel die Umgebung. Das Werkzeug direnv kann das sogar automatisch erledigen. Ersetzt werden damit viele sprachspezifische Versionsmanager, nicht aber die Paketmanager der Sprachen selbst: npm, pip oder Cargo verwalten weiterhin die Bibliotheken des Projekts.

Eine Schwäche hat das Beispiel: import <nixpkgs> nimmt den Stand von Nixpkgs, der gerade auf dem jeweiligen Rechner eingestellt ist. Zwei Kollegen können also unterschiedliche Versionen bekommen. Genau dieses Problem lösen Flakes.

Flakes: festgeschriebene Versionen, offiziell noch experimentell

Ein Flake ist ein Projekt mit einer Datei flake.nix, die ihre Eingaben ausdrücklich benennt, und einer Datei flake.lock, die deren genaue Git-Revision festschreibt. Das Prinzip kennen Webentwickler von package-lock.json.

# flake.nix – Entwicklungsumgebung für ein Node.js-Projekt
{
  description = "Entwicklungsumgebung für den Webshop";

  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";

  outputs = { self, nixpkgs }:
    let
      system = "x86_64-linux";
      pkgs = nixpkgs.legacyPackages.${system};
    in
    {
      devShells.${system}.default = pkgs.mkShell {
        packages = [
          pkgs.nodejs_22
          pkgs.postgresql_16
          pkgs.git
        ];
      };
    };
}

Mit nix develop öffnet sich die Umgebung, und weil flake.lock im Repository liegt, bekommen alle im Team und die CI-Pipeline exakt dieselben Pakete. Aktualisiert wird bewusst mit nix flake update, als nachvollziehbare Änderung in Git.

Flakes sind in der Praxis weit verbreitet, viele Anleitungen und Projekte setzen sie voraus. Im offiziellen Nix gelten sie und die neuere Kommandozeile mit Befehlen wie nix develop aber weiterhin als experimentell und müssen in der Konfiguration mit experimental-features = nix-command flakes freigeschaltet werden. Einige Distributionen von Nix, etwa die des Unternehmens Determinate Systems, aktivieren Flakes standardmäßig. Für Unternehmen heißt das: Flakes sind für neue Projekte der übliche Weg, sie sollten aber wissen, dass sich Details noch ändern können.

NixOS: das ganze System als Textdatei

NixOS überträgt das Prinzip auf das Betriebssystem. Die Datei /etc/nixos/configuration.nix beschreibt, wie der Rechner aussehen soll:

# /etc/nixos/configuration.nix – ein kleiner Webserver
{ config, pkgs, ... }:

{
  imports = [ ./hardware-configuration.nix ];

  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  networking.hostName = "web01";
  time.timeZone = "Europe/Berlin";

  users.users.admin = {
    isNormalUser = true;
    extraGroups = [ "wheel" ];
    openssh.authorizedKeys.keys = [ "ssh-ed25519 AAAA… admin@firma" ];
  };

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

  services.nginx = {
    enable = true;
    virtualHosts."intranet.example.com".root = "/var/www/intranet";
  };

  networking.firewall.allowedTCPPorts = [ 22 80 443 ];

  environment.systemPackages = with pkgs; [ git htop vim ];

  # Version der Erstinstallation – nicht bei Updates ändern
  system.stateVersion = "26.05";
}

Die Datei legt Bootloader, Rechnername, Zeitzone, einen Administrator mit SSH-Schlüssel, einen abgesicherten SSH-Dienst, einen Webserver, die Firewall und einige Werkzeuge fest. Mit sudo nixos-rebuild switch baut NixOS daraus das neue System und schaltet um. Der Eintrag system.stateVersion wird oft missverstanden: Er gibt nicht die installierte Version an, sondern den Stand der Erstinstallation, damit sich Datenformate von Diensten bei Updates nicht ungewollt ändern.

Jeder Umbau erzeugt eine neue Generation des Systems. Die vorherigen bleiben erhalten und erscheinen im Bootmenü. Startet der Rechner nach einem Update nicht mehr sauber, wählt man beim Booten einfach die letzte funktionierende Generation, im laufenden Betrieb hilft sudo nixos-rebuild switch --rollback. Alte Generationen räumt nix-collect-garbage auf, sonst wächst der Store mit der Zeit erheblich.

NixOS erscheint zweimal im Jahr, im Mai und im November, die Versionsnummer setzt sich aus Jahr und Monat zusammen. Aktuell ist 26.05 vom Mai 2026, die Version 26.11 ist für Ende November 2026 geplant. Jede Version wird nur rund sieben Monate gepflegt, Updates auf die nächste Version gehören also fest zum Betrieb. Für Benutzerumgebungen gibt es außerdem Home Manager, das Programme und Einstellungen im Heimverzeichnis auf dieselbe Weise beschreibt, auf macOS ergänzt nix-darwin die Systemkonfiguration.

Nix, Ansible und Docker: wer macht was

Nix wird oft mit Werkzeugen verglichen, die ähnliche Ziele haben. Die Unterschiede sind grundsätzlich.

Ansible konfiguriert bestehende Systeme, indem es per SSH Aufgaben ausführt: Paket installieren, Datei anlegen, Dienst starten. Die Module sind idempotent, ein zweiter Lauf ändert also nichts, wenn alles stimmt. Was im Playbook nicht steht, fasst Ansible aber nicht an. Entfernt jemand eine Aufgabe aus dem Playbook, bleibt das Paket auf dem Server. NixOS baut das System dagegen jedes Mal vollständig aus der Beschreibung. Was nicht in der Konfiguration steht, ist nach dem Umbau nicht mehr aktiv. Dafür funktioniert Ansible mit Debian, Ubuntu, Red Hat und Windows gleichermaßen, NixOS verlangt eine eigene Distribution. Wie Ansible arbeitet, erklärt unser Beitrag Ansible erklärt: Server automatisch konfigurieren im DevOps-Alltag.

Docker und andere Container verpacken eine Anwendung mit ihren Abhängigkeiten in ein Image. Das löst viele Versionsprobleme, aber ein Dockerfile mit apt-get install liefert je nach Tag unterschiedliche Ergebnisse. Nix kann Container-Images selbst bauen und dabei die Paketversionen genau festlegen. Viele Teams kombinieren beides: Nix für die reproduzierbare Erzeugung, Container für Auslieferung und Betrieb, etwa in Kubernetes. Welche Container-Werkzeuge es neben Docker gibt, zeigt unser Beitrag zu Docker-Alternativen wie Podman und containerd.

Alle drei gehören zur Familie von Infrastructure as Code: Systeme werden als Text beschrieben, in Git versioniert und wie Software geprüft. Nix geht dabei am weitesten, verlangt aber auch am meisten Umstellung.

Die Lernkurve und andere Schattenseiten

Die Vorteile von Nix sind real, die Einstiegshürde auch. Die häufigsten Stolpersteine:

• Eine eigene Sprache: Die Nix-Sprache ist klein, aber ungewohnt. Fehlermeldungen sind oft lang und verweisen auf Stellen tief in Nixpkgs statt auf den eigenen Fehler.
• Verstreute Dokumentation: Neben dem offiziellen Handbuch und nix.dev gibt es viele Blogartikel, die alte und neue Wege vermischen. Ob eine Anleitung Flakes nutzt oder nicht, ist nicht immer sofort erkennbar.
• Ungewöhnliches Dateisystem: Vorkompilierte Programme, die Bibliotheken unter /usr/lib erwarten, laufen unter NixOS nicht ohne Weiteres. Dafür gibt es Hilfsmittel, sie kosten aber Zeit.
• Speicherbedarf: Mehrere Versionen und Generationen nebeneinander brauchen Platz. Ohne regelmäßiges Aufräumen füllt sich die Platte.
• Wenig Fachkräfte: Wer NixOS-Server betreibt, braucht mehr als eine Person, die das System versteht. Das ist für kleine IT-Abteilungen ein echtes Betriebsrisiko.

Realistisch sollten Sie für ein Team mit Linux-Erfahrung einige Wochen einplanen, bis es Nix sicher im Alltag nutzt. Bei NixOS im Serverbetrieb eher mehr.

Was das für Ihr Team bedeutet

Für die meisten Entwicklungsteams lohnt sich Nix zuerst als Werkzeug für Entwicklungsumgebungen. Der Einstieg ist überschaubar, er lässt sich auf ein Projekt begrenzen, und der Nutzen zeigt sich schnell: neue Kollegen sind schneller arbeitsfähig, die CI-Pipeline nutzt dieselben Werkzeuge wie der Laptop, und Fehler durch abweichende Versionen werden seltener. Wer bereits mit Containern arbeitet, kann Nix schrittweise für den Bau der Images ergänzen.

NixOS als Serverbetriebssystem ist dagegen eine strategische Entscheidung. Es spielt seine Stärken bei vielen gleichartigen Systemen, bei hohen Anforderungen an Nachvollziehbarkeit und bei Teams aus, die ohnehin alles in Git verwalten. Für eine kleine IT-Abteilung, die vor allem eine Handvoll Windows- und Ubuntu-Server pflegt, ist Ansible meist der pragmatischere Weg. Überschätzt wird Nix, wenn man es als Ersatz für alles verkauft. Unterschätzt wird es, weil das Prinzip der festen Zutaten auch die Sicherheit der Lieferkette stärkt: Wer genau weiß, welche Versionen in einem System stecken, kann Schwachstellen gezielter finden und beheben.

Unsere Empfehlung: Beginnen Sie mit einer Flake-basierten Entwicklungsumgebung in einem Projekt, sammeln Sie dort Erfahrung und entscheiden Sie danach, ob Nix auch im Betrieb eine Rolle spielen soll. Wie sich Nix in eine Gesamtstrategie für automatisierte Infrastruktur einfügt, besprechen wir in Beratung und Schulungen auf unserer Themenseite Infrastructure as Code.

Häufige Fragen zu Nix und NixOS

Braucht man NixOS, um Nix zu nutzen?

Nein. Der Paketmanager Nix läuft parallel zu apt, dnf oder Homebrew auf Linux und macOS und ändert das bestehende System kaum. Er legt seine Dateien unter /nix ab und lässt sich wieder entfernen. Das ist der übliche Weg, Nix kennenzulernen.

Ist Nix für Einsteiger geeignet?

Für einfache Aufgaben wie eine Projektumgebung mit festgelegten Werkzeugen ja, wenn eine Vorlage vorhanden ist. Wer eigene Pakete schreibt oder NixOS betreibt, braucht solide Linux-Kenntnisse und Geduld mit der Nix-Sprache.

Ersetzt Nix Docker?

Nicht vollständig. Nix ersetzt Docker als Werkzeug für Entwicklungsumgebungen und kann Container-Images bauen. Für Isolation und Betrieb in Kubernetes oder auf Container-Plattformen bleiben Container das übliche Format. Beide ergänzen sich gut.

Wie aktuell sind die Pakete in Nixpkgs?

Sehr aktuell. Neben den stabilen Zweigen der halbjährlichen Versionen gibt es den Zweig nixos-unstable, der neue Programmversionen meist schnell erhält. Viele Teams kombinieren ein stabiles System mit einzelnen Paketen aus diesem Zweig.

Was kostet Nix?

Nix, Nixpkgs und NixOS sind Open Source und kostenlos. Kosten entstehen durch Einarbeitung, gegebenenfalls durch einen eigenen Binärcache für selbst gebaute Pakete und durch kommerzielle Unterstützung, die einige Unternehmen anbieten.