Docker vs Podman: Der ehrliche Vergleich mit eigenen Messwerten (2026)

Docker vs Podman ist eine der häufigsten Fragen, sobald man Container ernsthaft auf einem Server betreibt. Beide Werkzeuge starten dieselben Images, verstehen fast dieselben Befehle und landen am Ende beim selben Linux-Kernel. Der Unterschied liegt darunter: Docker arbeitet mit einem zentralen Hintergrunddienst, der als root läuft. Podman kommt ohne diesen Dienst aus und startet Container auf Wunsch komplett ohne Root-Rechte. Das klingt nach einem Detail, verändert aber, wie sicher, wie sparsam und wie bequem dein Server ist.

Wir betreiben auf unserem Entwicklungsserver seit Monaten Docker mit einem halben Dutzend dauerhaft laufender Container. Für diesen Artikel haben wir Podman direkt daneben installiert und beide unter identischen Bedingungen gemessen: Startzeit, Speicherbedarf pro Container, den Dauerverbrauch des Docker-Dienstes, das Verhalten ohne Root-Rechte, Compose und die systemd-Integration. Dabei sind uns zwei Fallen begegnet, die in keinem Werbevergleich stehen. Du bekommst hier also einen Docker-vs-Podman-Vergleich mit Zahlen statt Meinungen, und am Ende eine klare Empfehlung, wann du welches Werkzeug nehmen solltest.

Das Video von IBM Technology (englisch) erklärt in wenigen Minuten die Grundidee hinter Podman. Red Hat gehört zu IBM und entwickelt Podman maßgeblich. Das Video ist also keine neutrale Stimme, erklärt die Architektur aber sauber. Unsere eigenen Messungen folgen weiter unten.

Docker vs Podman: die kurze Antwort

Wenn du nur drei Sätze mitnehmen willst:

• Für Einsteiger und für die meisten Tutorials ist Docker die entspanntere Wahl. Fast jede Anleitung, jedes Compose-Beispiel und jede Fehlermeldung im Netz bezieht sich auf Docker. Du kommst schneller ans Ziel.
• Für einen Server, auf dem Sicherheit Vorrang hat, ist Podman die bessere Grundlage. Kein Dienst mit Root-Rechten, Container laufen als normaler Benutzer, und die Anbindung an systemd ist ab Werk eingebaut.
• Wechseln ist kein großes Projekt. Beide nutzen das OCI-Image-Format. Ein Image, das mit Docker gebaut wurde, läuft unter Podman unverändert, und die meisten Befehle sind identisch.

Wenn du noch nicht genau weißt, was ein Container überhaupt ist, lies zuerst unseren Grundlagenartikel Was ist Docker?. Dort erklären wir Images, Container und Volumes von vorne.

Was ist Podman überhaupt?

Podman steht für Pod Manager. Es ist ein Open-Source-Werkzeug, das maßgeblich von Red Hat entwickelt wird, um Container ohne zentralen Dienst zu verwalten. Auf Fedora, RHEL, CentOS Stream und AlmaLinux ist Podman vorinstalliert. RHEL liefert Docker gar nicht mehr mit, dort ist Podman die offizielle Container-Lösung. Auf Ubuntu und Debian liegt Podman als ganz normales Paket bereit, ein apt install podman genügt.

Der Name verrät eine Besonderheit: Podman kennt Pods, also Gruppen von Containern, die sich ein Netzwerk teilen. Das Konzept stammt aus Kubernetes. Docker hat nichts Vergleichbares. Du brauchst Pods nicht, um Podman zu benutzen, aber sie sind praktisch, wenn du später einmal nach Kubernetes umziehen willst.

Die wichtigste Designentscheidung ist aber eine andere: Podman hat keinen Daemon. Jeder Befehl startet den Container direkt und beendet sich danach. Warum das wichtig ist, sehen wir im nächsten Abschnitt.

