Sobald eine Anwendung aus mehr als einem Container besteht, etwa aus einer Web-App, einer Datenbank und vielleicht einem Cache, wird das manuelle Starten mit docker run schnell unübersichtlich. Genau hier setzt Docker Compose an. Mit einer einzigen Datei beschreiben Sie den gesamten Stack und starten ihn mit einem Befehl. Diese Anleitung zeigt Ihnen den Aufbau der compose.yaml, die wichtigsten Befehle und ein realistisches Beispiel aus Web-App und PostgreSQL. Und sie erklärt ehrlich, wo die Grenzen von Docker Compose liegen und wann sich ein Wechsel zu einer verwalteten Plattform lohnt.
Kurz gesagt: Docker Compose ist ein Werkzeug, mit dem Sie mehrere Container als zusammenhängende Anwendung in einer einzigen Datei (compose.yaml) beschreiben und mit einem Befehl starten. Sie definieren Dienste, Volumes, Netzwerke und Umgebungsvariablen deklarativ, und docker compose up -d startet den gesamten Stack. Ideal für lokale Entwicklung und einen einzelnen Server.
Was ist Docker Compose?
Docker Compose löst ein konkretes Problem: Reale Anwendungen bestehen selten aus einem einzelnen Container. Ein typischer Stack umfasst mindestens einen Anwendungsdienst und eine Datenbank, oft ergänzt um einen Cache oder einen Hintergrund-Worker. Ohne Compose müssten Sie jeden dieser Container einzeln starten, verbinden und mit Umgebungsvariablen versorgen. Das ist fehleranfällig und lässt sich schlecht wiederholen.
Docker Compose ist ein offizielles Docker-Werkzeug zur Definition und Ausführung von Anwendungen aus mehreren Containern. Die gesamte Konfiguration liegt in einer YAML-Datei, sodass sich ein kompletter Stack reproduzierbar starten, stoppen und in der Versionsverwaltung ablegen lässt.
Der große Vorteil ist die Deklarativität. Sie beschreiben den gewünschten Zustand, und Compose sorgt dafür, dass er eintritt. Die Datei liegt neben Ihrem Code im Repository, sodass jedes Teammitglied mit exakt demselben Setup arbeitet. Details zum Werkzeug finden Sie in der offiziellen Docker-Compose-Dokumentation.
Die compose.yaml verstehen
Die zentrale Datei heißt heute standardmäßig compose.yaml (der ältere Name docker-compose.yml funktioniert weiterhin). Sie besteht im Kern aus wenigen Abschnitten auf oberster Ebene.
Eine compose.yaml ist die deklarative Beschreibung eines Anwendungs-Stacks. Sie listet unter
servicesjeden Container mit Image, Ports, Umgebungsvariablen und Abhängigkeiten auf und verbindet diese über gemeinsame Netzwerke und persistente Volumes.
Die wichtigsten Bausteine im Überblick:
- services: Jeder Eintrag ist ein Container. Sie geben entweder ein fertiges
imagean oder lassen mitbuildein lokales Docker-Image aus einem Dockerfile bauen. - volumes: Benannte Volumes speichern Daten dauerhaft, auch wenn ein Container neu erstellt wird. Ohne Volume verlieren Sie beim nächsten Neustart die Datenbankinhalte.
- networks: Compose legt automatisch ein Standardnetzwerk an. Über eigene Netzwerke steuern Sie gezielt, welche Dienste sich gegenseitig erreichen. Innerhalb des Netzwerks sprechen sich Container über ihren Dienstnamen an, zum Beispiel
db. - environment: Hier setzen Sie Umgebungsvariablen, etwa Zugangsdaten oder eine
DATABASE_URL. - depends_on: Legt die Startreihenfolge fest und wartet mit
condition: service_healthyoptional darauf, dass ein Dienst wirklich bereit ist.
Die vollständige Referenz aller Schlüssel steht in der Compose-Dateireferenz.
Ein realistisches Beispiel: Web-App plus PostgreSQL
Sehen wir uns einen typischen Stack an: eine Web-Anwendung, die aus dem lokalen Dockerfile gebaut wird, zusammen mit einer PostgreSQL-Datenbank. Beide liegen in einem privaten Netzwerk, und die Datenbank speichert ihre Daten in einem benannten Volume.
services:
web:
build: .
ports:
- "3000:3000"
environment:
DATABASE_URL: postgres://app:${DB_PASSWORD}@db:5432/app
depends_on:
db:
condition: service_healthy
networks:
- backend
db:
image: postgres:16
environment:
POSTGRES_USER: app
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_DB: app
volumes:
- db-data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U app"]
interval: 5s
timeout: 5s
retries: 5
networks:
- backend
volumes:
db-data:
networks:
backend:Beachten Sie drei Details. Erstens erreicht die Web-App die Datenbank über den Hostnamen db, also den Dienstnamen. Das interne DNS von Compose übernimmt die Auflösung, eine feste IP-Adresse ist nicht nötig. Zweitens sorgt der healthcheck in Kombination mit depends_on dafür, dass die App erst startet, wenn PostgreSQL Verbindungen annimmt. Drittens landet das Passwort nicht im Klartext in der Datei, sondern kommt aus einer Variable. Hinweise zum offiziellen Datenbank-Image finden Sie in der PostgreSQL-Dokumentation.
Die .env-Datei nutzen
Compose liest automatisch eine Datei namens .env im selben Verzeichnis ein und ersetzt Platzhalter wie ${DB_PASSWORD}. So halten Sie Geheimnisse aus der versionierten compose.yaml heraus.
# .env
DB_PASSWORD=ein-sicheres-passwortNehmen Sie die .env in Ihre .gitignore auf, damit keine Zugangsdaten im Repository landen. Für die Zusammenarbeit im Team legen Sie zusätzlich eine .env.example mit leeren oder Beispielwerten an, die den Aufbau dokumentiert, ohne echte Geheimnisse preiszugeben.
Die wichtigsten Docker-Compose-Befehle
Der Alltag mit Docker Compose kommt mit einer Handvoll Befehle aus. Alle werden im Verzeichnis mit der compose.yaml ausgeführt.
docker compose up -d # Stack im Hintergrund starten (detached)
docker compose ps # Laufende Dienste und Status anzeigen
docker compose logs -f web # Logs eines Dienstes live verfolgen
docker compose down # Stack stoppen und Container entfernenEin paar Erläuterungen. Das Flag -d (detached) startet den Stack im Hintergrund, sodass Ihr Terminal frei bleibt. docker compose down entfernt Container und Netzwerke, lässt benannte Volumes aber standardmäßig bestehen, damit Ihre Datenbankdaten erhalten bleiben. Erst docker compose down -v löscht auch die Volumes, was Sie also bewusst und mit Vorsicht einsetzen sollten. Mit docker compose up -d --build erzwingen Sie einen frischen Build, wenn sich Ihr Code oder das Dockerfile geändert hat.
Wann Docker Compose reicht, und wo die Grenzen liegen
Docker Compose ist hervorragend für die lokale Entwicklung. Ein einziger Befehl bringt den kompletten Stack auf jedem Rechner zum Laufen, unabhängig vom Betriebssystem. Auch für kleine Projekte auf einem einzelnen Server ist Compose eine solide und einfache Wahl.
Die Grenzen ergeben sich aus dem Design. Compose orchestriert Container auf genau einer Maschine. Sobald Sie mehrere Server, automatische Ausfallsicherheit oder Rolling Updates ohne Ausfallzeit benötigen, sprengt das den Rahmen von Docker Compose. Für diesen Schritt greifen Teams klassisch zu einem Orchestrierungssystem. Wie sich die beiden Ebenen unterscheiden, lesen Sie im Vergleich Kubernetes und Docker.
Konkret bedeutet das: Fällt Ihr einzelner Server aus, ist die gesamte Anwendung offline. Compose kennt keine Verteilung über mehrere Knoten und keine eingebaute Skalierung über Maschinengrenzen hinweg. Außerdem sind Sie für alles rund um den Host selbst verantwortlich, also für Betriebssystem-Updates, HTTPS-Zertifikate, Datenbank-Backups und Monitoring. Bei einem einzelnen Hobbyprojekt ist das machbar. Bei mehreren produktiven Diensten wird der Betriebsaufwand schnell spürbar. Wenn Sie einen dauerhaften Docker-Betrieb planen, hilft der Überblick zum Docker-Hosting in Deutschland.
Von Docker Compose zu einer verwalteten Plattform
Eine compose.yaml denkt in Diensten, und genau dieses Modell übertragen Sie fast unverändert auf eine PaaS. Der Unterschied: Sie verwalten keinen Docker-Host mehr selbst.
Eine PaaS (Platform as a Service) nimmt Ihnen den Betrieb des Servers ab. Sie liefern Code oder ein Dockerfile, die Plattform baut das Image, startet den Container, richtet automatisch HTTPS ein und stellt eine verwaltete Datenbank bereit, ohne dass Sie Betriebssystem, Zertifikate oder Volumes von Hand pflegen.
Auf Out Plane bilden Sie denselben Stack ab, den Sie zuvor in der compose.yaml beschrieben haben. Jeden Dienst deployen Sie einzeln, entweder aus einem Dockerfile oder über einen automatisch erkannten Buildpack, und die Plattform übernimmt den Build. Ihre öffentliche App erreichen Sie unter einer Adresse nach dem Muster {name}-{port}-{teamSlug}.outplane.app, mit automatischem HTTPS.
Die Datenbank aus dem Beispiel wird zu einer verwalteten PostgreSQL-Instanz mit Backups, Point-in-Time-Recovery, Read Replicas, Connection Pooling und pgvector. Sie administrieren keinen postgres-Container mehr selbst. Wichtig für die ehrliche Einordnung: Verwaltet ist ausschließlich PostgreSQL. Dienste wie Redis oder ein selbst gehosteter Cache, die Sie in Compose als weiteren Container laufen ließen, betreiben Sie auf der Plattform ebenfalls als eigenen Container mit einem persistenten Volume, dann allerdings in eigener Verantwortung. Ein privates Netzwerk verbindet Ihre Dienste untereinander, ähnlich dem gemeinsamen backend-Netzwerk in Ihrer compose.yaml. Was eine PaaS grundsätzlich leistet, erklärt der Artikel Was ist PaaS?. Wie die verwaltete Datenbank aussieht, zeigt der Beitrag zum kostenlosen PostgreSQL-Hosting.
| Aspekt | Docker Compose auf eigenem Server | Verwaltete Plattform (Out Plane) |
|---|---|---|
| Server-Wartung | Sie pflegen OS, Docker und Sicherheitsupdates | Von der Plattform übernommen |
| Image-Build | Lokal oder in Ihrer CI | Aus Dockerfile oder Buildpack, von der Plattform gebaut |
| HTTPS | Zertifikate selbst einrichten und erneuern | Automatisch pro Dienst |
| PostgreSQL | Container plus Backups von Hand | Verwaltet: Backups, PITR, Read Replicas, pgvector |
| Ausfallsicherheit | Ein Host, ein Ausfallpunkt | Verwalteter Betrieb der Container |
| Netzwerk | Compose-Netzwerk auf einer Maschine | Privates Netzwerk zwischen den Diensten |
| Betriebsaufwand | Vollständig bei Ihnen | Deutlich reduziert |
Häufig gestellte Fragen
Was ist der Unterschied zwischen Docker und Docker Compose?
Docker startet und verwaltet einzelne Container über Befehle wie docker run. Docker Compose ist eine Ebene darüber und beschreibt in einer YAML-Datei mehrere zusammengehörige Container als einen Stack. Statt jeden Container einzeln zu starten, verwalten Sie den kompletten Verbund deklarativ mit einem Befehl.
Wie starte und stoppe ich einen Compose-Stack?
Im Verzeichnis mit der compose.yaml startet docker compose up -d den gesamten Stack im Hintergrund. Mit docker compose ps sehen Sie den Status, mit docker compose logs -f verfolgen Sie die Ausgaben. docker compose down stoppt und entfernt die Container, lässt benannte Volumes aber standardmäßig unangetastet.
Wofür brauche ich die .env-Datei?
Die .env-Datei hält Geheimnisse und umgebungsspezifische Werte aus der versionierten compose.yaml heraus. Compose liest sie automatisch ein und ersetzt Platzhalter wie ${DB_PASSWORD}. Nehmen Sie die Datei in die .gitignore auf und dokumentieren Sie die erwarteten Variablen zusätzlich in einer .env.example ohne echte Werte.
Ist depends_on genug, damit meine Datenbank vor der App bereit ist?
Nicht allein. Ohne Zusatz steuert depends_on nur die Startreihenfolge, nicht die tatsächliche Bereitschaft. Ergänzen Sie einen healthcheck am Datenbankdienst und condition: service_healthy beim abhängigen Dienst. Erst dann wartet Compose, bis PostgreSQL wirklich Verbindungen annimmt, bevor die Anwendung startet.
Reicht Docker Compose für die Produktion?
Für kleine Projekte auf einem einzelnen Server kann Compose genügen. Die Grenzen liegen in einem Ausfallpunkt, fehlender Verteilung über mehrere Maschinen und im Betriebsaufwand für HTTPS, Backups und Updates. Für ausfallsichere oder wachsende Systeme ist eine Orchestrierung oder eine verwaltete Plattform die bessere Wahl.
Wie sichere ich die PostgreSQL-Daten in einem Compose-Setup?
Legen Sie die Daten in einem benannten Volume ab, wie im Beispiel mit db-data, damit sie einen Neustart überstehen. Regelmäßige Backups müssen Sie jedoch selbst einrichten, etwa per pg_dump in einem geplanten Job. Eine verwaltete Datenbank nimmt Ihnen genau diese Backup- und Wiederherstellungsaufgaben ab.
Wann sollte ich von Docker Compose auf eine Plattform wechseln?
Sobald der Betriebsaufwand für einen selbst gepflegten Host, für HTTPS und für Datenbank-Backups Ihre Zeit auffrisst, oder wenn ein einzelner Ausfallpunkt zum Risiko wird. Eine PaaS übernimmt Build, HTTPS und die verwaltete PostgreSQL-Datenbank, während Sie Ihr aus Compose bekanntes Dienstmodell beibehalten.
Fazit
Docker Compose bringt einen kompletten Stack aus mehreren Containern mit einer einzigen Datei und einem Befehl zum Laufen, ideal für die lokale Entwicklung und einen einzelnen Server. Sie kennen jetzt den Aufbau der compose.yaml, die zentralen Befehle, die Rolle der .env und ein realistisches Beispiel aus Web-App und PostgreSQL. Ebenso klar sind die Grenzen: eine Maschine, keine eingebaute Ausfallsicherheit und Betrieb in Eigenregie.
Wenn Sie dasselbe Dienstmodell ohne die Last eines eigenen Docker-Hosts betreiben möchten, deployen Sie jeden Dienst aus einem Dockerfile oder Buildpack und hängen eine verwaltete PostgreSQL-Datenbank daneben. Legen Sie direkt in der Konsole unter https://console.outplane.com los. Der Hobby-Tarif ist dauerhaft kostenlos, und Sie starten mit 20 US-Dollar Startguthaben ohne Kreditkarte. Die Konditionen im Detail finden Sie unter /pricing.