Wat is NixOS? Declaratieve Linux voor servers uitgelegd

Wat is NixOS?

NixOS is een Linux-distributie waarin je de hele server beschrijft in één configuratiebestand. Elke wijziging aan dat bestand levert een nieuwe, complete systeemversie op. Die kun je met één commando weer terugdraaien. De basis is de pakketbeheerder Nix. Die zet elk pakket in een eigen map onder /nix/store, met een hash in de naam, zodat versies elkaar nooit overschrijven.

Deze gids laat zien hoe dat werkt en wat het kost. De voorbeelden zijn geschreven voor NixOS 26.05 "Yarara", de stabiele release van eind mei 2026. Volgens de release-aankondiging krijgt 26.05 updates tot en met 31 december 2026. De volgende stabiele release is 26.11.

Waarom NixOS ineens in het Nederlandse nieuws is

Eind september 2026 berichtte Tweakers dat het ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) werkt aan DAWO, de Digitaal Autonome Werkomgeving Overheid, en dat die werkplek op NixOS wordt gebouwd. Dat deel is geen gerucht: BZK publiceert de code zelf, in de repository MinBZK/DAWO-NixOS op code.overheid.nl. Volgens Tweakers testen acht gemeenten het systeem via de VNG (Vereniging van Nederlandse Gemeenten). Ook volgens Tweakers hopen de ontwikkelaars ergens in 2027 op een eerste stabiele versie, zonder formele planning. Het Duitse heise online nam het nieuws op 30 september over. Als reden voor de keuze noemt de berichtgeving dat NixOS Nederlandse wortels heeft en dat geen bedrijf het project bezit. Vanaf hier gaat het over NixOS zelf. Wat er ook met DAWO gebeurt, de techniek hieronder blijft hetzelfde.

De Utrechtse oorsprong van Nix

Nix begon als promotieonderzoek aan de Universiteit Utrecht. Eelco Dolstra verdedigde daar op 18 januari 2006 zijn proefschrift The Purely Functional Software Deployment Model. Het kernidee uit dat proefschrift is nog steeds de basis. Elk pakket staat los van de rest in een store, en de naam van elk pakket bevat een cryptografische hash van alles wat bij de bouw is gebruikt. De NixOS Foundation beheert onder meer de binary cache cache.nixos.org. Volgens nixos.org is de Foundation een stichting die is ingeschreven bij de Kamer van Koophandel in Utrecht. Wie wil zien waar Nix staat ten opzichte van Debian en Red Hat, vindt dat in de geschiedenis van Linux-distributies.

Hoe werkt de Nix store met hashes?

Op een gewone distributie installeert apt of dnf bestanden in gedeelde mappen zoals /usr/bin en /usr/lib. Twee versies van dezelfde bibliotheek kunnen daar niet naast elkaar staan, omdat ze hetzelfde pad willen. Een update overschrijft dus bestanden van een draaiend systeem.

Nix doet dat anders. Elk pakket krijgt een eigen map onder /nix/store. De naam begint met een hash van 32 tekens, gevolgd door de pakketnaam en de versie. Die hash wordt berekend uit alle invoer van de bouw: de broncode, het buildscript, de compileropties en de exacte versies van alle afhankelijkheden. Verander één invoer en je krijgt een ander pad. Daardoor kunnen twee versies van OpenSSL gewoon naast elkaar bestaan, en weet elk programma precies welke versie het gebruikt.

Je kunt dit zelf zien. Op een NixOS-machine wijst het actieve systeem naar een pad in de store:

readlink -f /run/current-system

De uitvoer is een pad dat begint met /nix/store/, dan de hash, en daarna nixos-system- met de hostnaam en het versienummer. De bestanden in de store zijn alleen-lezen. Niets in het systeem past ze achteraf aan.

Dat betekent niet automatisch dat elke build bit voor bit gelijk is. De hash beschrijft de invoer, niet de uitvoer. Twee builds met dezelfde invoer horen hetzelfde resultaat te geven. Een compiler die bijvoorbeeld een tijdstempel in het bestand zet, geeft toch verschillende bestanden. Het verschil tussen "zelfde invoer" en "zelfde bytes" staat uitgelegd in wat reproducible builds wel en niet beloven.