Der Kernunterschied: Daemon oder daemonlos

Wenn du docker run eingibst, startet der Befehl docker den Container nicht selbst. Er schickt eine Anfrage an den Docker-Daemon dockerd, einen Dienst, der dauerhaft im Hintergrund läuft. dockerd gibt die Aufgabe an containerd weiter, und das startet für jeden Container einen kleinen Hilfsprozess namens containerd-shim. Erst der startet den eigentlichen Prozess.

Bei Podman fehlt die obere Hälfte dieser Kette. Der Befehl podman startet den Container selbst und übergibt ihn an einen winzigen Wächterprozess namens conmon. Danach beendet sich podman. Es gibt keinen Dienst, der permanent läuft und alle Container zusammenhält.

Genau das haben wir auf unserem Server nachgesehen. Wir haben mit beiden Werkzeugen denselben Test-Container gestartet (alpine, der nur sleep ausführt) und dann geschaut, wer eigentlich der Elternprozess ist:

Docker:  containerd-shim-runc-v2  (Elternprozess PID 1)  →  sleep 600
Podman:  conmon                   (Elternprozess systemd) →  sleep 600

Beide Container laufen, beide sehen von innen gleich aus. Der Unterschied liegt in dem, was sonst noch mitläuft.

Was das für den Speicher bedeutet

Wir haben den tatsächlichen Speicherverbrauch gemessen, und zwar als PSS (Proportional Set Size). PSS rechnet Speicher, den sich mehrere Prozesse teilen, anteilig zu. Das ist ehrlicher als die übliche RSS-Zahl, die geteilte Bibliotheken bei jedem Prozess voll zählt.

Der Hilfsprozess pro Container ist bei Podman also rund 15-mal kleiner. Viel wichtiger ist aber die zweite Zeile. Unser dockerd läuft seit 89 Tagen ohne Neustart und belegt inzwischen rund 233 MB Arbeitsspeicher, containerd noch einmal 46 MB. Zusammen fast 280 MB, die permanent reserviert sind, egal ob gerade ein Container läuft oder nicht.

Ehrlich eingeordnet: Auf unserem Server mit 23 GB RAM ist das kaum ein Prozent und völlig egal. Auf einem kleinen VPS mit 1 oder 2 GB sieht die Rechnung anders aus. Dort sind 280 MB ein spürbarer Teil des Budgets. Wie viel Speicher ein Server wirklich braucht, haben wir in Wie viel RAM braucht ein Server? ausführlich gemessen. Außerdem ist die Zahl für dockerd eine Momentaufnahme nach 89 Tagen Laufzeit mit vielen gebauten Images. Ein frisch gestarteter Dienst ist deutlich kleiner. Wir haben ihn für diesen Artikel bewusst nicht neu gestartet, weil darauf Testumgebungen laufen.

Was das für die Ausfallsicherheit bedeutet

Der zentrale Dienst ist nicht nur ein Speicherposten, er ist auch ein gemeinsamer Ausfallpunkt. Wird dockerd neu gestartet, etwa bei einem Update, stoppt Docker standardmäßig alle Container mit. Es gibt dafür eine Option namens Live Restore, die Container über einen Daemon-Neustart hinweg am Leben hält. Auf unserem Server ist sie, wie bei den meisten Standardinstallationen, ausgeschaltet (docker info zeigt Live Restore Enabled: false).

Bei Podman gibt es dieses Problem nicht, weil es nichts gibt, was man neu starten müsste. Ein Podman-Update berührt laufende Container nicht, jeder hängt nur an seinem eigenen conmon.

Startzeit: praktisch gleichauf

Oft liest man, Podman sei schneller oder langsamer als Docker. Wir haben es gemessen: jeweils fünf Durchläufe von run --rm alpine true, also Container erzeugen, starten, beenden und löschen. Das Image lag bei beiden bereits lokal vor.

