NixOS: Der Leitfaden vom Paketmanager Nix

Stell dir vor, du konfigurierst einen Server für eine kritische Anwendung – und nach einem Update bricht alles zusammen, weil eine Abhängigkeit geändert wurde. Oder du versuchst, eine Entwicklungsumgebung auf mehreren Maschinen identisch aufzusetzen, und endest mit Versionskonflikten. Solche Szenarien sind in der Linux-Welt leider alltäglich. Hier kommt Nix ins Spiel: Ein Paketmanager, der diese Probleme durch einen radikal anderen Ansatz löst. Nix ist nicht nur ein Tool zur Paketinstallation, sondern ein ganzes Ökosystem für reproduzierbare, deklarative und isolierte Systeme. Und NixOS baut darauf auf, indem es das gesamte Betriebssystem deklarativ verwaltet.

In diesem Leitfaden tauchen wir tief in Nix und NixOS ein. Wir starten mit den Basics und gehen bis zu fortgeschrittenen Techniken für Sysadmins. Ob du ein Linux-Anfänger bist, der seine ersten Schritte in reproduzierbaren Umgebungen macht, oder ein erfahrener Admin, der Serverflotten managen muss – hier findest du praxisnahe Anleitungen.

❗Wichtiger Hinweis: Dieser Artikel basiert auf dem Stand von NixOS 25.11, der neuesten stabilen Version aus November 2025. Nix entwickelt sich rasant, also prüfe immer die offizielle Dokumentation auf Updates.

Definition und Kernkonzepte

Nix ist ein rein funktionaler Paketmanager, der Pakete als unveränderliche (immutable) Einheiten behandelt. Im Gegensatz zu traditionellen Managern wie APT oder Pacman, die Pakete global installieren und den Systemzustand verändern, baut Nix alles in isolierten Pfaden auf. Jede Installation erhält einen einzigartigen Hash, der alle Abhängigkeiten und Build-Parameter berücksichtigt. Das Ergebnis? Reproduzierbare Builds: Was auf deiner Maschine läuft, läuft exakt so auf einer anderen.

Der Kern von Nix basiert auf der Nix-Sprache, einer funktionalen Skriptsprache ähnlich wie Haskell. Sie beschreibt "Derivations" – Bauanleitungen für Pakete. Eine Derivation spezifiziert Inputs (z.B. Quellcode, Bibliotheken), Build-Schritte und Outputs. Sobald gebaut, landet alles im Nix Store unter /nix/store.

Hier ein einfaches ASCII-Diagramm zur Veranschaulichung des Build-Prozesses:

+---------------+     +----------------+     +-----------------+
|  Derivation   | --> |  Build Inputs  | --> |  Nix Builder    |
| (nix expr)    |     | (Hashes, Deps) |     | (Isolated Env)  |
+---------------+     +----------------+     +-----------------+
                             |                          |
                             v                          v
                      +----------------+     +-----------------+
                      |  Hashing       | <-- |  Build Output   |
                      | (Unique Path)  |     | (Immutable Pkg) |
                      +----------------+     +-----------------+
                                                |
                                                v
                                       /nix/store/<hash>-pkg-name-version/

💡 Tipp: Der Hash sorgt dafür, dass selbst minimale Änderungen (z.B. eine andere Compiler-Flag) einen neuen Pfad erzeugen. Das verhindert Kollisionen und ermöglicht parallele Versionen.

NixOS erweitert das auf das gesamte System. Statt manueller Konfiguration (z.B. via /etc) definierst du alles in einer configuration.nix-Datei. Ein Rebuild wechselt atomar zum neuen Zustand, mit Rollback-Option. Das macht NixOS ideal für Server, wo Downtime teuer ist.

Vorteile vs. Nachteile

Die Stärken von Nix liegen in seiner Zuverlässigkeit:

🔧 Praxisbeispiel:

Als Sysadmin baust du eine Web-Anwendung. Mit Nix definierst du alle Deps (Node.js, PostgreSQL) in einer Shell-Umgebung. Dein Team kann exakt dasselbe Setup mit einem nix-shell laden – unabhängig vom Host-OS.

