Ist Docker Compose produktionsreif? Ja – so sieht das Setup aus
Ja — für eine Single-Host-App mit moderatem Traffic ist Docker Compose eine legitime Produktionsplattform. Produktionsreif wird es durch: Reverse Proxy mit automatischem TLS, Healthchecks und Restart-Policies, ein kleines Deploy-Skript, Off-Host-Backups, die ihr wirklich mal restored habt, und einen Monitoring-Agent. Wechselt erst, wenn ihr mehrere Hosts oder Zero-Downtime-Orchestrierung tatsächlich braucht — nicht, weil ein Konferenztalk es sagt.
„Compose ist nur für Dev" wird deutlich öfter wiederholt als geprüft. Wir betreiben seit Jahren produktive Workloads auf Compose — hier ist das Setup, das sich diesen Satz verdient.
Ist Docker Compose produktionsreif?
Für einen überraschend großen Teil echter Produkte: ja. Wenn eure App auf einen vernünftig dimensionierten Server passt — und das tut die meiste B2B-Software mit moderatem Traffic — bekommt ihr mit Compose reproduzierbare Deployments, Service-Isolation und eine Datei, die den ganzen Stack beschreibt. Kombiniert mit günstigem EU-Hosting (die Hetzner-vs.-Vercel-Rechnung haben wir aufgeschrieben) ist das Produktionsbetrieb für eine zweistellige Monatsrechnung.
Der Haken: Default-Compose ist nicht Produktions-Compose. Dazwischen liegen etwa sechs Entscheidungen.
Das erwachsene Compose-Setup
| Produktionsthema | Compose-Antwort | Wann ihr rauswachst |
|---|---|---|
| TLS & Routing | Reverse Proxy mit automatischen Zertifikaten | Dutzende Services und Domains |
| Crash-Recovery | Healthchecks + restart: unless-stopped | Self-Healing über Maschinen hinweg |
| Deploys | Kleines Skript: Pull, Restart, Health-Gate | Harte Zero-Downtime-Anforderungen |
| Secrets | .env außerhalb von Git, beim Deploy injiziert | Zentrale Rotations-Policies |
| Backups | Nächtliche Dumps off-host, restore-getestet | Point-in-Time-Recovery im großen Stil |
| Monitoring | Agent auf dem Host + externer Uptime-Check | Observability über eine Flotte |
Zwei Punkte verdienen Nachdruck. Pinnt eure Images: deployt getaggte Builds, nie latest — sonst ist eure Rollback-Story Fiktion. Und Backups zählen erst, wenn ihr eines auf einen Scratch-Server restored und die Zeit gestoppt habt.
Was Compose euch ehrlicherweise nicht gibt
Kein Multi-Host-Scaling, keine Zero-Downtime-Orchestrierung, kein Self-Healing, wenn die Maschine selbst stirbt. Das Deploy-Skript kostet euch ein paar Sekunden Blip, und ein toter Host heißt: Restore auf eine neue Maschine — typisch unter einer Stunde, wenn ihr geübt habt, ein Fass ohne Boden, wenn nicht.
Die Signale fürs Rauswachsen: Ihr braucht mehr Rechenleistung, als ein großer Server hergibt, ein paar Sekunden Deploy-Downtime kosten echtes Geld, oder Verträge verlangen Hochverfügbarkeit über Zonen. Dann wird die Kubernetes-Frage legitim. Nach unserer Erfahrung erreichen die meisten Teams in den ersten zwei Jahren keines dieser Signale — nur Blogposts darüber.
Unsere Default-Empfehlung
Startet auf Compose, auf einem gut dimensionierten Server, mit den sechs Bausteinen oben ab Tag eins. Ihr verbringt euer erstes Jahr mit Produkt statt Plattform. Und falls ihr doch rauswachst, ist nichts verloren: Container, Images und Gewohnheiten ziehen unverändert in jeden Orchestrator um.
Genau diesen Stack — TLS, Deploys, Backups, Monitoring — bauen wir als Teil unserer Cloud & DevOps Projekte auf, meist in unter einer Woche.
Olio auf LinkedIn
