Docker Desktop vs. Podman im Self-Hosting: Lizenz, Architektur und OCI-Compliance neu bewertet

Docker Desktop kostet in größeren Unternehmen seit 2022 Geld. Podman nicht. Wer Self-Hosting auf Linux betreibt, sollte spätestens jetzt die Architekturfrage neu stellen – nicht aus ideologischen Gründen, sondern weil sich technische und lizenzrechtliche Realitäten verschoben haben.

Die Lizenzfrage: Was wirklich kostenpflichtig ist und was nicht

Häufig kursiert die Zusammenfassung „Docker ist nicht mehr kostenlos“. Das stimmt so nicht. Docker Engine bleibt Open Source unter Apache 2.0 und ist kostenfrei, egal wie groß das Unternehmen ist. Die Lizenzpflicht betrifft ausschließlich Docker Desktop – die GUI-Anwendung für Windows und macOS. Wer auf einem Linux-Server oder einer Linux-Workstation direkt mit der Docker Engine arbeitet, zahlt nichts.

Die Schwelle ist klar definiert: Unternehmen mit mindestens 250 Mitarbeitenden oder mindestens 10 Millionen US-Dollar Jahresumsatz müssen für Docker Desktop zahlen. Die Subscription-Preise liegen laut aktuellen Vergleichsquellen bei rund 9 US-Dollar pro Monat und Nutzer (Pro), 21 Dollar (Team) und 24 Dollar (Business). Das klingt überschaubar, summiert sich bei einem Entwicklerteam von zwanzig Personen auf über 400 Dollar monatlich – allein für das GUI-Werkzeug auf dem Entwickler-Laptop.

Was dabei oft übersehen wird: Viele Admins betreiben ihre Produktionscontainer auf Linux-Hosts mit freier Docker Engine, arbeiten aber auf ihrer Windows- oder macOS-Workstation mit Docker Desktop. Genau dort greift die Lizenzpflicht. Podman Desktop dagegen ist vollständig Open Source, Apache 2.0, ohne Nutzer- oder Umsatzgrenzen kommerziell einsetzbar. Für Self-Hoster, die ohnehin auf Linux arbeiten, ist diese Unterscheidung weniger kritisch – aber sie erklärt, warum gerade Enterprise-Teams die Alternative ernsthafter prüfen als noch vor zwei Jahren.

Architektur: Daemon vs. Daemonless

Der technisch relevanteste Unterschied zwischen Docker und Podman ist nicht die CLI-Syntax, sondern das Architekturmodell. Docker läuft mit einem zentralen Root-Daemon – dem dockerd –, der alle Container und Images verwaltet. Jeder docker run-Befehl kommuniziert mit diesem Daemon. Der Docker-Socket ist in vielen Standard-Setups als Unix-Socket mit Root-Rechten erreichbar. Ein kompromittierter Socket bedeutet vollständige Kontrolle über den Host.

Podman verzichtet auf diesen Daemon vollständig. Jeder podman run-Aufruf startet den Containerprozess direkt, ohne Zwischendienst. Das hat praktische Konsequenzen: kein einzelner Daemon als Ausfallpunkt, kein persistenter Hintergrundprozess mit Root-Rechten. Laut einem aktuellen Vergleich auf Daily.dev berichten rund 34 Prozent der befragten Organisationen davon, Docker für lokale Entwicklung und Podman für CI/CD und Produktionsumgebungen zu kombinieren – genau wegen dieser Architekturunterschiede.

Podman integriert sich außerdem eng mit systemd. Container lassen sich per podman generate systemd als Unit-Files exportieren und damit wie reguläre Systemdienste starten, überwachen und neu starten. Wer seine Self-Hosting-Dienste ohnehin über systemd verwaltet, bekommt hier eine saubere Integration, ohne Wrapper-Skripte.

Rootless als Default

Podman läuft standardmäßig im Rootless-Modus: Container werden unter dem Nutzer-Namespace des aufrufenden Users gestartet, nicht als Root auf dem Host. Ein Containerausbruch liefert dem Angreifer damit nur Nutzerrechte, keine Host-Root-Rechte. Docker bietet Rootless-Modus inzwischen ebenfalls an, aber es ist kein Default – man muss es explizit konfigurieren.

