Docker Compose vs. Podman Quadlets: KMU-Sicht 2026

Container-Workloads sind im Mittelstand längst Realität — vom Reverse-Proxy über die Wiki-Instanz bis zur Monitoring-Plattform. Lange Zeit hieß die Standardantwort auf die Frage nach dem Orchestrator schlicht: Docker Compose. Seit Red Hat mit Podman 4.4 die sogenannten Quadlets eingeführt hat und diese 2026 in praktisch allen aktuellen Linux-Distributionen verfügbar sind, lohnt sich ein zweiter Blick. Dieser Artikel ordnet beide Werkzeuge aus KMU-Sicht ein, vergleicht Ökosystem, Sicherheit und Betriebsmodell und zeigt, wann ein Wechsel sinnvoll ist — und wann nicht.

Docker Compose: Der etablierte Standard

Docker Compose ist seit Jahren das De-facto-Werkzeug, um Multi-Container-Stacks deklarativ zu beschreiben. Eine docker-compose.yml definiert Services, Volumes, Netzwerke und Abhängigkeiten in einer einzigen YAML-Datei. Mit docker compose up -d startet der gesamte Stack — übersichtlich, schnell, dokumentiert.

Stärken:

• Riesiges Ökosystem: Praktisch jede Self-Hosting-Anleitung im Netz nutzt Compose
• Einfacher Einstieg, gut dokumentiert, viele fertige Stacks auf GitHub
• Plattformübergreifend (Linux, Windows, macOS) für Entwickler-Workflows
• Reife Tooling-Integration (Portainer, Watchtower, Dozzle)

Schwächen:

• Setzt einen laufenden Docker-Daemon voraus, der als Root läuft (Single Point of Failure)
• Rootless-Modus existiert, ist aber gefrickelt und nicht der Standardpfad
• Eigene Logik für Restart und Healthchecks parallel zu systemd
• Logs landen im Docker-eigenen JSON-File-Format und nicht in journald
• Lizenzmodell (Docker Desktop) bleibt für Unternehmen ein Reizthema

Podman Quadlets: systemd statt Daemon

Podman verfolgt einen grundlegend anderen Ansatz: Es gibt keinen zentralen Daemon. Container werden direkt als Kindprozesse des aufrufenden Users gestartet — standardmäßig rootless. Quadlets sind ab Podman 4.4 (stable in 5.x, in 2026 fest verfügbar in RHEL 9/10, Rocky 9/10, AlmaLinux, Debian 13 Trixie und Ubuntu 24.04 LTS) das Mittel der Wahl, um Container deklarativ über systemd zu verwalten.

Ein Quadlet ist eine schlichte .container-Datei im systemd-Unit-Format, die beim Start in eine vollwertige systemd-Service-Unit übersetzt wird. Damit erbt der Container alle Eigenschaften von systemd: Restart-Policies, Dependencies, Resource-Limits via cgroups v2, Journal-Logging, Socket-Activation, Timer-basierte Starts.

Stärken:

• Rootless by Default — kein Daemon mit Root-Rechten
• Native systemd-Integration: Logs landen automatisch in journald
• Restart-Verhalten, Dependencies und Resource-Limits über bewährte systemd-Mechanismen
• Kein zentraler Single Point of Failure
• OCI-kompatibel: Pulls von Docker Hub, Quay, GHCR funktionieren unverändert
• In RHEL-basierten Distributionen offiziell unterstützt — wichtig für Compliance

Schwächen:

• Lernkurve, vor allem für Teams, die Compose im Schlaf beherrschen
• Weniger fertige Anleitungen im Netz (wächst aber sichtbar)
• Volumes, Pods und Networks brauchen jeweils eigene Unit-Dateien
• Debugging über journalctl und systemctl statt docker compose logs

Direktvergleich

Merkmal	Docker Compose	Podman Quadlets
Daemon	Ja, dockerd als Root	Nein, daemonless
Rootless-Betrieb	Möglich, aber Sonderfall	Standard
Konfigurationsformat	YAML (docker-compose.yml)	systemd-Unit (.container, .volume, .network)
Restart-Logik	restart: unless-stopped im YAML	systemd Restart= Direktive
Logging	JSON-File-Driver, separate Tools	journald nativ, journalctl -u service
Healthchecks	Im YAML definiert	systemd-Healthcheck plus Unit-Status
Resource-Limits	YAML-Felder, mappt auf cgroups	systemd-Direktiven (CPUQuota, MemoryMax)
Auto-Start	Docker-Daemon startet alle Container	systemd enabled Units beim Boot
Ökosystem	Sehr groß, viele Tutorials	Wächst, RHEL-Welt voraus
Compliance/Audit	Daemon erschwert Auditing	Saubere Prozessbäume, journald-Logs
Image-Pulls	Docker Hub, eigene Registry	Docker Hub, Quay, GHCR — Multi-Registry

Aufbau einer Quadlet-Datei

Eine .container-Datei liegt typischerweise unter /etc/containers/systemd/ (system-weit) oder ~/.config/containers/systemd/ (rootless pro User). Das Format ist bewusst nah an klassischen systemd-Units:

[Unit]
Description=Nextcloud AIO
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/nextcloud/all-in-one:latest
ContainerName=nextcloud-aio
PublishPort=8080:8080
Volume=nextcloud-aio.volume:/mnt/docker-aio-config
Environment=APACHE_PORT=11000
Environment=APACHE_IP_BINDING=0.0.0.0
HealthCmd=/healthcheck.sh
HealthInterval=30s
Memory=4G
CPUQuota=200%

[Service]
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target default.target

Nach dem Anlegen genügt systemctl daemon-reload und systemctl start nextcloud-aio.service. Quadlet erzeugt die Service-Unit automatisch im Hintergrund. Logs sind sofort über journalctl -u nextcloud-aio.service -f einsehbar — ohne zusätzlichen Log-Driver, ohne externe Tools.

Praxisbeispiel: 5-Service-Stack migrieren

Nehmen wir einen typischen KMU-Stack: Traefik als Reverse-Proxy, Nextcloud für Dateifreigaben, Vaultwarden als Passwort-Server, Uptime-Kuma für Monitoring und eine PostgreSQL als gemeinsame Datenbank. Die ursprüngliche docker-compose.yml umfasst rund 120 Zeilen YAML mit Networks und Volumes.

Die Migration zu Quadlets folgt einem klaren Schema:

1. Pro Service eine .container-Datei unter /etc/containers/systemd/
2. Pro Volume eine .volume-Datei für persistente Daten (Konfigs, Datenbanken)
3. Ein gemeinsames Netzwerk als .network-Datei für die interne Kommunikation
4. Abhängigkeiten über Wants= und After= in den Units (z. B. Nextcloud nach PostgreSQL)
5. Reverse-Proxy-Labels für Traefik direkt als Label=-Direktiven im Container-Block

Aus 120 YAML-Zeilen werden rund 200 Zeilen über mehrere Dateien verteilt — etwas mehr Schreibarbeit, dafür übersichtlicher pro Komponente und sauber in systemd verankert. Ein Reboot startet den kompletten Stack in der korrekten Reihenfolge, ohne dass ein Docker-Daemon zwischengeschaltet ist. Backups via Proxmox Backup Server erfassen die Volumes wie gewohnt, da die Pfade unverändert bleiben.

Wann lohnt sich der Wechsel?

Auf Quadlets migrieren, wenn:

• Der Host ohnehin RHEL, Rocky, AlmaLinux oder eine andere systemd-Distribution ist
• Compliance-Vorgaben rootless-Betrieb und saubere Audit-Trails verlangen
• journald als zentraler Log-Hub bereits etabliert ist
• Der Docker-Daemon als Single Point of Failure stört
• Container neben klassischen systemd-Diensten koexistieren sollen

Bei Docker Compose bleiben, wenn:

• Das Team Compose-Erfahrung hat und die Stacks stabil laufen
• Anleitungen aus dem Self-Hosting-Ökosystem 1:1 übernommen werden sollen
• Entwickler unter Windows oder macOS denselben Stack lokal nutzen
• Tools wie Portainer für die Verwaltung gesetzt sind
• Der zeitliche Aufwand einer Migration aktuell nicht im Verhältnis zum Nutzen steht

Hybrid-Strategie für KMU

In der Praxis sehen wir bei vielen Kunden einen gestaffelten Ansatz: Produktive, langlebige Dienste — Reverse-Proxy, Mail-Gateway, Backup-Agent — wandern zu Quadlets, weil sie vom journald-Logging und der systemd-Integration profitieren. Entwicklungs- und Test-Stacks bleiben bei Compose, weil dort Geschwindigkeit und Tutorial-Kompatibilität wichtiger sind. Auf einem Linux-Server lassen sich beide Welten problemlos parallel betreiben.

Für KMU mit eigener Virtualisierung in Proxmox VE empfehlen wir, neue Container-Workloads direkt als Quadlets anzulegen — die initiale Lernkurve zahlt sich im laufenden Betrieb durch weniger Wartungsaufwand schnell aus. Bestehende Compose-Stacks bleiben, bis ein Versionssprung oder eine Umstrukturierung ohnehin Arbeit erfordert.

Fazit

Docker Compose bleibt 2026 der schnellste Weg zu einem laufenden Container-Stack, gerade wenn Tutorials und fertige Vorlagen genutzt werden. Podman Quadlets sind die strategisch interessantere Wahl, sobald Produktivbetrieb, Compliance und langfristige Wartung im Vordergrund stehen — rootless by default, native systemd-Integration und sauberes journald-Logging gleichen die anfängliche Mehrarbeit deutlich aus. Die wichtigste Erkenntnis: Es ist keine Entweder-oder-Entscheidung. Beide Werkzeuge koexistieren problemlos auf demselben Host.

---

DATAZONE unterstützt Sie bei der Bewertung Ihrer Container-Strategie, der Migration bestehender Compose-Stacks zu Quadlets und beim sicheren Betrieb auf Proxmox VE. Kontaktieren Sie uns — wir beraten Sie zu Linux-Servern, Virtualisierung und Container-Workloads aus einer Hand.