*Beim ersten Docker-Durchlauf fehlte das Image mit dem Tag latest noch lokal und wurde heruntergeladen. Der Wert ist deshalb nicht vergleichbar.

Das Ergebnis: Docker als root liegt bei etwa 0,5 Sekunden, Podman als root bei etwa 0,7 Sekunden, und Podman ohne Root-Rechte bei etwa 0,48 Sekunden. Dass ausgerechnet die rootless-Variante am schnellsten war, hat uns selbst überrascht. Wir vermuten, dass der Unterschied am Netzwerk-Backend und an der Größe des Speicherverzeichnisses liegt: Der Root-Podman nutzt netavark mit eigenen Firewallregeln, der Test-Benutzer hatte ein leeres, frisches Verzeichnis. Das ist aber eine Vermutung, keine Messung.

Die ehrliche Zusammenfassung: Für die Frage Docker oder Podman spielt die Startzeit keine Rolle. Die Unterschiede liegen im Bereich von Zehntelsekunden, und das bei einem Vorgang, den du im Alltag selten tausendfach hintereinander ausführst.

Rootless: der wichtigste Grund für Podman

Jetzt kommt der Punkt, der den Docker-vs-Podman-Vergleich eigentlich entscheidet: Wer ist der Container aus Sicht des Servers?

Bei einer normalen Docker-Installation läuft der Daemon als root. Die Prozesse in deinen Containern laufen, sofern das Image nichts anderes festlegt, ebenfalls als root. Wir haben es nachgesehen: Unser Docker-Test-Container mit sleep erscheint in der Prozessliste des Servers als Benutzer root.

Dazu kommt ein Detail, das viele unterschätzen. Wer Docker-Befehle ohne sudo ausführen will, wird üblicherweise in die Gruppe docker aufgenommen. Diese Gruppe darf auf den Socket /var/run/docker.sock zugreifen. Auf unserem Server sieht das so aus:

srw-rw---- 1 root docker 0 /var/run/docker.sock

Wer auf diesen Socket schreiben darf, kann einen Container starten, der das komplette Dateisystem des Hosts einbindet. Die Mitgliedschaft in der Gruppe docker ist deshalb gleichbedeutend mit Root-Rechten, das sagt auch die offizielle Docker-Dokumentation. Auf unserem Server ist die Gruppe übrigens leer, weil wir als root arbeiten. Auf vielen Entwicklerrechnern und Servern ist sie das nicht.

So sieht rootless in der Praxis aus

Für den Test haben wir einen frischen, normalen Benutzer ohne jede Sonderberechtigung angelegt. Beim Anlegen trägt Ubuntu automatisch einen Bereich von 65.536 Unter-IDs in /etc/subuid und /etc/subgid ein. Genau diese brauchen rootless Container.

Dann haben wir als dieser Benutzer einen Container gestartet und darin id ausgeführt:

Auf dem Host:        uid=5002(pvdtest)
Im Container:        uid=0(root) gid=0(root)

Im Container hält sich der Prozess für root. Er darf dort Pakete installieren, Dateien anlegen, alles, was root eben darf. Aber was sieht der Server? Wir haben die Zuordnung mit podman unshare cat /proc/self/uid_map ausgelesen:

         0       5002          1
         1     231072      65536

Die erste Zeile heißt: root im Container ist in Wirklichkeit Benutzer 5002 auf dem Host, also unser ganz normaler Testbenutzer. Alle anderen Benutzer im Container werden auf den Bereich ab 231.072 abgebildet, der keinem echten Benutzer gehört. Und die Prozessliste des Servers bestätigt es: Der sleep-Prozess läuft als pvdtest, nicht als root.

Das ist der ganze Trick. Bricht ein Angreifer aus einem rootless Container aus, landet er nicht als root auf deinem Server, sondern als ein unprivilegierter Benutzer. Das ersetzt keine anderen Schutzmaßnahmen, macht einen erfolgreichen Ausbruch aber deutlich weniger schlimm.

