Sie brauchen kein Kubernetes. Noch nicht. Wenn Ihr Produkt vor Series B ist, Ihr Traffic sich in Dutzenden Millionen Requests pro Monat (nicht Milliarden) bewegt und Ihr Team weniger als ein Dutzend Engineers umfasst, kann Docker Compose in der Produktion die richtige Wahl sein—sofern Sie es wie Produktion behandeln und nicht wie eine verlängerte Dev-Umgebung.
Die Debatte flammte diesen Monat erneut auf, nachdem wieder eine Runde von Posts fragte: „Sollte ich 2026 pures Docker Compose in der Produktion betreiben?“ – und eine Woche voller Sicherheits-Schlagzeilen: ein aktiv ausgenutzter cPanel-Authentication-Bypass, Ubuntu-Properties, die von DDoS eingedeckt wurden, und Kernel-Offenlegungen ohne vorherige Heads-up für Distributionen. Übersetzung: Ihre Operations-Fläche wird geprüft, egal ob Sie k8s oder Compose fahren. Die Frage ist, für welche Komplexität Sie heute bezahlen wollen.
Die eigentliche Entscheidung
Sie wählen nicht zwischen „Spielzeug-Compose“ und „echtem Kubernetes“. Sie wählen zwischen:
- Ein bis wenige Hosts, simple Vernetzung, vorhersehbare Workloads, 99,9 % SLO — Compose + ein gehärteter Linux-Host + ein Reverse-Proxy + disziplinierte Deployments.
- Viele Hosts, sprunghafte oder spezialisierte Workloads (GPU/ML/Batch), Mandantenisolierung, 99,99 %+ — ein Scheduler (Kubernetes, ECS oder Nomad) mit passendem Tooling und Teamreife.
Alles andere sind Details. Hier ist das Framework, das wir mit US-Startups und Scale-ups nutzen (und das unsere SRE-Teams in Brazil täglich betreiben).
Ein CTO-Raster mit 8 Achsen zur Compose-Tauglichkeit
1) Teamgröße und On-Call-Reife
- Compose-freundlich: 2–6 Engineers, 1–2 SREs oder starke Generalisten, eine einzige On-Call-Rotation und die klare Messlatte „eine Person kann den gesamten Stack verstehen“.
- Scheduler-Terrain: 3+ Squads, separates Plattform-Team, >30 Services oder ein Mandat für Self-Service-Infra durch Feature-Teams.
2) Workload-Charakteristik
- Compose-freundlich: Überwiegend langlaufende Web-APIs, ein paar Worker, cron-ähnliche Jobs, eine Datenbank, ein Cache.
- Scheduler-Terrain: Spiky Batch-Jobs, GPU/Accelerators, mandantenspezifische Sandboxes oder Hunderte flüchtige Tasks pro Tag.
3) SLOs und Ausfallzeit-Budget
- Compose-freundlich: 99,9 % Verfügbarkeit (≈43 Minuten/Monat). Blue/Green oder gestaffelte Restarts halten Sie im Budget.
- Scheduler-Terrain: 99,99 % (≈4,3 Minuten/Monat) oder höher, Multi-AZ-HA, automatisches Rescheduling über Nodes hinweg.
4) Release-Kadenz und Rollback
- Compose-freundlich: Tägliche Releases mit Blue/Green oder Canary-per-Header im Edge-Proxy, einfaches Rollback durch Tauschen eines Compose-Projektnamens.
- Scheduler-Terrain: Mehrere Deploys pro Stunde über Dutzende Services mit Auto-Canarying und Traffic Shaping.
5) Netzwerk und Service-Discovery
- Compose-freundlich: Eine kleine Zahl interner Netzwerke, Traefik/Caddy davor, DNS-basierte Discovery über 1–3 Hosts.
- Scheduler-Terrain: Komplexes Mesh, Network Policies, mTLS zwischen Services, mandantenspezifische virtuelle Netzwerke.
6) Zustandsbehaftete Workloads
- Compose-freundlich: Ein oder zwei zustandsbehaftete Services (Postgres, Redis) auf dedizierten VMs mit verwalteten Backups und PITR.
- Scheduler-Terrain: Dutzende StatefulSets, dynamische Volumes über Nodes hinweg oder strikte Multi-AZ-HA für Datenbanken.
7) Compliance und Isolation
- Compose-freundlich: SOC2 mit Single-Tenant-Infra pro Umgebung, geradliniger Umgang mit Secrets, Audit vom Host aus.
- Scheduler-Terrain: HIPAA/PCI mit Network Policies, Pod-Sicherheitsstufen und feingranularen Runtime-Beschränkungen.
8) Kosten und Fokus
- Compose-freundlich: Sie wollen Features shippen, nicht eine Plattform betreiben. Rechnen Sie mit 2–4 Ingenieursstunden/Monat für Infra-Wartung.
- Scheduler-Terrain: Sie bezahlen bereits für ein Plattform-Team oder einen Anbieter; Infra ist ein Wettbewerbsvorteil.
Ein produktionsreifes Compose-Blueprint (2026)
Wenn Ihre Antworten eher „Compose-freundlich“ ausfallen, dann betreiben Sie es ernsthaft. Hier ist ein Blueprint, das wir für Teams mit 10–150 rps im Schnitt (Peaks 5–10x) und 99,9 % SLO härten.
Hosts und OS
- Starten Sie mit zwei Produktions-VMs (compute-optimiert, z. B. c7a.large oder Äquivalent) hinter einem verwalteten Load Balancer. Postgres kommt auf eine eigene VM. Das bringt Isolation, einfache Wiederherstellung und vermeidet Noisy Neighbors.
- Aktivieren Sie unattended security updates und planen Sie ein wöchentliches Patch-Fenster. Da Kernel-Schwachstellen ohne Vorabankündigung ausgeliefert werden, sollten Sie mindestens monatlich mit einem Reboot rechnen. Entwerfen Sie Rolling Restarts (siehe unten).
- Härten Sie Docker: user namespaces, seccomp default, no-new-privileges, NET_RAW droppen, Memory/CPU-Limits für jeden Container setzen. Ziehen Sie rootless Docker oder Podman in Betracht, wenn Ihr Team die Trade-offs beherrscht.
Netzwerk und Ingress
- Betreiben Sie Traefik (oder Caddy) als Edge-Proxy. Auto-TLS via Let’s Encrypt, Sticky Sessions falls nötig und pro Service Canarying per Header oder Cookie.
- Nutzen Sie Compose-Netzwerke, um Service-Gruppen zu isolieren. Nur der Proxy ist ins Internet veröffentlicht. Alles andere bleibt intern.
Deploys und Zero-Downtime
- Blue/Green per Projektname: Fahren Sie zwei Stacks im selben Host-Netzwerk (z. B. Projekt „blue“ und „green“). Beim Deploy den neuen Stack starten, Health Checks bestehen lassen, dann Traefik auf die neuen Labels umschalten und den alten stoppen. Rollback ist ein Label-Flip.
- Health Checks sind entscheidend: Verwenden Sie start_period und interval/timeout/retries, um Readiness zu kodieren. Verwechseln Sie Liveness nicht mit Readiness.
- Automatisieren Sie Deploys mit einem CI-Job, der Folgendes tut: build → push → ssh → docker compose pull → neue Farbe hochfahren → Smoke-Tests ausführen → Labels flippen.
Secrets und Konfiguration
- Bevorzugen Sie einen verwalteten Secret Store (AWS SSM, GCP Secret Manager, 1Password Connect). Rendern Sie Env-Files beim Deploy und mounten Sie sie schreibgeschützt in Container.
- Wenn Sie .env-Files auf dem Host behalten müssen, speichern Sie sie verschlüsselt im Ruhezustand mit sops und entschlüsseln Sie nur im Speicher während des Deploys.
Observability
- Metriken: node_exporter + cAdvisor → Prometheus → Grafana-Dashboards. Alarmieren Sie bei Sättigung (CPU Steal, Speicherdruck), Fehlerraten und 95. Perzentil der Latenz.
- Logs: Docker → Loki via Promtail oder in den Log-Service Ihres Cloud-Providers. 14–30 Tage hot vorhalten; Älteres in Objektspeicher archivieren.
- Tracing: OpenTelemetry in ein verwaltetes Backend (Tempo, Honeycomb oder Datadog). Bei 5–10 % samplen, um Kosten im Rahmen zu halten.
Backups und Disaster Recovery
- Postgres: pgBackRest oder ein verwaltetes Postgres mit PITR. Ziel: RPO ≤ 5 Minuten (WAL Shipping) und RTO ≤ 60 Minuten.
- Assets/State: Bevorzugen Sie Objektspeicher (S3/kompatibel). Für kleine Volumes nachts mit restic sichern. Wiederherstellungen monatlich testen.
- VMs nachts snapshotten. 14 Tage Snapshots aufbewahren; einen Rebuild auf neue Hosts skripten.
Sicherheits-Posture
- Firewall: Standard „deny“; nur Load Balancer und SSH offen. Ziehen Sie Cloudflare oder Fastly davor in Betracht, um DDoS zu absorbieren. Der Ubuntu-DDoS in diesem Monat erinnert einmal mehr daran, dass Ihr Origin nicht exponiert sein sollte.
- SBOM und Image Scanning: minimale Images bauen (distroless oder slim), in CI scannen, Digests pinnen in Compose und Basis-Images zweiwöchentlich rotieren.
- Runtime: Read-only-Root-Filesysteme wo möglich aktivieren; Volumes mit minimal nötigen Berechtigungen mounten; Linux-Capabilities droppen.
Wo Compose an Grenzen stößt (und was stattdessen zu tun ist)
Seien Sie explizit über die Hülle Ihres Einsatzbereichs. Wenn eines davon auf Ihrer Roadmap auftaucht, beginnen Sie mit der Planung eines Wechsels:
- Multi-Host-Scheduling und Auto-Recovery: Wenn Container sich bei Node-Ausfall automatisch neu schedulen sollen, ohne dass Sie Blue/Green selbst orchestrieren, schauen Sie auf ECS auf Fargate (am wenigsten Ops) oder Kubernetes (meiste Kontrolle).
- Horizontales Autoscaling: Sie können Scale-up/-down in Compose skripten, aber bei stark spiky oder kostenkritischem Traffic gewinnen native HPA/ECS Service Auto-Scaling.
- Network Policies und mTLS-by-default: Mit iptables und Sidecars kann man es nachbauen, aber es ist fragil. Wenn Sie feingranulare Netzwerkisolation brauchen, wechseln Sie.
- Dutzende Teams und Services: Self-Service-Infra braucht Leitplanken, Quoten und Template-Ressourcen. Das ist ein Plattformproblem, kein compose.yaml-Problem.
- Schwergewichtiges GPU/ML-Scheduling oder Batch-Job-Orchestrierung: Nutzen Sie einen Scheduler, der für Accelerators und flüchtige Jobs gebaut ist.
Kosten: der Teil, den die meisten Teams falsch bepreisen
Im kleinen Maßstab ist die Kubernetes-Steuer vor allem Menschenzeit. Selbst mit verwalteten Control Planes sollten Sie Folgendes erwarten:
- Managed-k8s-Baseline: Control-Plane-Gebühren (70–150 $/Monat), NAT-Gateways (30–70 $/Monat jeweils) plus der Overhead von Node-Gruppen. In der Praxis sehen wir meist 800–2.000 $/Monat bevor App-Last überhaupt anliegt.
- Ingenieurszeit: 8–20 Stunden/Monat für Cluster-Hygiene, Upgrades und die „Es ist immer DNS“-Klasse von Problemen. Bei einem vollkostenbereinigten Stundensatz von 150 $ sind das 1.200–3.000 $/Monat.
- Compose-Baseline: zwei mittelgroße VMs zu je 80–120 $, eine verwaltete Datenbank 150–400 $, ein Load Balancer 20–30 $. Nennen wir es 350–700 $/Monat Infra und 2–4 Stunden/Monat Pflege, wenn Sie den Stack klein und diszipliniert halten.
Das ist nicht theoretisch. Wir betreiben Production-Compose für Startups mit 10–30 Mio. Requests/Monat bei 99,9 % SLO für 20–40 % niedrigere Infra-Kosten und 50–70 % weniger Ops-Zeit als ihr vorheriges „Starter-k8s“. Der Trade-off ist Kapazitätsplanung und einfache Fehlermodi, die Sie selbst kodifizieren müssen.
Konkretes Deployment-Muster (das wirklich funktioniert)
- Repo-Struktur: App-Code + infra/compose mit per-Umgebung-Overrides (compose.prod.yaml, compose.staging.yaml). Images versionieren und per Digest pinnen.
- Build: Multi-Stage-Dockerfiles, distroless/slim Bases, SBOM-Generierung. In ein privates Registry pushen.
- Release Candidate: CI-Job taggt das Image mit Git-SHA und schreibt ein Release-Manifest mit Image-Digests.
- Deploy: CI verbindet sich via SSH mit dem Zielhost/den Zielhosts, zieht das Release-Manifest, startet die neue Farbe mit docker compose up -d, wartet auf Health und flippt die Traefik-Labels.
- Smoke-Test: eine kurze E2E-Suite gegen die Canary-Route (header-basiert) laufen lassen; wenn sauber, auf 100 % promoten.
- Post-Deploy: Dashboards, Error Budgets verifizieren und bei Bedarf per Label-Flip zurückrollen.
Lassen Sie „watchtower auto-updates“ weg. Das tauscht Wiederholbarkeit gegen Überraschung. Sie wollen intentionale Deploys – auch mit Compose.
Operating Practice: Patching und Incident Response
Die letzten Wochen waren eine Erinnerung: Angreifer lieben die Long Tail. Der cPanel-Auth-Bypass und der Ubuntu-DDoS war es egal, ob Teams k8s oder Compose betrieben; bestraft wurden langsames Patching und exponierte Origins. Behandeln Sie Patching als First-Class-Workflow:
- Wöchentliches Patch-Fenster: planen und ankündigen. Im Blue/Green-Modus die inaktive Farbe patchen, flippen, dann die andere patchen.
- Kernel-Realitäten: Bei Kernel-CVEs ohne „Heads-up“ von vornherein mit Reboots rechnen. Entwerfen Sie dafür. Ihr Blue/Green-Prozess sollte einen Reboot zum Non-Event machen.
- CDN davor schalten: volumetrische DDoS absorbieren und Bad Actors rate-limitieren. TLS am Edge terminieren und Origins privat halten.
Wann die Migration planen (bevor es weh tut)
Warten Sie nicht, bis Schmerzen Sie in einen 90-Tage-Plattform-Refactor zwingen. Starten Sie ein Migrationsradar, sobald eines davon zutrifft:
- Zwei oder mehr Teams fragen nach Self-Serve-Umgebungen.
- Sie brauchen Autoscaling schneller, als Ihre CI/CD eine neue Farbe ausrollen kann.
- Security fordert Network Policies, die Sie am Host nicht komfortabel durchsetzen können.
- Ihre Service-Anzahl überschreitet ~30 und Ihre Compose-Files fühlen sich wie eine Rube-Goldberg-Maschine an.
Wählen Sie dann einen Scheduler auf Basis Ihrer Cloud und Ihres Talentpools: ECS auf Fargate für den geringsten Ops-Aufwand (insbesondere bei AWS-zentrischen Stacks), Kubernetes, wenn Sie Portabilität oder tiefe Ökosystem-Features brauchen, oder Nomad, wenn Sie Einfachheit schätzen und ohne k8s-Allgegenwart leben können. Budgetieren Sie die Migration wie ein Feature: 6–10 Wochen für ein erfahrenes Team, länger, wenn Sie gleichzeitig Netzwerk und CI neu designen.
Ein realistisches Beispiel
Ein Series-A-Fintech-ähnliches SaaS: 6 Microservices (Go + Node), ein Worker, ein geplanter Job, Postgres, Redis, 10 Mio. Requests/Monat (Ø 4 rps, Peak 50–100 rps), 2–3 Engineers im On-Call. Ziele: 99,9 % SLO, SOC2, US/EU-Kunden.
- Infra: zwei c7a.large App-VMs + verwaltetes Postgres + Redis auf einer kleinen VM. Traefik auf jeder App-VM; der Cloud-Load-Balancer verteilt auf beide.
- Deploys: Blue/Green pro Host, Label-Flip via Traefik, 1–2 Deploys/Tag.
- Security: SBOM in CI, Image-Digest-Pinning, Secrets aus SSM, Read-only-Roots, no-new-privileges, NET_RAW gedroppt. CDN davor, Origins privat.
- Ops: 2 Stunden/Woche: Patching, Dashboard-Checks, monatlicher Restore-Test. Observability nach Grafana + Loki + Tempo.
- Ergebnisse: 99,93 % Verfügbarkeit über ein Quartal; ein Incident (15 Minuten) zurückgeführt auf eine ungebremste Worker-Queue, behoben durch Setzen von Compose-Memory-Limits und Backpressure.
Wo Nearshore passt
Wenn Sie Compose wählen, wählen Sie eine kleinere Ops-Fläche – gut. Aber Patch-Fenster und Incidents mitten in der Nacht passieren trotzdem. Ein in Brazil ansässiges SRE-Team mit 6–8 Stunden US-Überlappung kann den wöchentlichen Patch-Zyklus fahren, Blue/Green-Flips managen und After-Hours-Incidents übernehmen, während Ihr Kernteam schläft. Unserer Erfahrung nach reicht ein Nearshore-SRE-Engagement von 0,5–1,0 FTE, um einen Produktions-Compose-Stack compliant, aktuell und langweilig zu halten – genau das, was Sie wollen.
Fazit
Docker Compose in der Produktion ist kein schmutziges Geheimnis; es ist eine bewusste Abwägung. Wenn Sie unter 30 Services liegen, ein 99,9 %-SLO anstreben und weder Mandantenisolation noch Multi-AZ-Rescheduling benötigen, können Sie mit Compose schneller vorankommen und weniger ausgeben—vorausgesetzt, Sie härten den Host, automatisieren Blue/Green, schalten ein CDN davor und behandeln Patching wie Produktarbeit. Wenn Ihre Roadmap einen Scheduler verlangt, werden Sie es wissen. Bis dahin: Halten Sie Ihren Stack einfach und Ihre Error Budgets grün.
Key Takeaways
- Compose ist 2026 produktionsfähig für kleine Teams, vorhersehbare Workloads und 99,9 %-SLOs—wenn Sie es wie Produktion betreiben.
- Nutzen Sie einen gehärteten Linux-Host, Traefik/Caddy, Blue/Green per Projektname, per Digest gepinnte Images und echte Health Checks.
- Erwarten Sie 20–40 % niedrigere Infra-Kosten und 50–70 % weniger Ops-Zeit als „Starter-k8s“ im kleinen Maßstab; investieren Sie die gewonnene Zeit in Features.
- Security ist Pflichtprogramm: Default-Deny-Firewall, CDN davor, Read-only-Roots, gedroppte Capabilities, wöchentliche Patch-Fenster und getestete Backups.
- Planen Sie eine Migration, wenn Sie Autoscaling, feingranulare Network Policies, Mandantenisolation benötigen oder ~30 Services überschreiten.
- Nearshore-SRE (Brazil) übernimmt Patching und Incidents mit 6–8 Stunden Überlappung und hält Ihren Compose-Stack langweilig und compliant.