Wer sich schon einmal auf einem Ubuntu-Server wiedergefunden hat, den er vor einem Jahr aufgesetzt hat – und keine Ahnung mehr hatte, warum Paket X manuell installiert, Dienst Y durch eine Zeile in /etc/rc.local gestartet und Konfiguration Z irgendwann per Hand geändert wurde – der kennt das Problem: Configuration Drift. Der Server läuft, aber niemand weiß mehr exakt, wie und warum.

Genau dieses Problem hat mich dazu gebracht, meinen Homelab-Server von Ubuntu auf NixOS umzustellen. Was folgt, ist eine Erklärung, warum dieses ungewöhnliche Linux-Derivat die Art und Weise, wie ich Server betreibe, dauerhaft verändert hat.

Was ist NixOS eigentlich?

NixOS ist eine Linux-Distribution, die auf dem Nix-Paketmanager aufbaut und einen radikal anderen Ansatz verfolgt: Das gesamte System – von installierten Paketen über Systemdienste bis hin zur Netzwerkkonfiguration – wird in einer einzigen deklarativen Konfigurationsdatei beschrieben: der configuration.nix.

Das klingt zunächst nach mehr Aufwand. In der Praxis ist es genau das Gegenteil. Statt Befehle auszuführen und zu hoffen, dass der Zustand des Systems dem entspricht, was man sich vorgestellt hat, beschreibt man den gewünschten Zustand – und NixOS sorgt dafür, dass er eintritt.

Ein Dienst in drei Zeilen

Ein konkretes Beispiel: Um auf Ubuntu einen Nginx-Webserver zu installieren und zu starten, führt man mehrere Befehle aus, bearbeitet Konfigurationsdateien in /etc/nginx/ und hofft, dass systemctl enable nginx nicht vergessen wurde. In NixOS sieht die Konfiguration so aus:

services.nginx.enable = true;
services.nginx.virtualHosts."example.com" = {
  locations."/" = { proxyPass = "http://127.0.0.1:8000"; };
};

Ein nixos-rebuild switch später ist Nginx installiert, gestartet, aktiviert und konfiguriert – genau so, wie beschrieben. Keine weiteren Schritte notwendig.

Atomare Updates und Rollbacks

Was passiert, wenn ein Update den Server kaputt macht? Auf Ubuntu beginnt die Fehlersuche. Auf NixOS wechselt man beim nächsten Boot einfach in die vorherige Generation. Jede Änderung an der Konfiguration erzeugt eine neue, unveränderliche Systemgeneration. Die alten Generationen bleiben erhalten und sind im Bootloader auswählbar:

# Letzte funktionierende Generation aktivieren
sudo nixos-rebuild switch --rollback

Das ist kein Marketing-Versprechen – ich habe es selbst genutzt, nachdem ein fehlerhafter Nginx-Vhost meinen Server für externe Dienste kurzzeitig unzugänglich gemacht hatte. Drei Sekunden und ein Befehl, alles wieder wie vorher.

Reproduzierbarkeit als Superkraft

Der vielleicht unterschätzte Vorteil: Meine gesamte Server-Konfiguration liegt in einem Git-Repository. Jede Änderung wird committet, jede Absicht ist dokumentiert. Wenn ich heute einen zweiten Server aufsetzen wollte, der exakt meinem aktuellen entspricht, reicht ein git clone und ein nixos-rebuild switch.

Das ist etwas, das mit Ansible-Playbooks oder Docker-Compose-Files nur annähernd erreicht wird – aber nie vollständig, weil immer manuelle Schritte zwischen den Zeilen versteckt sind.

Der Einstieg: Was man wissen muss

NixOS hat eine steile Lernkurve. Die Nix-Sprache ist funktional und gewöhnungsbedürftig. Die Fehlermeldungen können kryptisch sein. Und nicht jede Software ist im Nix-Ökosystem sofort verfügbar.

  • Dokumentation: nixos.org/options ist die zentrale Referenz für alle verfügbaren Optionen
  • NixOS-Search: Pakete und Optionen lassen sich unter search.nixos.org durchsuchen
  • Home Manager: Für User-spezifische Konfiguration empfiehlt sich das Home-Manager-Modul

Fazit

Ein Server, der seinen eigenen Zustand vollständig in einer versionierten Textdatei beschreibt – das ist die Kernidee hinter NixOS. Nach dem Umstieg würde ich nie mehr zurück zu einem klassischen System wollen. Sämtliche Webdienste, die ich für Kunden betreibe, laufen auf diesem Prinzip – deklarativ, reproduzierbar, mit Rollback auf Knopfdruck.

Den nächsten logischen Schritt – wie ich Django-Apps auf NixOS deploye – erkläre ich im Artikel Django auf NixOS deployen. Fragen gerne über das Kontaktformular.