De hele machine in configuration.nix

Op NixOS beheer je de server niet met losse commando's, maar met één bestand: /etc/nixos/configuration.nix. Daarin staan de gebruikers, de diensten, de firewall en de tijdzone. Het systeem dat je krijgt, volgt uit dat bestand.

Hieronder staat een kleine webserver. Het is een fragment om toe te voegen aan het bestand dat je installatie al heeft. Laat de regels voor de bootloader en de import van hardware-configuration.nix staan zoals ze zijn, want die horen bij jouw schijf en jouw hardware.

{ config, pkgs, ... }:

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

  # De bestaande boot.loader-regels van je installatie blijven hier staan.

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

  users.users.beheer = {
    isNormalUser = true;
    extraGroups = [ "wheel" ];
    openssh.authorizedKeys.keys = [
      "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... beheer@laptop"
    ];
  };

  # Alleen sleutels, dus sudo vraagt geen wachtwoord dat niet bestaat.
  security.sudo.wheelNeedsPassword = false;

  services.openssh = {
    enable = true;
    settings = {
      PasswordAuthentication = false;
      KbdInteractiveAuthentication = false;
      PermitRootLogin = "no";
    };
  };

  services.nginx = {
    enable = true;
    virtualHosts."voorbeeld.nl" = {
      locations."/".return = "200 'NixOS werkt'";
    };
  };

  networking.firewall = {
    enable = true;
    allowedTCPPorts = [ 22 80 443 ];
  };

  system.stateVersion = "26.05";
}

Een paar regels verdienen uitleg. PasswordAuthentication = false en KbdInteractiveAuthentication = false zetten inloggen met een wachtwoord uit. Alleen de sleutel in authorizedKeys komt dan binnen. Zet je eigen publieke sleutel erin voordat je dit toepast. Anders sluit je jezelf buiten. wheelNeedsPassword = false is nodig omdat de gebruiker beheer geen wachtwoord heeft. Zonder die regel vraagt sudo om een wachtwoord dat niet bestaat. Wil je dat liever niet, geef de gebruiker dan als root een wachtwoord met passwd beheer.

Poort 22 staat in de lijst om het expliciet te maken. De SSH-module opent die poort zelf ook al, omdat services.openssh.openFirewall standaard aan staat. Poort 443 staat er alvast in voor TLS (transport layer security). Certificaten van Let's Encrypt regel je later met enableACME = true en forceSSL = true op de virtual host. Daarnaast heb je security.acme.acceptTerms nodig, en een e-mailadres in security.acme.defaults.email.

system.stateVersion is geen versie die je bij elke upgrade ophoogt. Het vertelt NixOS met welke release deze machine is geïnstalleerd, zodat diensten zoals databases hun oude dataformaat houden. Laat die waarde staan.

Elke optie heeft documentatie op search.nixos.org. Daar zie je per optie het type en de standaardwaarde, vaak met een voorbeeld.

Wat doet nixos-rebuild switch?

nixos-rebuild leest de configuratie en bouwt het hele systeem in de store. Daarna activeert het dat systeem. Begin voorzichtig:

sudo nixos-rebuild dry-build
sudo nixos-rebuild test
sudo nixos-rebuild switch

dry-build laat zien wat er gebouwd of gedownload moet worden, zonder iets te activeren. test activeert de nieuwe configuratie direct, maar maakt haar niet de standaard bij het opstarten. Na een herstart zit je dus weer op de vorige versie. switch activeert de configuratie en zet haar bovenaan in het bootmenu.

Elke switch maakt een nieuwe generatie: een genummerde verwijzing naar een compleet systeem in de store. Controleer daarna of de dienst echt draait:

systemctl status nginx
curl -H 'Host: voorbeeld.nl' http://127.0.0.1/

systemctl status hoort active (running) te tonen, en curl hoort de tekst NixOS werkt terug te geven.