Die Falle: Ports unter 1024

Rootless hat einen Preis, und wir sind prompt hineingelaufen. Der Versuch, als normaler Benutzer einen Container auf Port 80 zu veröffentlichen, endete so:

Error: rootlessport cannot expose privileged port 80, you can add
'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf
(currently 1024), or choose a larger port number (>= 1024)

Linux erlaubt normalen Benutzern keine Ports unter 1024. Das gilt auch für rootless Container. Port 8099 funktionierte sofort. Für einen Webserver hast du drei Möglichkeiten:

1. Einen Reverse Proxy davorsetzen, der als Systemdienst auf 80 und 443 lauscht und an den hohen Port weiterleitet. Das ist ohnehin die saubere Lösung, siehe Was ist ein Reverse Proxy?. Welcher Proxy sich dafür eignet, vergleichen wir in Caddy vs Nginx.
2. Die Grenze per sysctl absenken, wie es die Fehlermeldung vorschlägt. Das ist systemweit und gilt dann für alle Benutzer.
3. Den Container doch als root starten. Dann verlierst du den Hauptvorteil.

Rootless gibt es auch bei Docker

Fairerweise: Docker kann inzwischen auch rootless laufen. Dafür installierst du einen separaten Docker-Daemon im Benutzerkontext. Das funktioniert, ist aber ein zusätzlicher Einrichtungsschritt, und ein Daemon läuft dann trotzdem, nur eben pro Benutzer. Bei Podman ist rootless der Normalfall, nicht die Ausnahme. Das ist der eigentliche Unterschied: nicht was möglich ist, sondern was passiert, wenn du nichts extra konfigurierst.

Die Firewall-Frage

Einen Punkt aus unserem Docker-Compose-Artikel müssen wir hier aufgreifen, weil er Einsteiger regelmäßig erwischt: Docker trägt veröffentlichte Ports direkt in die iptables-Regeln des Kernels ein und umgeht damit eine Firewall wie ufw. Ein -p 5432:5432 macht deine Datenbank für das ganze Internet erreichbar, auch wenn ufw den Port angeblich sperrt.

Auf unserem Server binden deshalb alle sechs laufenden Docker-Container ihre Ports ausdrücklich an 127.0.0.1. Das haben wir mit docker ps für diesen Artikel noch einmal geprüft.

Podman als root nutzt mit netavark ebenfalls eigene Firewallregeln und verhält sich hier ähnlich. Rootless Podman dagegen leitet Ports über einen Prozess im Benutzerkontext weiter (in unserer Version rootlessport mit slirp4netns oder pasta). Diese Weiterleitung ist ein ganz normaler Socket, den die Host-Firewall sieht. Unsere Empfehlung gilt aber für beide Werkzeuge gleich: Ports, die nicht öffentlich sein müssen, immer an 127.0.0.1 binden. Verlass dich nicht darauf, dass eine Firewall das für dich regelt.

Befehle: fast identisch

Die gute Nachricht für alle, die von Docker kommen: Podman versteht fast alle Befehle wortgleich.

docker pull nginx          →  podman pull nginx
docker run -d -p 8080:80   →  podman run -d -p 8080:80
docker ps                  →  podman ps
docker logs -f web         →  podman logs -f web
docker exec -it web sh     →  podman exec -it web sh
docker build -t app .      →  podman build -t app .

Viele setzen deshalb einfach alias docker=podman, und auf Fedora gibt es dafür sogar ein eigenes Paket (podman-docker). Ein paar Unterschiede gibt es trotzdem.

Kurznamen von Images