Aber Nix hat auch Schattenseiten:

⚠️ Warnung: Die Lernkurve ist steil. Konzepte wie Derivations und Flakes erfordern Zeit. Anfangs frustrierend, wenn du von APT kommst. Zudem sind Builds ressourcenintensiv, da Nix oft von Source kompiliert (obwohl Binary Caches helfen).

Ein weiterer Nachteil: Die Community ist kleiner als bei Ubuntu, was zu weniger fertigen Paketen führen kann. Aber mit über 100.000 Paketen in Nixpkgs deckt es die meisten Bedürfnisse ab.

Historie: Von 2003 bis 2026

Nix wurde 2003 von Eelco Dolstra an der Universität Utrecht entwickelt, um Software-Deployment-Probleme in großen Systemen zu lösen. Die erste Version fokussierte auf funktionale Builds. 2012 entstand NixOS als Distribution, die Nix für das gesamte OS nutzt.

Bis 2020 wuchs Nix langsam, vor allem in der Haskell-Community. Der Durchbruch kam mit Flakes (eingeführt 2020 als experimental Feature in Nix 2.4). Flakes standardisieren Konfigurationen und machen sie portabel – kein Channel-Management mehr.

Im Jahr 2026 ist Flakes der Standard. In NixOS 25.11 (November 2025) wurde Flakes vollständig stabilisiert, mit besserer Integration in Tools wie nix develop. Community-Wachstum: Über 10.000 Contributor auf GitHub, jährliche NixCon mit Tausenden Teilnehmern. Neueste Entwicklungen umfassen bessere Hardware-Support (z.B. für ARM) und Cloud-Integration (z.B. native AWS-Images).

💡 Tipp: Wenn du von älteren Versionen kommst, migriere zu Flakes. Sie sind 2026 der Weg für alle neuen Setups.

Einsatzbereiche

Nix glänzt in Szenarien, wo Konsistenz zählt:

🔧 Praxisbeispiel: Reproduzierbarer Webserver-Setup. Als Admin setzt du einen Nginx-Server auf. In einer flake.nix definierst du:

{
  description = "Simple Nginx Server";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.11";
  outputs = { self, nixpkgs }: {
    nixosConfigurations.myServer = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        ({ config, pkgs, ... }: {
          services.nginx.enable = true;
          services.nginx.virtualHosts."example.com" = {
            forceSSL = true;
            enableACME = true;
            locations."/" = { root = "/var/www"; };
          };
        })
      ];
    };
  };
}

Build mit nixos-rebuild switch --flake .#myServer. Das Ganze ist versioniert und deploybar auf beliebigen Hosts. Kein manueller Konfig-Chaos mehr.

Vergleich mit anderen Tools

Vergleichen wir Nix mit Bekannten:

Einordnung: Nix im Vergleich zu bekannten Werkzeugen

Der folgende Vergleich stellt NixOS dem jeweils zugrundeliegenden Ansatz anderer bekannter Werkzeuge gegenüber. Ziel ist es, die grundlegenden Unterschiede im Umgang mit Software und Abhängigkeiten verständlich zu machen.

+-------------+---------------+---------------+-----------------------------+
| System      | Ansatz        | Isolation     | Charakteristik              |
+-------------+---------------+---------------+-----------------------------+
| APT         | imperativ     | global        | einfach, aber anfaellig     |
| (Debian/Ub) |               |               | fuer Abhaengigkeitskonfl.   |
+-------------+---------------+---------------+-----------------------------+
| Docker      | container-    | Container     | starke Isolation, zusaetzl. |
|             | basiert       |               | Runtime-Overhead            |
+-------------+---------------+---------------+-----------------------------+
| Guix        | deklarativ    | paketbasiert  | funktional, Scheme-basiert  |
|             | funktional    |               |                             |
+-------------+---------------+---------------+-----------------------------+
| Nix (NixOS) | deklarativ    | paketbasiert  | reproduzierbar, Rollbacks   |
|             |               |               | auf Systemebene             |
+-------------+---------------+---------------+-----------------------------+

