Podman Compose vs. Docker Compose

Warum überhaupt vergleichen?

Docker hat die Container-Welt geprägt – und Podman hat sich in wenigen Jahren von einer Red-Hat-Nische zum ernsthaften Kandidaten entwickelt. Wer heute ein neues Self-Hosted-Setup aufsetzt, steht vor der Frage: Docker Compose, wie es in den meisten Tutorials steht – oder Podman mit seinen Versprechen „daemonless“, „rootless“ und „voll kompatibel“? Die Antwort hängt weniger von der Datei ab als von der Umgebung, in der du läufst.

Konzept: Daemon vs. daemonless

• Docker arbeitet klassisch mit einem zentralen Daemon (dockerd), der als Root läuft; alle Clients sprechen mit ihm über den Docker-Socket.
• Podman kommt ohne Daemon aus: Jede Operation startet einen eigenen Prozess („fork-exec“), Container laufen standardmäßig rootless in User-Namespaces.
• Sicherheitsmodell: Rootless heißt nicht automatisch sicherer, reduziert aber die Angriffsfläche – ein kompromittierter Container hat nur die Rechte deines Users.
• Systemd-Integration: Podman ist für systemd-Linuxe gedacht (Quadlet); Docker setzt eher auf eigene Restart-Policies und Compose.
• Lizenz-Ebene: Docker Engine ist Open Source (Apache-2.0); Docker Desktop ist für größere Unternehmen kostenpflichtig. Podman ist durchgehend Open Source.

Verwirrung um „Podman Compose“

„Podman Compose“ ist leider kein einzelnes Werkzeug – dahinter stecken zwei verschiedene Ansätze, die man leicht verwechselt:

Die Kernunterschiede in der Tabelle

Funktioniert dieselbe Compose-Datei?

In den allermeisten Fällen: ja. Eine compose.yaml ohne Docker-spezifische Extras läuft mit docker compose up -d und podman compose up -d identisch – vorausgesetzt, der docker-compose-Binary ist installiert und der Podman-Socket aktiv:

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro

# Docker:
docker compose up -d

# Podman (gleiche Datei):
podman compose up -d

Migration von Docker zu Podman

• Aliase: alias docker=podman deckt den Alltag ab – die meisten CLI-Befehle sind kompatibel.
• Socket aktivieren: systemctl --user enable --now podman.socket – danach funktioniert docker compose (und Tools wie Portainer-Agent) gegen Podman.
• Bestand übernehmen: Volumes und Images weiterverwenden – die Ordner liegen nur woanders (~/.local/share/containers); ein podman pull lädt dieselben OCI-Images.
• Mac/Windows: podman machine startet eine VM – Docker Desktop-Nutzer finden sich schnell zurecht.
• Nicht alles ist 1:1: Container-Attach, Logs und Stats funktionieren, aber Host-Integrationen (z. B. Docker-Socket-Mounts in Compose) musst du einzeln prüfen.

Quadlet: die Podman-native Alternative

Wer unter systemd lebt, braucht womöglich gar kein Compose: Quadlet wandelt Container-Definitionen in echte Systemd-Units um – mit Autostart, Abhängigkeiten und Journal-Logs. Einzelne Container schreibst du als myapp.container:

[Unit]
Description=Meine kleine Website

[Container]
Image=docker.io/library/nginx:alpine
PublishPort=8080:80
Volume=%h/html:/usr/share/nginx/html:ro

[Service]
Restart=always

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now myapp

Fallstricke aus der Praxis

• Netzwerk-DNS: Rootless-Netzwerke nutzen teils andere DNS-Wege – Service-Namen aus Compose funktionieren, aber manche Host-Netzwerkkonfigurationen nicht wie unter Docker.
• deploy.resources.limits: docker compose v2 setzt diese um; podman-compose (Python) ignoriert sie oft – Limits dann lieber als --memory/Quadlet setzen.
• Watchtower & Co.: Tools, die den Docker-Socket brauchen, laufen gegen den Podman-Socket meist, aber nicht immer – bei Problemen den Podman-Agent-Ansatz prüfen.
• SELinux: Ohne :z/:Z erscheinen Mounts leer oder die Container starten nicht – der Klassiker auf Fedora-Servern.
• Builds: build:-Blöcke funktionieren in beiden, aber Podman nutzt seinen eigenen Builder (Buildah) – manche Dockerfile-Spezialitäten unterscheiden sich minimal.

Häufige Fragen (FAQ)

Fazit

Datei-technisch sind sich beide Seiten heute so ähnlich, dass die Entscheidung fast nie an der compose.yaml hängt, sondern am Betriebssystem und am Sicherheitsmodell: Auf Fedora, RHEL & Co. oder mit Rootless-/Systemd-Fokus ist Podman die runde Lösung – auf klassischen Debian-Servern mit etablierten Tools bleibt Docker Compose die pragmatische Wahl. Wer beides kann, ist für jedes Projekt gerüstet.