Twee jaar geleden zette ik mijn eerste homelab-services over van Docker naar Podman. Sommige containers draaiden meteen vlekkeloos. Andere vergden drie avonden debuggen over UIDs, poorten en een ontbrekend loginctl enable-linger. Dit artikel is wat ik zelf had willen lezen voor ik begon: eerlijk over waar Podman beter is, eerlijk over waar Docker gewoon minder gedoe geeft.
Wat er anders is onder de motorkap
Het fundamentele verschil tussen Docker en Podman is architecturaal. Docker werkt met een centrale daemon — dockerd — die als achtergrondproces draait met rootrechten. Elke opdracht die je typt, praat met die daemon via een Unix-socket. Podman heeft geen daemon. Wanneer je podman run uitvoert, start het een containerproces als direct kind van je eigen shell. Geen persistente service, geen geprivilegieerde socket.
In de praktijk betekent dat twee dingen. Eén: elke container erft de rechten van de gebruiker die hem gestart heeft. Draai je Podman als gewone gebruiker, dan heeft de container nooit meer privileges dan jij. Twee: als Podman crasht of je sluit je terminal, stoppen de containers niet automatisch — tenzij je ze expliciet onder systemd hebt gehangen, wat Podman aanmoedigt via Quadlet.
Docker heeft rootless ondersteuning later toegevoegd, maar het is niet de standaardinstelling. Op een standaard Ubuntu-installatie draait dockerd als root en heeft de docker-groep effectief root-equivalent toegang. Je kunt dat aanpassen, maar het vraagt extra configuratie die buiten de standaard documentatie valt.
Waar Podman wint
Het sterkste argument voor Podman is veiligheid door standaardinstellingen. Containers krijgen bij Podman standaard 11 kernel capabilities; Docker geeft er 14. Dat klinkt technisch, maar het verschil is concreet: NET_ADMIN en SYS_MODULE zitten in Dockers standaard capability set, niet in Podman's. Kleine aanvalsoppervlakte als startpunt, niet als optie.
Het tweede voordeel is Quadlet, Podmans integratie met systemd. Sinds Podman 4.4 kun je containers beschrijven in eenvoudige .container-bestanden die je in ~/.config/containers/systemd/ plaatst. Systemd leest die bij boot en genereert automatisch de bijbehorende unit-files. Een simpel voorbeeld voor een Jellyfin-instantie:
[Unit]
Description=Jellyfin mediaserver
[Container]
Image=docker.io/jellyfin/jellyfin:latest
Volume=/mnt/media:/media:z
PublishPort=8096:8096
AutoUpdate=registry
[Service]
Restart=always
[Install]
WantedBy=default.targetSla dat op als ~/.config/containers/systemd/jellyfin.container, draai systemctl --user daemon-reload en start met systemctl --user start jellyfin. Podman beheert het herstarten, de auto-updates en de volgorde van opstarten. Geen aparte docker-compose up -d in een crontab, geen rc.local-hacks. En met podman auto-update controleer je actief of de registry een nieuwer image heeft voor de tag die je gebruikt.
Het derde voordeel: Podman is volledig open source onder Apache 2.0, zonder enterprise-restricties. Docker Desktop introduceerde in 2022 een betalingsplicht voor organisaties met meer dan 250 medewerkers of meer dan tien miljoen dollar omzet. Docker Engine zelf blijft gratis, maar Docker Desktop — de grafische tool die macOS- en Windows-gebruikers bijna onvermijdelijk nodig hebben — valt daar niet meer onder. Voor een thuisgebruiker maakt dat weinig uit, maar als je thuis dezelfde toolchain wil als op je werk, kan die licentiedrempel een rol spelen.
"Podman heeft geen daemon nodig — wat betekent dat er niets draait, niets geheugen gebruikt en niets crasht als er geen containers actief zijn."
Waar Docker nog wint
Eerlijkheid verplicht: Docker is voor heel wat thuisgebruikers nog steeds de betere keuze, en wel om drie redenen.
Ecosysteem en documentatie. Zoek je een how-to voor het opzetten van een Nextcloud, Vaultwarden of Home Assistant container, dan staat er bijna altijd een docker-compose.yml klaar. Podman leest die bestanden ook — ofwel via podman-compose, ofwel via podman compose dat tegenwoordig Docker Compose als backend kan aansturen — maar je stoot sneller op randgevallen die in tutorials niet behandeld worden. Dat kost tijd.
Snelheid bij image-operaties. Docker is gemiddeld tien tot vijftien procent sneller bij container-starts en image-pulls, voornamelijk omdat de daemon al in het geheugen zit en niet elke keer opnieuw de overlay-mounts hoeft te initialiseren. Voor een homelab merk je dat verschil nauwelijks, maar voor CI-pipelines waar je tientallen containers per uur start, telt het.
Docker Compose v2 pariteit. podman-compose is een community-project, niet het officiële Podman-team. Het implementeert een subset van de Docker Compose v2-specificatie. Concreet: depends_on met health check-condities werkt niet volledig, netwerknamen worden anders afgehandeld (Docker verwijdert koppeltekens, Podman behoudt ze), en container-namen volgen een ander patroon (project-service-1 versus project_service_1). Kleine verschillen, maar ze beken in bestaande scripts.
Docker vs Podman — snel vergelijken
De migratiepijn: wat je écht tegenkomt
Als je bestaande Docker-setup naar Podman wil brengen, zijn dit de hobbels die je met zekerheid tegenkomt:
Poorten onder 1024. Als rootless gebruiker mag je standaard geen poorten binden onder poortnummer 1024. Draai je een webserver op poort 80 of 443, dan geeft Podman een permission denied-fout. De snelle oplossing:
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80Maak dat permanent door de regel toe te voegen aan /etc/sysctl.d/99-podman-ports.conf. Alternatief: gebruik een reverse proxy zoals Caddy of Nginx Proxy Manager die op poort 80/443 luistert als root-service, en laat je containers op hogere poortnummers draaien.
Volume-permissies en SELinux. Volumes in rootless Podman mappen UIDs anders dan Docker. Een bestand dat root aanmaakt binnen een container is op de host eigendom van een subUID — niet van jouw gebruiker. Op Fedora, RHEL of CentOS Stream speelt ook SELinux een rol: voeg :z (gedeeld label) of :Z (privé-label) toe aan je volume-mount, anders krijg je Permission denied zonder duidelijke foutmelding.
# Zonder :Z — werkt mogelijk niet op SELinux-systemen
-v /home/user/data:/data
# Met :Z — geeft de container schrijftoegang
-v /home/user/data:/data:ZContainers overleven logout niet. Rootless Podman-containers stoppen wanneer je uitlogt, tenzij je linger inschakelt voor je gebruiker:
loginctl enable-linger $USERDit is de meest vergeten stap in elke migratiegids. Zonder deze regel starten je Quadlet-services niet bij reboot en stoppen ze zodra je ssh-verbinding wegvalt.
DNS-verschillen. Docker biedt aan elk container-netwerk een interne DNS-resolver op 127.0.0.11. Podman doet iets vergelijkbaars maar op een ander adres. Containers die dat Docker-adres hardcoded hebben staan — ongebruikelijk maar het bestaat — werken na migratie niet meer. Controleer je images op hardcoded DNS-verwijzingen als je vreemde netwerk-issues krijgt.
Praktisch advies per profiel
Je draait een stuk of vijf services op een thuisserver (NAS, Home Assistant, Vaultwarden, Jellyfin). Begin met Podman als je op Linux zit. De Quadlet-integratie is een duidelijke stap vooruit ten opzichte van docker-compose up in een crontab, en auto-updates werken zonder Watchtower. Verwacht twee à drie uur migratietijd voor een gemiddelde setup: poortconfiguratie, linger instellen, volumes testen. Daarna heb je weinig onderhoud meer.
Je gebruikt Docker Desktop op macOS of Windows en werkt mee aan projecten van anderen. Blijf bij Docker Desktop tenzij je een concrete reden hebt om te wisselen. Podman Desktop werkt goed, maar de brug naar Docker-socket-compatibele tooling (sommige IDE-plugins, Testcontainers, Orbstack-alternatieven) is soms wrikken. Als je organisatie voor Docker betaalt, is er helemaal geen reden.
Je zet een nieuwe homelab op van nul. Kies Podman. De leercurve is dezelfde als Docker — bijna alle commando's zijn identiek, je kunt een alias zetten met alias docker=podman en de meeste tutorials werken gewoon. Je leert meteen de betere gewoontes: rootless, systemd-integratie, geen daemon-afhankelijkheid. Over vijf jaar ben je blij dat je het zo hebt gebouwd.
Je beheert gedeelde CI/CD-omgevingen of complexe multi-container stacks. Docker heeft hier nog een voorsprong. De officiële Compose v2-specificatie, de brede integratie met GitLab, GitHub Actions en Jenkins, en de stabielere Compose-implementatie maken Docker betrouwbaarder in omgevingen waar veel mensen samenwerken aan dezelfde toolchain. Podman haalt die achterstand in, maar is er nog niet volledig.
Veelgestelde vragen
Kan ik Docker-images gebruiken in Podman? Ja, volledig. Podman gebruikt dezelfde OCI-imagestandaard. podman pull nginx haalt hetzelfde image op als docker pull nginx. Je kunt ook docker.io/library/nginx specificeren als volledig pad; Podman vraagt anders welk register je bedoelt.
Werkt mijn bestaande docker-compose.yml in Podman? Grotendeels wel, maar test het altijd. Kleine syntaxverschillen in netwerknamen en container-naamgeving kunnen scripts die op die namen vertrouwen breken. De eenvoudigste test: podman compose up -d en kijk wat er klaagt. Alternatieven zijn podman-compose (pip install podman-compose) of het omzetten naar Quadlet-bestanden voor productiepersistentie.
Is Podman klaar voor productie? Red Hat gebruikt het als standaard containerruntime op RHEL 8 en 9. Als dat niet genoeg referentie is: de meeste enterprise Linux-distributies die Docker vervangen, kiezen Podman. Voor thuisgebruik is de vraag niet relevant — het is meer dan stabiel genoeg.
Wat is het verschil tussen podman generate systemd en Quadlet? podman generate systemd is de oude methode: je genereert handmatig een unit-file vanuit een bestaande container. Quadlet is de nieuwe aanpak: je schrijft een declaratief .container-bestand en systemd genereert de unit automatisch bij daemon-reload. Quadlet is de aanbevolen methode vanaf Podman 4.4; generate systemd is deprecated.