Bei Docker bedeutet alpine immer docker.io/library/alpine. Podman weiß erst einmal nicht, von welcher Registry ein Kurzname stammen soll. Auf unserem Ubuntu-System ist das über eine Datei mit Aliasen (/etc/containers/registries.conf.d/shortnames.conf) geregelt, in der bekannte Namen fest einer Registry zugeordnet sind. Für alles andere empfehlen wir: Schreib den vollen Namen, also docker.io/library/alpine statt alpine. Das ist eindeutig und schützt davor, versehentlich ein gleichnamiges Image aus einer fremden Registry zu ziehen.

Getrennte Welten

Ein Punkt, der beim Umstieg verwirrt: Docker und Podman teilen sich keine Images und keine Container. Docker speichert unter /var/lib/docker, Podman als root unter /var/lib/containers und rootless im Home-Verzeichnis des Benutzers. Nach der Installation von Podman sind deine Docker-Images dort nicht zu sehen. Du musst sie neu herunterladen oder neu bauen.

Compose: die überraschende Falle

Docker Compose ist für viele der eigentliche Grund, Docker zu benutzen. Wie sieht das bei Podman aus?

Podman bringt den Befehl podman compose mit. Wir haben ihn mit einer minimalen compose.yaml ausprobiert, und die erste Zeile der Ausgabe war aufschlussreich:

>>>> Executing third-party compose provider
     "/usr/libexec/docker/cli-plugins/docker-compose". <<<<

podman compose ist also kein eigenes Compose, sondern ein Weiterleiter. Er sucht ein vorhandenes Compose-Programm und ruft es auf. Auf unserem Server fand er das Compose-Plugin von Docker (Version 5.0.2) und benutzte es. Das funktioniert, weil Podman eine Docker-kompatible Schnittstelle anbietet und Compose so mit Podman statt mit Docker spricht.

Und das hat geklappt. Der Container startete, und hier kommt der entscheidende Teil:

docker ps  →  (leer)
podman ps  →  pvd-compose-web

Der Container lief unter Podman, Docker wusste nichts davon. Auf einem Server, auf dem beide installiert sind, ist das eine echte Stolperfalle: Du siehst mit dem gewohnten docker ps nicht, was läuft, und derselbe Befehl compose kann je nach Aufruf in zwei völlig getrennten Welten landen.

Ohne Docker-Installation brauchst du einen anderen Compose-Anbieter. Üblich ist das Python-Programm podman-compose, das eine eigene Umsetzung ist und nicht jedes Compose-Feature gleich gut beherrscht. Komplexe Compose-Dateien mit vielen Abhängigkeiten, Healthchecks und eigenen Netzwerken solltest du vor dem Umstieg testen, nicht blind übernehmen.

Cloud X Berry (englisch) stellt Docker und Podman einsteigerfreundlich gegenüber und geht auch auf die Frage ein, ob man Docker überhaupt noch braucht. Ein guter zweiter Blick auf das Thema.

systemd und Quadlet: wo Podman glänzt

Bei Docker ist der Daemon dafür zuständig, Container nach einem Neustart wieder hochzufahren (restart: unless-stopped). Bei Podman gibt es keinen Daemon. Also übernimmt diese Aufgabe das, was auf jedem modernen Linux ohnehin läuft: systemd.

Der moderne Weg dafür heißt Quadlet. Du schreibst eine kleine Datei, die wie eine systemd-Unit aussieht, und Podman erzeugt daraus automatisch einen richtigen Dienst. Genau das haben wir als rootless Benutzer getestet. Die Datei ~/.config/containers/systemd/pvdsleep.container bestand aus nur diesen Zeilen:

[Container]
Image=docker.io/library/alpine
Exec=sleep 1000

[Install]
WantedBy=default.target

Danach genügten zwei Befehle:

systemctl --user daemon-reload
systemctl --user start pvdsleep

Das Ergebnis: systemctl --user is-active pvdsleep meldete active, und podman ps zeigte einen Container namens systemd-pvdsleep. Der Container ist damit ein ganz normaler systemd-Dienst. Logs landen im Journal, Abhängigkeiten zu anderen Diensten lassen sich wie gewohnt festlegen, und systemctl enable sorgt für den Start beim Booten.