Für Self-Hoster, die auf einem gemeinsam genutzten Linux-Server mehrere Dienste betreiben, ist das kein theoretisches Sicherheitsargument. Es ist die Differenz zwischen einem Vorfall, der einen Dienst betrifft, und einem, der den ganzen Host kompromittiert. Gerade auf Distributionen wie Red Hat Enterprise Linux, wo Podman seit RHEL 10 noch tiefer in die Systemarchitektur integriert ist, zahlt sich dieses Sicherheitsmodell im Betrieb unmittelbar aus.

OCI-Compliance und Kompatibilität: Kein Lock-in

Ein alter Mythos lautet, Docker-Images seien nicht mit Podman kompatibel. Das war vielleicht in frühen Versionen ein Diskussionspunkt, ist heute aber schlicht falsch. Beide Engines implementieren den Open Container Initiative (OCI) Standard für Image-Formate und Runtimes. Jedes Docker-Image lässt sich mit Podman starten, ohne Konvertierung, ohne Anpassung. Registries wie Docker Hub, GitHub Container Registry oder Quay sind mit beiden Engines nutzbar.

Docker hat die OCI maßgeblich mitbegründet. Die Compliance-Aussagen gelten für beide Seiten gleichermaßen. Was OCI-Konformität praktisch bedeutet: Wer heute Docker-Container baut und morgen auf eine andere Runtime – ob Podman, containerd oder CRI-O – wechseln will, kann das tun. Kein Rebuild, kein Formatwechsel. Das ist der eigentliche Wert des Standards: Migrations- und Wechselpfade bleiben offen.

Podman unterstützt zusätzlich das Pod-Konzept nativ. Container lassen sich in Pods gruppieren, die einen gemeinsamen Netzwerk-Namespace teilen – analog zum Kubernetes-Pod-Modell. Mit podman generate kube lassen sich aus laufenden Pods direkt Kubernetes-Manifeste generieren. Wer Self-Hosting heute auf einem einzelnen Server betreibt und morgen auf Kubernetes migrieren will, hat mit Podman einen kürzeren Weg dorthin.

Performance: Wo Podman gewinnt, wo Docker vorne liegt

Pauschale Aussagen wie „Podman ist immer schneller“ sind nicht korrekt. Es kommt auf den Workload an. Beim Container-Start profitiert Podman davon, dass keine Daemon-Kommunikation nötig ist. Vergleichsmessungen beschreiben schnellere Startzeiten gegenüber Docker bei Einzelcontainern, weil der direkte Prozessstart ohne Zwischenschicht auskommt.

Beim Image-Build sieht es anders aus. Docker BuildKit mit seinen ausgereiften Caching-Mechanismen und Multi-Stage-Build-Optimierungen ist in vielen Szenarien performanter. Wer täglich große Images mit komplexen Abhängigkeiten baut, merkt das. Buildah – das daemonlose Build-Tool aus dem Podman-Ökosystem – schließt diesen Abstand, ist aber in der Praxis noch nicht überall so flüssig integriert wie BuildKit.

Für typische Self-Hosting-Workloads – ein paar Dienste wie Nextcloud, Vaultwarden, Immich oder Authentik, die dauerhaft laufen – spielt die Build-Performance kaum eine Rolle. Hier zählt die Stabilität im Dauerbetrieb und der geringe Ressourcen-Footprint. Podman ohne Daemon beansprucht dauerhaft weniger Arbeitsspeicher, weil kein Hintergrundprozess läuft. Das ist auf kleinen Servern oder Homelab-Hardware mit begrenztem RAM messbar relevant.

Migration: Wie aufwendig ist der Wechsel wirklich?

Die CLI-Kompatibilität zwischen Docker und Podman ist eng. Das übliche Alias-Setup alias docker=podman funktioniert für die meisten Standardbefehle. Wer einfache Compose-Workflows nutzt, kann auf podman compose oder das kompatible podman-compose-Tool umsteigen – wobei Docker Compose (v2) auch direkt gegen einen Podman-Socket funktioniert, sofern der Socket aktiviert ist.