Nix und NixOS revolutionieren die Linux-Administration durch Fokus auf Zuverlässigkeit. Wenn du bereit bist für die Lernphase, sparst du langfristig Stunden an Debugging. Im nächsten Abschnitt gehen wir zu den Grundlagen über.

Grundlegende Konzepte und Installation

Nachdem wir uns mit den Grundideen von Nix und NixOS auseinandergesetzt haben, lass uns nun die Kernbausteine genauer betrachten. Hier lernst du, wie der Nix Store funktioniert, was Profile und Generationen bedeuten und wie du Nix oder NixOS installierst. Wir fokussieren uns auf praxisnahe Schritte, damit du direkt loslegen kannst – ob auf einem bestehenden Linux-System oder bei einem frischen Setup.

❗ Wichtiger Hinweis: In NixOS 25.11, der stabilen Version aus November 2025, ist Multi-User-Modus der Standard für sichere Installationen. Achte darauf, um Konflikte mit Systempaketen zu vermeiden.

Der Nix Store: Herzstück der Isolation

Der Nix Store unter /nix/store ist der zentrale Speicherort für alle Pakete, Derivations und Builds. Jedes Element erhält einen einzigartigen Pfad, der durch einen Hash aller Inputs (Quellcode, Abhängigkeiten, Build-Flags) generiert wird. Das gewährleistet, dass identische Inputs immer denselben Output erzeugen – pure Reproduzierbarkeit.

Ein typischer Pfad sieht so aus: /nix/store/abc123def456-firefox-130.0/. Hier steht "abc123def456" für den Hash, "firefox" für den Paketnamen und "130.0" für die Version.

⚠️ Warnung: Der Store ist read-only nach Builds. Änderungen außerhalb von Nix können zu Inkonsistenzen führen. Nutze immer Nix-Befehle für Modifikationen.

Zur Veranschaulichung des Store-Aufbaus:

+-------------+
| /nix/store  |
+-------------+
      |
      +-------------------+     +-------------------+
      | Hash-Pfad         |     | Paket-Inhalte     |
      | (z.B. abc123-...) | --> | Binaries, Libs,   |
      +-------------------+     | Docs, etc.        |
                                +-------------------+
      |
      +-------------------+
      | Symlinks (Profile)|
      | -> Aktive Pakete  |
      +-------------------+

💡 Tipp: Überprüfe den Store mit nix-store --query --references /nix/store/<hash>, um Abhängigkeiten zu sehen. Nützlich, wenn du debuggst, warum etwas nicht gelöscht wird.

Als Sysadmin profitierst du hier: Auf einem Server mit mehreren Anwendungen kannst du unterschiedliche Versionen von Bibliotheken isolieren, ohne Konflikte. Zum Beispiel läuft eine App mit glibc 2.37, eine andere mit glibc 2.38 – alles parallel.

Profile und Generationen: Flexible Umgebungen

Profile fassen Pakete zu Umgebungen zusammen, die du aktivierst oder rollbackst. Das moderne Tool dafür ist nix profile, das nix-env ablöst. Jede Änderung erzeugt eine neue Generation, die du wie Snapshots handhabst.

Beispiel: Installiere Firefox und liste Profile auf.

nix profile install nixpkgs#firefox
nix profile list

Ausgabe könnte sein:

Index:    0
Flake:    nixpkgs
Attr:     firefox
Path:     /nix/store/abc123def456-firefox-130.0

Generationen erlauben Rollbacks. Zeige sie an und wechsle:

nix profile history
nix profile rollback --to 5  # Zur Generation 5 wechseln

🔧 Praxisbeispiel:

Als Admin testest du ein Update auf einem Staging-Server. Nach nix profile upgrade prüfst du die App. Läuft's schief? Rollback mit einem Befehl – keine Downtime.

❗Wichtig: In Multi-User-Setups (Standard 2026) laufen Profile unter /nix/var/nix/profiles/. Das trennt User- von System-Umgebungen für bessere Sicherheit.

Configuration.nix: Deklarative Systemsteuerung

Für NixOS ist configuration.nix die zentrale Datei unter /etc/nixos/. Sie beschreibt den gesamten Systemzustand in Nix-Syntax: Services, User, Hardware usw. Das Module-System erlaubt modulare Erweiterungen, inklusive neuer Features wie systemd v256-Integration in 25.11.