Unser Stolperstein: Exit-Code 137

Beim Stoppen des Dienstes stand danach nicht inactive, sondern failed da, mit dem Exit-Code 137. Das sah im ersten Moment wie ein Fehler aus. Die Ursache ist banal: sleep in einem Alpine-Container reagiert nicht auf das Signal SIGTERM, weil es als Prozess mit der Nummer 1 läuft und dafür keinen Handler hat. Podman wartet zehn Sekunden und beendet den Prozess dann hart mit SIGKILL. 137 bedeutet genau das: 128 plus Signal 9.

Dieselbe Warnung sahen wir schon vorher beim Aufräumen unserer anderen Podman-Testcontainer: StopSignal SIGTERM failed to stop container ... resorting to SIGKILL. Das ist kein Podman-Problem, sondern eine Eigenschaft des Images. Docker verhält sich beim Stoppen nach demselben Muster (erst SIGTERM, nach zehn Sekunden SIGKILL), das haben wir hier aber nicht eigens nachgemessen. Bei Docker fällt es nur weniger auf, weil es keinen systemd-Status gibt, der rot wird. Für echte Dienste gilt: Das Programm im Container muss SIGTERM sauber behandeln, oder du startest den Container mit --init, damit ein kleiner Init-Prozess die Signale weiterreicht.

Ein weiterer Hinweis, falls du rootless Container auch ohne angemeldeten Benutzer laufen lassen willst: Dafür muss für diesen Benutzer lingering aktiviert sein (loginctl enable-linger BENUTZER). Sonst beendet systemd alle Benutzerdienste, sobald die letzte Sitzung endet, und deine Container gleich mit.

Versionen: worauf du achten musst

Wir haben mit Podman 4.9.3 getestet, der Version aus den offiziellen Paketquellen von Ubuntu 24.04 LTS. Das ist nicht die neueste Version. Die Reihe 5.x ist seit 2024 verfügbar und hat unter anderem pasta als Standard-Netzwerk für rootless Container eingeführt. Auf Fedora bekommst du immer eine aktuelle Version, auf Ubuntu und Debian eine, die zur jeweiligen Distribution passt und dort mit Sicherheitsupdates versorgt wird.

Docker lief bei uns in Version 29.2.1, installiert aus Dockers eigener Paketquelle. Das ist ein typisches Muster: Docker installiert man meistens direkt vom Hersteller, Podman aus der Distribution. Beides hat Vor- und Nachteile. Die Hersteller-Quelle ist aktueller, die Distributions-Quelle stabiler und langfristig gepflegt. Welche Distribution sich für einen Server eignet, erklären wir in Linux-Server-Distributionen im Vergleich.

Docker vs Podman: die große Vergleichstabelle

Wann Docker, wann Podman?

Nach allen Messungen ist unsere Empfehlung klar, aber nicht dogmatisch.

Nimm Docker, wenn …

• du gerade anfängst. Die Menge an Tutorials, Stack-Overflow-Antworten und fertigen Compose-Dateien ist unschlagbar. Jede Hürde, die du nicht nehmen musst, ist eine gewonnene Stunde.
• du stark auf Compose setzt, besonders mit komplexen Dateien aus fremden Projekten. Das offizielle Docker Compose ist die Referenz.
• dein Team oder deine CI-Pipeline bereits Docker nutzt. Ein Werkzeugwechsel ohne konkreten Grund kostet mehr, als er bringt.
• du auf Windows oder macOS entwickelst und dir Docker Desktop lizenzrechtlich erlaubt ist.

Nimm Podman, wenn …