Die größten Reibungspunkte beim Umstieg liegen woanders. Erstens: Skripte, die explizit den Docker-Socket unter /var/run/docker.sock erwarten, müssen auf den Podman-Socket umgeleitet werden – kein großes Problem, aber ein manueller Schritt. Zweitens: Wer Volumes mit Root-Rechten erstellt hat und in den Rootless-Modus wechselt, muss Dateirechte prüfen. Drittens: systemd-Integration ist bei Podman der empfohlene Weg für Dienste im Dauerbetrieb, bei Docker war das lange Compose-Datei plus Neustart-Policy. Das sind Lernkurven, keine Blockaden.

Meiner Einschätzung nach ist der Wechsel für einen typischen Self-Hoster, der fünf bis zehn Dienste auf einem Linux-Server betreibt, an einem Wochenende machbar. Wer mehrere Dutzend Container mit komplexen Abhängigkeiten und CI/CD-Pipelines verwaltet, sollte mehr Zeit einplanen und kritische Workflows testen, bevor er produktive Systeme umstellt.

Konkrete Migrationsstrategie in drei Phasen

Wer den Wechsel strukturiert angehen will, profitiert von einem schrittweisen Vorgehen. In einer ersten Phase empfiehlt es sich, Podman parallel zur laufenden Docker-Installation einzurichten und einzelne, unkritische Dienste – etwa einen Monitoring-Stack oder einen selbst gehosteten RSS-Reader – als erste Kandidaten zu nutzen. Dabei lassen sich Volumes, Netzwerkkonfiguration und Compose-Syntax in einer risikoarmen Umgebung validieren.

In der zweiten Phase folgt die systemd-Integration: Für jeden migrierten Dienst wird eine Unit-File generiert, getestet und aktiviert. Erst wenn diese Units stabil autorestarten und Log-Ausgaben sauber in journald landen, wandern weitere Dienste nach. Die dritte Phase besteht darin, Docker Engine zu deinstallieren und den Socket-Alias dauerhaft zu setzen. Wer an diesem Punkt angekommen ist, hat in der Regel alle Reibungspunkte bereits identifiziert und gelöst.

Besondere Aufmerksamkeit verdienen Dienste, die selbst auf den Docker-Socket zugreifen – etwa Portainer, Watchtower oder Traefik mit Docker-Provider. Diese Tools müssen explizit auf den Podman-Socket umgeleitet oder durch kompatible Alternativen ersetzt werden. Für Traefik existiert ein Podman-Provider-Plugin, Watchtower lässt sich mit dem Podman-Socket konfigurieren, und Portainer unterstützt Podman inzwischen ebenfalls, wenn auch mit eingeschränktem Funktionsumfang im Vergleich zur Docker-Integration.

Das Podman-Ökosystem 2026: Was Buildah und Skopeo beitragen

Podman steht nicht allein. Das Projekt von Red Hat umfasst ein Werkzeugset, das bewusst modular aufgebaut ist. Buildah ist das daemonlose Build-Tool, das OCI-Images ohne Root-Rechte und ohne laufenden Daemon erstellt. Skopeo kopiert, inspiziert und synchronisiert Container-Images zwischen Registries, ebenfalls ohne Daemon. Zusammen bilden sie einen vollständig daemonlosen Container-Stack, der für regulierte Umgebungen und CI-Pipelines auf Linux-Basis gut dokumentiert ist.

Laut einem Praxisvergleich von Infralovers unterstützen viele aktuelle Tools – IDE-Plugins, CI-Systeme, Registry-Clients – inzwischen Docker- und Podman-Sockets parallel. Der Lock-in in Richtung Docker-Toolchain ist geringer als noch vor drei Jahren. Das Ökosystem zieht nach, wenn auch langsamer als die reine Engine-Entwicklung.

Auf RHEL-, Fedora- und CentOS-Stream-Hosts ist Podman der Distributions-Standard. Wer dort Docker nachinstalliert, schwimmt gegen die Strömung. Fedora hat das Podman-First-Modell schon mit älteren Releases konsequent etabliert. Das ist kein ideologisches Statement, sondern ein Hinweis auf die tatsächliche Integrationspflege, die Red Hat in Podman steckt.