Eine einfache Config:

{ config, pkgs, ... }:
{
  boot.loader.systemd-boot.enable = true;
  services.openssh.enable = true;
  environment.systemPackages = with pkgs; [
    firefox
    vim
    git
  ];
  system.stateVersion = "25.11";
}

Aktiviere mit sudo nixos-rebuild switch. Das baut das System neu und wechselt atomar.

💡 Tipp: Nutze system.stateVersion für Kompatibilität. In 25.11 unterstützt es verbesserte Security-Module, z.B. für AppArmor.

Als Sysadmin: Definiere Server-Konfigs in Git. Push Änderungen, rebuild – fertiger Infrastructure-as-Code.

Installation: Von Standalone bis NixOS

Nix lässt sich standalone auf Distros wie Ubuntu installieren oder als volles NixOS.

Standalone auf Ubuntu 24.04:

sh <(curl -L https://nixos.org/nix/install) --daemon  # Multi-User
. /etc/profile.d/nix.sh

Teste mit nix --version. Neu in 2026: Automatische Integration mit systemd für bessere Daemon-Handhabung.

NixOS-Installation:

Lade das ISO von nixos.org, boote und editiere configuration.nix. Dann:

sudo nixos-install

Neu: nixos-anywhere für Remote-Installs. Auf einem bestehenden Server:

nix run github:nix-community/nixos-anywhere -- --flake .#myhost user@remote-host

⚠️ Warnung: Bei Remote-Installs sichere Daten! Es überschreibt den Bootloader.

🔧 Praxisbeispiel: Als Admin deployest du NixOS auf einen Cloud-VM (z.B. AWS). Mit nixos-anywhere konfigurierst du aus der Ferne – ideal für Flotten.

Flakes-Grundlagen: Moderne Konfig-Management

Flakes sind 2026 Standard: Sie packen Konfigs in flake.nix, mit Inputs für Abhängigkeiten. Keine Channels mehr nötig.

Einfache Flake:

{
  description = "Basic System";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.11";
  outputs = { self, nixpkgs }: {
    nixosConfigurations.myhost = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [ ./configuration.nix ];
    };
  };
}

Build mit nixos-rebuild switch --flake .#myhost.

Zur Veranschaulichung der Flake-Struktur:

+-------------+
| flake.nix   |
+-------------+
      |
      +-------------------+     +-------------------+
      | Inputs (nixpkgs) | --> | Outputs (Configs) |
      +-------------------+     +-------------------+
                                |
                                +-------------------+
                                | Lockfile (Hashes) |
                                +-------------------+

💡 Tipp: flake.lock fixiert Versionen für Reproduzierbarkeit. Update mit nix flake update.

Erste Schritte: Nix-Shell für Tests

Starte mit nix-shell oder nix develop für temporäre Umgebungen.

nix-shell -p hello
hello

Das lädt Hello-World isoliert, ohne den Store zu verändern.

🔧 Praxisbeispiel: Als Sysadmin testest du ein Tool: nix develop -f '<nixpkgs>' -c bash. Lade Deps on-the-fly – super für Troubleshooting.

Mit diesen Basics bist du gerüstet, Nix in der Praxis einzusetzen. Der Store und Profile sorgen für Stabilität, Flakes für Flexibilität. Im nächsten Teil vertiefen wir Paketmanagement.

Paketmanagement und fortgeschrittene Features

Mit den Grundlagen im Gepäck – vom Store über Profile bis zu ersten Flakes – können wir nun tiefer in den Alltag eintauchen. Hier geht's um das tägliche Handwerk: Pakete installieren, aktualisieren und anpassen. Wir schauen uns auch an, wie Nix in DevOps-Workflows passt, und heben Features hervor, die in 2026 Standard sind, wie erweiterter OCI-Support für Container. Alles praxisorientiert, damit du als Sysadmin direkt umsetzen kannst.

❗ Wichtiger Hinweis: Seit NixOS 25.11 sind Flakes der empfohlene Weg für alles. Channels gelten als veraltet – migriere frühzeitig, um Kompatibilitätsprobleme zu vermeiden.