Gaat het mis, dan gebeurt dat meestal voordat er iets verandert. Een typfout in de Nix-syntaxis, zoals een vergeten puntkomma, geeft een melding die begint met error: syntax error, unexpected. Een verkeerd gespelde optie, zoals virtualHost in plaats van virtualHosts, geeft een melding dat The option met die naam does not exist. In beide gevallen stopt de build en blijft het draaiende systeem precies zoals het was. NixOS activeert namelijk pas iets als de hele build gelukt is.

Hoe draai je een update terug?

Een generatie verdwijnt niet als je een nieuwe maakt. Daardoor is terugdraaien één commando:

sudo nixos-rebuild switch --rollback

Dat activeert de vorige generatie en maakt die weer de standaard. Alle generaties staan als links in het systeemprofiel:

ls -l /nix/var/nix/profiles/system-*-link

Start de server helemaal niet meer op, dan kies je een oudere generatie in het bootmenu. Bij GRUB staan ze in het submenu NixOS - All configurations. Is die oude generatie goed, maak haar dan weer de standaard:

sudo /run/current-system/bin/switch-to-configuration boot

Op een VPS heb je voor het bootmenu de console van je provider nodig, want SSH draait op dat moment nog niet. Zoek dus uit waar die console zit voordat je haar nodig hebt.

Eén grens is belangrijk. Een rollback zet software en configuratie terug, maar geen data. Een database in /var/lib die door een nieuwe versie naar een nieuw formaat is omgezet, blijft in dat nieuwe formaat. De oude versie kan die bestanden daarna misschien niet meer lezen. Maak voor een grote upgrade dus nog steeds een back-up van je data.

Oude generaties houden hun pakketten in de store, dus /nix groeit. Ruim op met:

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

Dat verwijdert generaties ouder dan dertig dagen, en daarna alle pakketten die niemand meer gebruikt. Je kunt dit ook automatisch laten doen met nix.gc.automatic = true; en nix.gc.options = "--delete-older-than 30d"; in de configuratie. Gebruik nix-collect-garbage -d alleen bewust. Dat verwijdert alle oude generaties, en daarmee ook elke mogelijkheid om terug te gaan.

Channels of flakes: welke kies je?

NixOS heeft twee manieren om vast te leggen welke versie van de pakketverzameling (nixpkgs) je gebruikt. Dat is voor nieuwkomers het meest verwarrende deel.

De klassieke manier is een channel. Dat is een URL die naar een versie van nixpkgs wijst. Controleer en zet hem zo:

sudo nix-channel --list
sudo nix-channel --add https://channels.nixos.org/nixos-26.05 nixos
sudo nixos-rebuild switch --upgrade

Het nadeel: de channel staat op de machine, niet in je configuratie. Twee servers met hetzelfde configuration.nix kunnen dus verschillende pakketversies hebben, omdat hun channel op een ander moment is bijgewerkt.

De nieuwere manier is een flake. Een flake.nix noemt zijn invoer expliciet, en een bijbehorend flake.lock legt de exacte commit vast:

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

  outputs = { self, nixpkgs }: {
    nixosConfigurations.web01 = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [ ./configuration.nix ];
    };
  };
}

Flakes staan officieel nog als experimentele functie in Nix. Je zet ze aan met nix.settings.experimental-features = [ "nix-command" "flakes" ]; in de configuratie. Daarna bouw je met:

sudo nixos-rebuild switch --flake /etc/nixos#web01

Staat de flake in een git-repository, dan ziet Nix alleen bestanden die git kent. Een nieuw bestand dat je nog niet met git add hebt toegevoegd, bestaat voor de build dus niet. Voor één server zijn channels genoeg. Beheer je meerdere servers vanuit één repository, dan is het lockbestand de reden om voor flakes te kiezen.

Wat kost NixOS je?

De Nix-taal. Configuratie schrijf je in een eigen, functionele taal. Eenvoudige instellingen lezen als een lijst met waarden. Zodra je functies of overlays gebruikt, moet je de taal echt leren. Foutmeldingen kunnen lang zijn. Met --show-trace achter nixos-rebuild zie je waar de fout vandaan komt.