Gegenargumente: Wo Docker weiterhin die bessere Wahl ist

Eine ausgewogene Bewertung verlangt, auch die Argumente für Docker klar zu benennen. Das Ökosystem rund um Docker bleibt in mehreren Bereichen deutlich ausgereifter. Erstens ist die Dokumentation: Der überwiegende Teil von Community-Tutorials, Vendor-Dokumentationen und Stack-Overflow-Antworten bezieht sich auf Docker-Syntax und Docker-Compose-Semantik. Wer ein Problem googelt, findet eine Docker-Antwort – nicht zwingend eine Podman-Antwort.

Zweitens ist Docker Desktop auf Windows und macOS für viele Entwicklungsteams schlicht komfortabler, weil die Integration mit Volume-Mounts, Netzwerk-Forwarding und WSL2 auf diesen Plattformen ausgereifter ist als Podmans Entsprechung. Für reine Linux-Nutzer entfällt dieser Vorteil, aber gemischte Teams sind in der Realität häufig.

Drittens: Wer in einer Organisation arbeitet, die Docker Enterprise oder verwandte Produkte lizenziert und Support-Verträge hat, wechselt nicht wegen eines Security-Vorteils in einem Architekturmodell. Die organisatorischen Reibungskosten überwiegen dort den technischen Gewinn, zumindest kurzfristig. Wer hingegen als Einzelperson oder kleines Team autonom entscheidet, hat diese Beschränkung nicht – und profitiert stärker von Podmans Vorteilen.

Welche Engine für welches Self-Hosting-Szenario?

Die Antwort hängt vom konkreten Setup ab. Drei Szenarien, drei Empfehlungen:

Szenario 1: Linux-Server, Einzelperson, wenige Dienste, RHEL/Fedora/Rocky als Host. Podman ist hier der natürliche Default. Kein zusätzlicher Daemon, systemd-Integration ohne Klimmzüge, rootless Security ohne Konfigurationsaufwand. Docker-Images laufen unverändert.

Szenario 2: Gemischtes Team, lokale Entwicklung auf Windows/macOS, Produktion auf Linux. Podman Desktop auf den Entwickler-Workstations erspart Docker-Desktop-Lizenzen. Für die Produktion auf Linux bleibt ohnehin die Frage, ob Docker Engine oder Podman – beide sind kompetent, Podman hat den Security-Vorteil. Ein Hybrid-Ansatz ist valide.

Szenario 3: Tutorial-Follower, der nach Anleitung deployt. Die meisten Anleitungen im Netz nutzen Docker-Syntax. Das CLI-Alias funktioniert für die Mehrheit der Befehle, aber Edge-Cases in Compose-Dateien oder volume-spezifische Konfigurationen können abweichen. Wer ohne tieferes Troubleshooting-Interesse deployt, fährt mit Docker Engine auf Linux kurzfristig einfacher. Einen detaillierten technischen Vergleich inklusive containerd als dritte Option liefert die EITT Academy für genau diese Abwägung.

Was ich nach dieser Analyse für mich mitnehme: Die Frage ist nicht mehr „Docker oder kein Container“, sondern „welche Runtime passt zur vorhandenen Infrastruktur und zum Threat-Modell“. Wer auf RHEL-Derivaten arbeitet und Security ernst nimmt, hat mit Podman heute einen vollwertigen Stack, keinen Kompromiss.

Was bleibt offen

Das Tooling-Ökosystem rund um Podman wächst, aber Docker bleibt das Gravitationszentrum von Tutorials, Dokumentation und Community-Beispielen. Das ist kein technisches Argument für Docker – es ist ein Netzwerkeffekt. Wie lange er trägt, wenn sich Lizenzkosten weiter summieren und rootless Security in mehr Compliance-Frameworks als Anforderung auftaucht, ist die eigentlich interessante Frage für die nächsten zwei Jahre.

Wer jetzt ein neues Self-Hosting-Projekt auf Linux aufsetzt: Lohnt es sich, Podman von Anfang an zu evaluieren, statt beim gewohnten Docker-Setup zu bleiben – und wenn ja, welche Dienste zeigen in Ihrem Homelab die stärksten Reibungspunkte beim Umstieg?