Installation: Von Basics zu Flakes

Pakete holst du mit nix profile install. Das Tool ist flexibel und integriert sich nahtlos mit Flakes. Für ein Paket aus Nixpkgs:

nix profile install nixpkgs#firefox

Das resolved den Attributpfad und baut bei Bedarf. Willst du eine spezifische Version? Nutze Overrides oder pinned Inputs.

⚠️ Warnung: Vermeide alte Channels wie nix-channel --add. Sie sind depreciated und können zu unvorhersehbarem Verhalten führen. Stattdessen Flakes für pinned Versionen.

Channels vs. Flakes im Vergleich – ein ASCII-Diagramm:

Channels (alt): 
+------------+     +------------+
| nixpkgs    | --> | Unpinned   |
| unstable   |     | Versions   |
+------------+     +------------+
Flakes (neu): 
+------------+     +------------+
| flake.nix  | --> | Pinned     |
| inputs     |     | Hashes     |
+------------+     +------------+
                    (flake.lock)

💡 Tipp: Für Teams: Teile Flakes via Git. Jeder baut exakt dasselbe – ideal für konsistente Staging-Umgebungen.

Als Sysadmin: Installiere Tools für Monitoring. nix profile install nixpkgs#prometheus – und du hast eine isolierte Version, die nicht mit Systempaketen kollidiert.

Updates und Rollbacks: Sichere Änderungen

Updates laufen deklarativ.

Für ein einzelnes Paket:

nix profile upgrade firefox

Für das ganze System: sudo nixos-rebuild switch --upgrade. Das holt frische Inputs und wechselt atomar.

Rollbacks sind kinderleicht, dank Generationen:

sudo nixos-rebuild switch --rollback

Oder spezifisch: --switch-generation 42.

🔧 Praxisbeispiel: Du managst einen Webserver. Nach einem Update crasht Nginx? Rollback in Sekunden – deine Site bleibt online. Teste Updates immer erst in einer VM mit nixos-rebuild build-vm.

❗ Wichtig: Prüfe vor Upgrades mit nixos-rebuild dry-run auf Breaking Changes. In 25.11 warnt es explizit vor Modul-Änderungen.

Overlays und Overrides: Custom Builds

Overlays erlauben Anpassungen an Nixpkgs. Definiere sie in ~/.config/nixpkgs/overlays/ oder direkt in Flakes.

Beispiel-Overlay für patched Firefox:

self: super: {
  firefox = super.firefox.override {
    extraPatches = [ ./my-patch.patch ];
    enableExtensions = true;
  };
}

In deiner Config: nixpkgs.overlays = [ (import ./overlay.nix) ];.

Overrides für einzelne Pakete:

In configuration.nix:

environment.systemPackages = with pkgs; [
  (vim.override { python3Support = true; })
];

Zur Veranschaulichung des Overlay-Mechanismus:

+--------------+     +--------------+
| Base Nixpkgs | --> | Overlay      |
| (super)      |     | Modifications|
+--------------+     +--------------+
                          |
                          v
                 +----------------+
                 | Final Package  |
                 | (self)         |
                 +----------------+

💡 Tipp: Für Enterprise: Baue custom Repos mit Overlays. So passt du Security-Patches an, ohne auf Upstream zu warten.

Als Sysadmin: Override OpenSSH für strengere Ciphers. Das hält deinen Server sicher, ohne das Base-System zu berühren.

DevOps-Integration: Nix in Pipelines

Nix passt perfekt zu CI/CD.

In GitHub Actions:

name: Build Nix Flake
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: cachix/install-nix-action@v24  # Aktualisiert für 2026
    - run: nix build .#myPackage

Neu in 2026: Besserer OCI-Support. Baue Container-Images mit nixpkgs#dockerTools:

pkgs.dockerTools.buildImage {
  name = "myapp";
  tag = "latest";
  contents = [ pkgs.nodejs pkgs.myApp ];
  config.Cmd = [ "${pkgs.nodejs}/bin/node" "/app/server.js" ];
};

Das erzeugt reproduzierbare Images – OCI-kompatibel für Kubernetes.