Channels en flakes door elkaar in de documentatie. Tutorials en blogposts gebruiken beide methodes, en oude en nieuwe commando's door elkaar. Een voorbeeld van internet werkt daardoor niet altijd in jouw opzet. De documentatie is verspreid over de NixOS-handleiding, de wiki, nix.dev en losse blogs. Controleer altijd voor welke release en welke methode een voorbeeld is geschreven.

Geen standaard bestandsindeling. NixOS volgt de FHS (Filesystem Hierarchy Standard) niet. Er is geen gevulde /usr/lib, en /bin bevat alleen sh. Een script met #!/bin/bash start daarom niet. Gebruik #!/usr/bin/env bash. Een kant-en-klaar binair programma van een website zoekt zijn dynamische linker op een vast pad. Dat pad bevat op NixOS alleen een stub. Je ziet dan Could not start dynamically linked executable, gevolgd door de uitleg dat NixOS zulke programma's niet zomaar kan draaien. De oplossing is nix-ld:

programs.nix-ld.enable = true;
programs.nix-ld.libraries = with pkgs; [ stdenv.cc.cc zlib openssl ];

Daarmee krijgen die programma's een echte linker en de bibliotheken die je opgeeft. Waarom zulke binaries van vaste paden afhangen, en hoe statisch linken dat omzeilt, staat in draagbare Linux-binaries met glibc en musl.

Schijfruimte. Elke generatie houdt haar eigen pakketten vast. Zonder garbage collection loopt een kleine schijf op een VPS na een paar maanden updates vol.

Waarin verschilt NixOS van immutable distro's?

Distributies zoals bootc, Fedora CoreOS, Flatcar en Talos worden vaak samen met NixOS genoemd. Ze werken anders. Die systemen leveren het besturingssysteem als één compleet image. Een update vervangt het hele image in één keer, en bij een probleem start je het vorige image weer op. Wil je iets aanpassen, dan bouw je een nieuw image (bij bootc met een Containerfile), of je geeft bij de eerste start een machineconfiguratie mee. Hoe die image-based aanpak werkt, staat in immutable server-distributies uitgelegd.

NixOS bouwt het systeem uit een beschrijving, pakket voor pakket, op de machine zelf of uit de binary cache. De eenheid van verandering is het store-pad, niet het image. De root-partitie is gewoon beschrijfbaar. Alleen /nix/store is alleen-lezen, en /etc bestaat grotendeels uit gegenereerde links. Beide aanpakken geven atomische updates en rollback. Het verschil zit in waar je de wijziging maakt: in een image-pipeline, of in een tekstbestand dat je in git bewaart.

De DAWO-pagina van BZK op code.overheid.nl noemt naast DAWO-NixOS ook een spoor op basis van Fedora Kinoite, een image-based desktop. De overheid onderzoekt beide modellen dus naast elkaar.

Ook het verschil met Ansible is goed om te kennen. Een Ansible-playbook beschrijft ook een gewenste toestand, maar voert die uit op een systeem dat daarna gewoon veranderlijk blijft. Haal je een taak uit het playbook, dan blijft het pakket op de server staan. Op NixOS verdwijnt een dienst uit de volgende generatie zodra je de regel verwijdert. Wie het Ansible-model wil vergelijken, begint met een eerste Ansible-playbook voor je VPS.

Hoort NixOS op een VPS?

NixOS past goed als je meerdere vergelijkbare servers beheert, of als je wilt dat de configuratie in git ook de documentatie is. Je kunt een configuratie zelfs eerst op je laptop proberen met nixos-rebuild build-vm, dat er een virtuele machine van maakt.

NixOS past minder goed als je software draait die alleen als .deb of .rpm met vaste paden wordt geleverd. Het past ook minder goed als niemand in je team tijd heeft om de Nix-taal te leren. Een server die maar één persoon begrijpt, is een risico. Twijfel je tussen distributies, lees dan eerst welk besturingssysteem je voor je VPS kiest.