• du einen Server mit mehreren Benutzern oder Diensten betreibst, bei dem ein einzelner Ausbruch nicht den ganzen Rechner kosten darf.
• du Fedora, RHEL oder AlmaLinux nutzt. Dort ist Podman die Standardlösung und bestens integriert, siehe auch unseren Fedora-Deep-Dive.
• du Container als richtige systemd-Dienste betreiben willst. Quadlet ist die sauberste Lösung, die wir kennen.
• du jeden Megabyte RAM brauchst, etwa auf einem kleinen VPS. Kein Daemon heißt: kein Grundverbrauch.
• du später zu Kubernetes willst. Pods und podman kube generate machen den Übergang einfacher.

Und was machen wir selbst?

Ehrlich: Auf unserem Entwicklungsserver läuft weiterhin Docker, weil dort Testumgebungen für Shops und Datenbanken laufen, deren Anleitungen und Compose-Dateien auf Docker ausgelegt sind. Einen funktionierenden Aufbau nur wegen eines Vergleichsartikels umzubauen, wäre genau die Art von Optimierung, die mehr kaputt macht, als sie bringt. Für einen neuen Server mit wenigen, klar definierten Diensten würden wir heute Podman mit Quadlet wählen. Den Speichervorteil und die Rechtetrennung bekommt man dort geschenkt.

Umstieg von Docker auf Podman: so gehst du vor

Wenn du wechseln willst, geh schrittweise vor:

1. Podman parallel installieren, ohne Docker zu entfernen. Die beiden kommen sich nicht in die Quere, wie unser Test gezeigt hat. Genau das kann aber verwirren, siehe Compose-Abschnitt.
2. Einen unkritischen Dienst zuerst umziehen. Image mit vollem Namen ziehen, mit podman run starten, prüfen.
3. Daten sichern. Docker-Volumes liegen unter /var/lib/docker/volumes, Podman sieht sie nicht. Daten musst du bewusst kopieren oder als Bind-Mount einbinden. Vorher ein Backup, immer.
4. Ports anpassen, wenn du rootless arbeitest: alles unter 1024 über einen Reverse Proxy.
5. Autostart über Quadlet einrichten, statt dich auf Restart-Policies zu verlassen.
6. Erst wenn alles läuft, Docker entfernen, und vorher prüfen, ob irgendein Skript oder Cronjob noch docker aufruft.

Wenn du den Server erst noch aufsetzt, hilft dir unsere Anleitung Linux-Server einrichten. Für den Zugang per SSH mit Schlüsseln lies Was ist SSH?.

Was wir bewusst nicht behaupten

Damit du unsere Zahlen richtig einordnen kannst:

• Ein Server, keine Laborbedingungen. Alle Messungen stammen von unserem Entwicklungsserver unter normaler Last. Andere Container liefen nebenher.
• Kein Lasttest. Wir haben Startzeit und Speicher gemessen, nicht den Durchsatz einer Anwendung im Container. Da beide dieselbe Laufzeit (runc) und denselben Kernel nutzen, erwarten wir dort keine nennenswerten Unterschiede, haben es aber nicht geprüft.
• dockerd nach 89 Tagen. Der Speicherwert des Docker-Daemons ist eine Momentaufnahme eines lange laufenden Dienstes, nicht der Wert direkt nach dem Start.
• Podman 4.9.3. Neuere Versionen verhalten sich teilweise anders, besonders beim Netzwerk.
• Rootless-Startzeit. Warum rootless bei uns schneller war, haben wir nicht untersucht. Die Erklärung oben ist eine Vermutung.

Nach dem Test haben wir alles wieder abgeräumt: Test-Benutzer samt Unter-IDs gelöscht, alle Podman-Container und -Images entfernt (das Speicherverzeichnis ist zurück auf 248 KB) und das zusätzlich heruntergeladene Docker-Image gelöscht. Podman selbst bleibt installiert. Die sechs produktiven Docker-Container liefen die ganze Zeit ungestört weiter.

Fazit: Docker vs Podman in einem Satz