🔧 Praxisbeispiel: Deploye eine App in K8s. Nix baut das Image, du pushst es zu einer Registry. Keine "Dockerfile-Maintenance-Hölle" mehr.

⚠️ Warnung: In Pipelines: Aktiviere Flakes mit nixConfig.experimental-features = nix-command flakes. Andernfalls failen Builds.

Performance: Caches und Parallelisierung

Builds können zeitaufwendig sein, daher Binary Caches. Standard: cache.nixos.org.

Füge eigene hinzu:

nix.settings.substituters = [ "https://mycache.example.com" ];
nix.settings.trusted-public-keys = [ "mycache.example.com-1:..." ];

Für Private: Cachix – teile Caches teamweit.

Parallel Builds:

In Config:

nix.settings = {
  max-jobs = "auto";  # Alle Cores
  cores = 0;          # Unbegrenzt pro Job
};

Ein Diagramm für Cache-Ablauf:

+------------+     +------------+
| Local Build|  No | Remote     |
| (slow)     | <-- | Cache Hit  |
+------------+     +------------+
      | Yes             ^
      v                 |
 +----------------+     |
 | Store Output   | --> | Push to Cache
 +----------------+     (for Team)

💡 Tipp: Für große Setups: Richte einen internen Cache-Server auf. Spart Bandbreite und Zeit bei Flotten-Deployments.

Als Sysadmin: Optimiere Builds für ARM-Server. Mit Parallelisierung compilierst du schneller, Caches teilst du cross-plattform.

Multi-Version: Parallele Pakete

Nix erlaubt mehrere Versionen nebeneinander.

Installiere z.B. Python-Varianten:

nix profile install nixpkgs#python311 nixpkgs#python312

Nutze sie in Shells: nix-shell -p python311.

❗ Beispiel: Als Admin hostest du Apps mit unterschiedlichen Deps. Eine braucht Python 3.11, eine 3.12 – kein Problem, alles isoliert im Store.

🔧 Praxisbeispiel: Teste Bibliotheken. nix-shell -p python311Packages.tensorflow vs. python312Packages.tensorflow – vergleiche Performance ohne System-Änderungen.

Diese Tools machen Nix zum Powerhouse für Management und Customizing. Overlays und DevOps-Integration sparen dir als Sysadmin Stunden. Im letzten Teil schauen wir uns Sicherheit und Wartung an.

Sicherheit, Wartung und Best Practices

Jetzt, wo du Pakete managst und anpasst, kommt der entscheidende Teil: Wie hältst du alles sicher und wartbar? In diesem Abschnitt decken wir Security-Features ab, die in Nix 2.22 (integriert in 25.11) verbessert wurden, plus Routinen für Cleanup und Debugging. Als Sysadmin sparst du so Zeit und vermeidest Ausfälle – mit Fokus auf automatisierte Prozesse und Migrationstipps.

❗ Wichtiger Hinweis: Sandboxing ist in 25.11 default aktiviert. Deaktiviere es nur in kontrollierten Umgebungen, da es Builds vor externen Einflüssen schützt.

Security: Sandboxing und Trusted Users

Nix baut Security in den Kern ein. Sandboxing isoliert Builds in Chroots, um Zugriffe auf das Host-System zu blocken. Konfiguriere es systemweit:

nix.settings.sandbox = true;

Trusted Users erlauben nur bestimmten Accounts (z.B. root) sensible Operationen wie Cache-Signaturen.

nix.settings.trusted-users = [ "root" "admin" ];

⚠️ Warnung: Bei untrusted Sources (z.B. custom Flakes) prüfe Hashes manuell. Nutze nix store sign für eigene Builds.

Zur Veranschaulichung des Sandbox-Prozesses:

+---------------+     +----------------+
| Derivation    | --> | Sandbox (Chroot)|
| (Inputs)      |     | Isolated Build |
+---------------+     +----------------+
                           |
                           v
                   +----------------+
                   | Secure Output |
                   | (Hashed Path) |
                   +----------------+

💡 Tipp: Für Server: Integriere Nix mit SELinux-Modulen. In 25.11 gibt's fertige Profile dafür – aktiviere mit security.selinux.enable = true;.

