Docker is zo dominant geworden dat "container" en "Docker" als synoniemen worden gebruikt. Maar het ecosysteem is rijker. Incus brengt systeemcontainers terug als volwassen alternatief voor lichte virtualisatie. Firecracker maakt van elke Lambda-functie een aparte microVM. Podman heeft zoveel architecturale keuzes anders gemaakt dat het nauwelijks nog een kloon is. Dit artikel kijkt naar wat die drie runtimes écht anders doen — en voor wie.

Hoe Docker domineerde (en waarom dat niet vanzelfsprekend was)

Docker verscheen in 2013 als een dunne schil rond Linux cgroups en namespaces. Wat het toevoegde was het image-formaat: gelaagde, overdraagbare snapshots die je kon bouwen, pushen en pullen via een registry. Dat, plus een begrijpelijke CLI, maakte containertechnologie toegankelijk voor ontwikkelaars die nooit eerder een chroot hadden geconfigureerd.

In 2015 richtten Docker en andere partijen de Open Container Initiative (OCI) op om een open standaard te definiëren voor images en runtimes. Het gevolg: elke image die je vandaag bouwt met Docker, werkt ook in Podman, Incus of Kubernetes via containerd. De standaard is gemeengoed; Docker is één implementatie. De alternatieven concurreren niet op imageformaat — dat is gestandaardiseerd — maar op architectuur, beveiligingsmodel en doelgroep.

"De OCI-standaard heeft het containerecosysteem bevrijd van vendor lock-in. Docker bouwt images, maar het hoeft ze niet te draaien."

Incus: systeemcontainers als serieuze LXD-opvolger

Om Incus te begrijpen, moet je het onderscheid tussen applicatiecontainers en systeemcontainers kennen. Docker draait applicatiecontainers: één proces per container, minimale rootfs, geen init-systeem. Een systeemcontainer — het domein van Incus — is conceptueel iets anders: het is een volledig Linux-systeem dat geïsoleerd draait, inclusief systemd, een netwerk-stack, eigen /etc en meerdere processen. Denk aan het als een lichtgewicht VM zonder de overhead van een echte hypervisor.

Incus is een community-fork van LXD, ontstaan in augustus 2023 nadat Canonical besloot LXD van de Linux Containers-organisatie over te hevelen naar hun eigen GitHub-organisatie en de maintainership te beperken tot eigen medewerkers. Stéphane Graber, de vroegere lead van het LXD-project, verhuisde mee naar Incus. Het resultaat is een project dat technisch voortbouwt op LXD maar los staat van Canonicals productplanning.

Incus 6.0 verscheen in april 2024 als LTS-release met ondersteuning tot juni 2029. De maandelijkse feature-releases bouwen er bovenop. Wat Incus onderscheidt van Docker:

  • Volledige systemd-ondersteuning. Binnen een Incus-container draait systemd als PID 1. Je kunt services installeren, inschakelen en beheren net als op een echte server. Dat maakt Incus geschikt voor scenario's waarbij je een complete dienst wil isoleren zonder een volledige VM op te starten — denk aan een mailserver, een DNS-resolver of een legacy-applicatie die een volledige OS-omgeving verwacht.
  • VM-integratie naast containers. Incus beheert niet alleen containers maar ook volledige virtuele machines via de zelfde CLI en hetzelfde API. Je kunt incus launch ubuntu:24.04 mijnserver --vm uitvoeren voor een echte VM, of hetzelfde commando zonder --vm voor een systeemcontainer. Voor een homelab of kleine cloudprovider is dat architecturaal elegant: één tool, twee isolatieniveaus.
  • Systemd-credentials. Recente Incus-releases voegen configuratiesleutels toe als systemd.credential.XYZ om via systemd's credential-mechanisme veilig data door te geven aan containerprocessen — iets wat in Docker omslachtig gaat via environment-variabelen of volume-mounts met secrets.

Wanneer kies je voor Incus? Als je een "kale server"-ervaring wil binnen een geïsoleerde omgeving: meerdere daemons draaien, een volledige pakketbeheerder gebruiken, netwerk-interfaces configureren. Docker is dan ongeschikt omdat het geen init-systeem heeft en moeilijk doet over processen die in de achtergrond draaien. Een VM is zwaarder dan nodig. Incus zit daar precies tussenin.

Firecracker: VM-grade isolatie op container-snelheid

Firecracker is een open-source microVM-monitor, geschreven in Rust en ontwikkeld door Amazon Web Services. Het draait op KVM — de virtualisatie-extensies die in elke moderne CPU zitten — maar schrapt alles wat QEMU meesleept. Geen BIOS, geen UEFI, geen emulatie van een grafische kaart of geluidskaart. De enige emulated devices zijn: een virtio-netwerkkaart, een virtio-blokschijf, een virtio-vsock, een seriële console en een minimale toetsenbordcontroller voor shutdown-signalen. Dat is het.

Het resultaat is indrukwekkend in de cijfers: een Firecracker microVM start in 125 milliseconden, gebruikt minder dan 5 MB aan overhead, en op één host kun je tot 150 microVMs per seconde aanmaken. Firecracker powers AWS Lambda en AWS Fargate; elke Lambda-aanroep start een verse microVM. De codebase telt 50.000 regels Rust — tegenover meer dan 1,4 miljoen regels voor QEMU. Kleiner codepakket, kleiner aanvalsoppervlak.

Het kernverschil met Docker is isolatieniveau. Een Docker-container deelt de kernel van de host — wie die kernel exploiteert, zit op de host. Een Firecracker microVM heeft een eigen kernel; de aanvaller moet twee grenzen doorbreken. Die hypervisor is geschreven in Rust, met een geheugenbeveiliging die C-code niet biedt.