SSD Nodes biedt geen NixOS-images aan. Het OS-menu bevat Ubuntu, Debian, CentOS, Rocky Linux, AlmaLinux en Fedora. Er bestaan community-tools die een draaiende Linux-machine omzetten naar NixOS. Het zijn tools van derden, en SSD Nodes ondersteunt ze niet:

• nixos-infect draait op de bestaande distributie en vervangt het root-bestandssysteem door NixOS. De README waarschuwt zelf dat de naam komt van de grote kans dat het systeem onbruikbaar wordt. Het project raadt het alleen aan voor een net aangemaakte server.
• nixos-anywhere maakt via SSH verbinding, start met kexec een NixOS-installer in het geheugen en partitioneert de schijf met disko. De README noemt minstens 1 GB RAM en zegt dat de schijf volledig wordt overschreven.

Beide tools wissen dus de bestaande installatie. Gebruik ze alleen op een lege server. Zorg vooraf voor console-toegang. Ga er ook niet van uit dat ze bij elke provider werken.

Wil je eerst de taal leren zonder je besturingssysteem te vervangen? Installeer dan alleen de pakketbeheerder Nix op je bestaande Ubuntu- of Debian-server. Gebruik het officiële installatiescript in multi-user-modus:

curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install | sh -s -- --daemon

Open daarna een nieuwe shell. nix --version hoort dan een versienummer te tonen. Je kunt zo pakketten uit nixpkgs gebruiken en de store leren kennen, terwijl de server zelf gewoon Ubuntu of Debian blijft.

FAQ

Is NixOS hetzelfde als Nix?

Nee. Nix is de pakketbeheerder en de taal waarin je pakketten en configuratie beschrijft. Nix draait ook op andere Linux-distributies en op macOS. NixOS is een complete Linux-distributie die met Nix is gebouwd. Daarin beschrijf je ook de systeemconfiguratie in Nix, zoals gebruikers en diensten.

Kan ik NixOS terugdraaien als een update mijn server breekt?

Ja. Elke nixos-rebuild switch maakt een nieuwe generatie, en sudo nixos-rebuild switch --rollback activeert de vorige. Start de server niet meer, kies dan een oudere generatie in het bootmenu via de console van je provider. Een rollback zet software en configuratie terug, maar geen data. Databases die naar een nieuw formaat zijn omgezet, blijven in dat formaat.

Waarom start een gedownload Linux-programma niet op NixOS?

Een kant-en-klaar binair programma verwacht zijn dynamische linker en bibliotheken op standaardpaden zoals /lib64 en /usr/lib. NixOS zet alles in /nix/store. Die paden zijn dus leeg of bevatten een stub, en je ziet Could not start dynamically linked executable. Zet programs.nix-ld.enable = true; aan en noem de benodigde bibliotheken in programs.nix-ld.libraries. Je kunt ook een versie van het programma uit nixpkgs gebruiken.

Moet ik beginnen met channels of met flakes?

Voor één server zijn channels het eenvoudigst. nix-channel wijst naar een release zoals nixos-26.05, en nixos-rebuild switch --upgrade werkt het systeem bij. Beheer je meerdere servers vanuit git, dan leggen flakes met hun flake.lock de exacte versie van nixpkgs vast, zodat elke server hetzelfde bouwt. Flakes zijn officieel nog experimenteel en moeten met nix.settings.experimental-features worden aangezet.

Kan ik NixOS draaien op een VPS van SSD Nodes?

SSD Nodes biedt geen NixOS-image aan. Het OS-menu bevat Ubuntu, Debian, CentOS, Rocky Linux, AlmaLinux en Fedora. Community-tools zoals nixos-infect en nixos-anywhere kunnen een draaiende Linux-machine omzetten. Het zijn tools van derden die de bestaande installatie wissen, en niemand garandeert dat ze bij een bepaalde provider werken. Wil je alleen Nix leren, installeer dan de pakketbeheerder Nix op je bestaande Ubuntu- of Debian-server.