Als Sysadmin: Schütze Produktionsserver vor fehlerhaften Builds. Sandboxing fängt Malware in Deps ab, Trusted Users verhindern Privilege-Escalation.

Wartung: Garbage Collection und Optimisation

Regelmäßige Cleanup hält den Store schlank. nix-collect-garbage löscht unreferenzierte Pfade:

sudo nix-collect-garbage -d  # Alte Generationen löschen

Automatisiere mit Cron (in configuration.nix):

services.cron = {
  enable = true;
  systemCronJobs = [ "0 2 * * * root nix-collect-garbage -d" ];
};

🔧 Praxisbeispiel: Auf einem Cloud-Server mit begrenztem Speicher: Cron-Job läuft nightly, kombiniert mit nix optimise-store. So sparst du Kosten bei Storage.

❗ Wichtig: Vor GC: nix-store --gc --print-roots zeigt, was erhalten bleibt. Nützlich, um wichtige Builds zu pinnen.

Debugging: Repl und Store-Checks

Bei Problemen: nix repl für interaktives Erkunden.

nix repl '<nixpkgs>'
:lf .  # Lade Flake
pkgs.firefox.outPath  # Zeige Pfad

Überprüfe Integrität: nix-store --verify --check-contents.

Logs findest du in /nix/var/log/nix/drvs.

💡 Tipp: Für Graphen: nix-store -q --graph /nix/store/<hash> | dot -Tpng > dep-graph.png. Visualisiert Abhängigkeiten – super für komplexe Setups.

Als Sysadmin: Debugge fehlende Deps. nix why-depends /run/current-system /nix/store/<pkg> zeigt, warum ein Paket referenziert wird.

Backups und Migration: Konfigs sichern

⚠️ Warnung: Bei Migration: Teste in einer VM. 25.11-Flakes ändern Input-Handhabung – passe inputs an.

🔧 Praxisbeispiel: Migriere einen Server-Fleet. Backup alte Generationen mit nix copy, dann flake-basierte Rebuilds. Rollback-Option bleibt erhalten.

Ein Backup-Flow-Diagramm:

+-------------+     +-------------+
| Config.nix  | --> | Git Repo    |
| /etc/nixos  |     | (Versioned) |
+-------------+     +-------------+
      |                   |
      v                   v
 +----------------+     +-------------+
 | nixos-rebuild  | <-- | Restore     |
 | (Test VM)      |     | from Backup |
 +----------------+     +-------------+
 ```
 
### Community: Ressourcen und Events
Tritt dem NixOS Discourse bei für Fragen: [discourse.nixos.org](https://discourse.nixos.org){.badge-link}
<blockquote class="infobox infobox--tip">
⚠️ **Hinweis:** Prüfe monatlich auf RFCs [github.com/NixOS/rfcs](https://github.com/NixOS/rfcs){.badge-link-text}. Neue Features wie erweiterter ARM-Support kommen oft via Community.
</blockquote>
</p>
<p>
<blockquote class="infobox infobox--tip">
💡 **Tipp:** Für Lernende: Nix Pills [nixos.org/guides/nix-pills](https://nixos.org/guides/nix-pills){.badge-link-text} – timeless, aber ergänze mit [zero-to-nix.com](zero-to-nix.com){.badge-link-text} für 2026-Updates.
</blockquote>
</p>
**Als Sysadmin:** Nutze die Community für Custom-Module. Teile deine Overlays – gib zurück und profitiere von Feedback.
## Fazit 
NixOS bietet mit seiner deklarativen Natur unschlagbare Vorteile für Zuverlässigkeit. Starte immer mit Flakes, automatisiere Wartung und priorisiere Security. Als Anfänger: Baue kleine Envs auf; als Pro: Integriere in CI/CD. Die Investition lohnt – weniger Ausfälle, mehr Skalierbarkeit.
<blockquote class="infobox infobox--practice">
❗ **Empfehlungen:** Migriere zu 25.11, nutze Cachix für Teams und besuche NixCon für Netzwerken. Mit diesen Practices bist du fit für 2026.
</blockquote>