Kata Containers bouwt daar een laag bovenop. Waar Firecracker puur een microVM-monitor is — jij regelt de orkestratie — koppelt Kata Containers Firecracker (of QEMU, of Cloud Hypervisor) aan de Kubernetes Container Runtime Interface. Je deployt een Kubernetes-pod, Kata start stilletjes een microVM voor die pod en presenteert die als gewone container aan de scheduler. Vanuit operationeel perspectief is het transparant; vanuit beveiligingsperspectief heb je per pod een volledige kernel-grens.

De praktische keerzijde: Firecracker vereist KVM, dus een host die virtualiseert. In een virtuele machine op een cloud-provider werkt het alleen als die provider geneste virtualisatie toestaat — dat doen AWS, Azure en GCP inmiddels, maar niet overal standaard. En Firecracker is geen vervanging voor een container-workflow; het is een isolatieprimitief dat bovenop een orkestrator zoals Kubernetes of Nomad wordt gelegd.

Drie runtimes op een rij
RuntimeIncus · Podman · Firecracker
TypeSysteemcontainer + VM · Applicatiecontainer · MicroVM
Kernel gedeeldJa (container) / Nee (VM) · Ja · Nee
Init-systeemVolledig systemd · Geen · Eigen gast-kernel
Opstarttijd~1–2 s · ~180 ms · ~125 ms
OCI-imagesOptioneel (via LXC) · Ja · Nee
Kubernetes-integratieBeperkt · Via CRI · Via Kata Containers
Ideaal voorHomelab, legacy-apps · Rootless CI/CD · Multitenant serverless

Waar Podman al half gewonnen heeft

Podman is het alternatief dat het meeste terrein heeft gewonnen in productieomgevingen — en het is interessant te kijken waarom. CLI-compatibiliteit met Docker is één factor: podman run, podman build en podman push werken identiek. Maar de echte reden is het architectuurverschil dat Red Hat van meet af aan maakte: geen daemon.

Podman is daemonless. Wanneer je een container start, is het een directe kindproces van je shell. Geen geprivilegieerde achtergrondservice, geen Unix-socket die root-equivalent toegang geeft aan iedereen in de docker-groep. Containers draaien standaard als de gebruiker die ze start. Op een multiuser-server is dat een significante beveiligingswinst: een gecompromitteerde container heeft niet automatisch escalatie-mogelijkheden richting andere gebruikers of de host.

Podman 5's grootste praktische toevoeging is Quadlet, de native systemd-integratie. Je schrijft een .container-bestand — vergelijkbaar met een Compose-service, maar in systemd-stijl — en legt het in ~/.config/containers/systemd/. Systemd genereert bij de volgende daemon-reload automatisch de unit-files. Auto-update is ingebouwd: zet AutoUpdate=registry in het bestand en een systemd-timer controleert periodiek of de registry een nieuwer image heeft. Geen Watchtower als aparte container naast je andere containers.

Op FOSDEM 2025 presenteerde het Podman-team uitbreidingen voor Quadlet: application grouping, automatische systemd-reload bij wijzigingen, en JSON-output voor CI/CD. Red Hat positioneert Podman als de standaard productie-runtime voor niet-Kubernetes workloads op RHEL en Fedora.

Toch heeft Podman twee zwakke punten. podman-compose is een community-project dat Docker Compose v2 niet volledig implementeert: health check-condities bij depends_on ontbreken en netwerknamen worden anders afgehandeld. Wie bestaande Compose-bestanden migreert, stoot op kleine verschillen die tijd kosten. En de bulk van container-how-tos op internet veronderstelt nog steeds Docker.

Containerd en CRI-O: de stille laag eronder

In productie-Kubernetes-clusters draaien de meeste workloads vandaag niet op Docker, maar op containerd of CRI-O. Dat zijn laag-niveau runtimes die de Kubernetes Container Runtime Interface implementeren en containers starten zonder de gebruiksvriendelijke CLI-laag van Docker of Podman.

Containerd — oorspronkelijk de kern van Docker, nu een zelfstandig CNCF-project — is de standaard in managed diensten als EKS, GKE en AKS. CRI-O is de runtime in Red Hat OpenShift en koppelt zijn versienummering één-op-één aan Kubernetes. Voor een homelab zijn dit niet de tools die je direct aanraakt, maar als je Kubernetes draait, is de "container runtime" onder je pods vrijwel nooit meer Docker.

Veelgestelde vragen

Kan ik bestaande Docker-images draaien in Podman?
Ja, volledig. Alle OCI-conforme images werken zonder aanpassingen — pull gewoon van docker.io of een andere registry. Incus heeft OCI-imageondersteuning toegevoegd, maar gebruikt van oudsher zijn eigen imageserver voor systeemcontainers. Firecracker gebruikt geen OCI-images; het verwacht een kernel en rootfs die je apart inricht.
Is Podman klaar voor productie?
Ja. Red Hat gebruikt Podman als standaardruntime in RHEL 8 en hoger. De Quadlet-integratie met systemd is stabiel vanaf Podman 4.4. Voor complexe Compose-workflows met depends_on-health checks is testen aangeraden voordat je volledig omschakelt.
Wanneer kies ik Firecracker boven een gewone container?
Wanneer je per workload een harde kernel-grens nodig hebt — multitenant CI, serverless-platforms, of code van derden uitvoeren. Firecracker is geen vervanging voor Docker-workflows op je laptop; het is een isolatieprimitief voor situaties waar gedeelde kernel een risico is.
Kan ik Podman en Docker naast elkaar draaien?
Ja. Ze delen geen daemon en gebruiken aparte image-stores. Podman slaat op in ~/.local/share/containers/; Docker in /var/lib/docker/. Kies per project één tool om verwarring te vermijden.