Docker ist der bequemere Standard, Podman die sicherere und sparsamere Architektur, und weil beide dieselben Images verstehen, ist die Wahl keine Entscheidung fürs Leben. Wer anfängt, fängt mit Docker gut an. Wer einen neuen Server aufsetzt und Wert auf Rechtetrennung und systemd legt, sollte Podman ernsthaft ausprobieren. Den größten Unterschied haben wir nicht bei der Geschwindigkeit gemessen, sondern bei der Frage, als wer deine Container laufen: bei Docker als root, bei Podman auf Wunsch als ganz normaler Benutzer.

Häufige Fragen zu Docker vs Podman

Was ist der Unterschied zwischen Docker und Podman?

Docker verwaltet Container über einen zentralen Hintergrunddienst, der als root läuft. Podman hat keinen solchen Dienst und startet jeden Container direkt, auf Wunsch ohne Root-Rechte. Befehle und Image-Format sind weitgehend gleich.

Ist Podman besser als Docker?

Nicht pauschal. Podman ist sicherer aufgebaut, braucht keinen Dauerdienst und passt besser zu systemd. Docker hat die größere Community, mehr Tutorials und das ausgereiftere Compose. Für Einsteiger ist Docker meist bequemer, für neue Server mit Sicherheitsfokus Podman die bessere Wahl.

Ist Podman schneller als Docker?

In unserer Messung nicht nennenswert. Ein Container-Start dauerte bei Docker etwa 0,5 Sekunden, bei Podman als root etwa 0,7 Sekunden und rootless etwa 0,48 Sekunden. Beim Speicher spart Podman dagegen deutlich, weil kein Daemon dauerhaft läuft.

Kann ich Docker-Images mit Podman nutzen?

Ja. Beide verwenden das OCI-Format. Jedes Image von Docker Hub läuft unter Podman. Am sichersten gibst du den vollen Namen an, etwa docker.io/library/nginx.

Funktioniert Docker Compose mit Podman?

Ja, mit Einschränkungen. podman compose ist ein Weiterleiter, der ein vorhandenes Compose-Programm aufruft, bei uns das Plugin von Docker. Ohne Docker brauchst du podman-compose, das nicht jedes Feature gleich gut unterstützt. Komplexe Dateien vorher testen.

Was bedeutet rootless bei Podman?

Der Container läuft als normaler Benutzer. Im Container ist der Prozess scheinbar root, auf dem Server aber nur ein unprivilegierter Benutzer. Bricht ein Angreifer aus, hat er keine Root-Rechte auf dem Host.

Kann Docker auch rootless laufen?

Ja, über einen separaten Rootless-Modus, bei dem ein eigener Daemon im Benutzerkontext läuft. Das erfordert zusätzliche Einrichtung. Bei Podman ist rootless dagegen ohne Extraschritte möglich.

Warum kann mein rootless Container nicht Port 80 öffnen?

Linux verbietet normalen Benutzern Ports unter 1024. Nimm einen hohen Port und setz einen Reverse Proxy davor, oder senke die Grenze per net.ipv4.ip_unprivileged_port_start. Die erste Variante ist sauberer.

Ist Podman kostenlos?

Ja. Podman und Podman Desktop sind Open Source und auch für Unternehmen kostenlos. Die Docker Engine ist ebenfalls kostenlos, nur Docker Desktop braucht ab einer bestimmten Unternehmensgröße eine kostenpflichtige Lizenz.

Kann ich Docker und Podman gleichzeitig installieren?

Ja, sie speichern Images und Container getrennt. Genau das kann aber verwirren: Ein Container, den du mit Podman startest, taucht in docker ps nicht auf. Auf Dauer solltest du dich für eines entscheiden.

Was ist Quadlet?

Quadlet ist die Integration von Podman in systemd. Du beschreibst einen Container in einer kleinen Datei, und Podman erzeugt daraus einen systemd-Dienst, der beim Booten startet, im Journal loggt und sich mit systemctl steuern lässt.