Docker Compose Befehle: Das Cheat Sheet

Q: Was sind die wichtigsten docker compose Befehle?

up -d, logs -f , exec, ps, pull, restart , down und config -q decken den großen Teil des Tagesbetriebs auf einem echten Homelab-Stack ab.

Q: Wie führe ich einen docker compose Befehl für nur einen Dienst aus?

Fügen Sie den Dienstnamen als letztes Argument hinzu: docker compose logs -f app, docker compose restart app, docker compose pull app und docker compose exec app sh wirken alle nur auf diesen einen Container.

Q: Was ist der Unterschied zwischen docker compose up und docker compose up -d?

Reines up läuft im Vordergrund und streamt die Logs jedes Containers in Ihr Terminal, bis Sie es stoppen. up -d startet dieselben Container losgelöst im Hintergrund — die Form, die Sie für alles wollen, was dauerhaft laufen soll.

Q: Wie aktualisiere ich nur das Image eines Dienstes, ohne alle zu pullen?

Benennen Sie den Dienst: docker compose pull app statt docker compose pull. Ohne Dienstnamen lädt Compose das Image für jeden in der Datei definierten Dienst.

Ein README verspricht über 40 Compose-Subcommands und für jedes davon eine Seite voller Flags. In der Praxis bedeutet der Betrieb von neun Stacks auf einem Homelab-Host, dass Sie täglich etwa acht davon greifen und den Rest ignorieren, bis ein konkretes Problem Sie zum Nachschlagen zwingt.

TL;DR

Acht Befehle decken den überwältigenden Großteil der echten Tagesarbeit mit Compose ab: up -d, logs -f <dienst>, exec, ps, pull, restart <dienst>, down und config.
pull, logs, restart und exec akzeptieren alle einen optionalen Dienstnamen — lassen Sie ihn weg, wirkt der Befehl auf jeden Dienst in der Datei, nicht nur auf den einen, den Sie gemeint haben.
docker compose config -q löst die gesamte Datei auf (inklusive .env-Interpolation) und validiert sie, ohne irgendetwas zu starten — der günstigste Sanity-Check vor up.
down entfernt Container und Netzwerke; stop hält sie nur an. Die beiden sind nicht austauschbar, und unser Vergleich down vs. stop vs. kill deckt die vollständige Unterscheidung ab.
Mein eigenes Homelab betreibt neun Compose-Stacks auf einem Host, laut dem Self-Hosting-Leitfaden — die Tabelle unten ist genau die Teilmenge, die den täglichen Betrieb über alle hinweg abdeckt.

Die Befehle, die Sie wirklich täglich brauchen

Laut der offiziellen Compose-CLI-Referenz akzeptiert jeder dieser Befehle ein optionales [SERVICE]-Argument, sofern nicht anders vermerkt — diese Unterscheidung zählt mehr als der Befehl selbst, sobald Sie mehr als einen Container pro Stack betreiben.

Befehl	Was er tut	Wann Sie ihn brauchen
`up -d`	Erstellt und startet alle Container im Hintergrund	Einen Stack nach einem Pull oder einer Konfigänderung hochfahren
`logs -f <dienst>`	Verfolgt die Live-Ausgabe eines Dienstes	Beim Boot eines Containers zusehen oder einen Fehler in Echtzeit diagnostizieren
`exec <dienst> sh`	Öffnet eine Shell in einem laufenden Container	Eine Datei, Env-Var oder einen Prozess im Container prüfen
`ps`	Listet die Container dieses Projekts und ihren Status	Bestätigen, dass wirklich alles `running` ist, nicht am Neustarten
`pull <dienst>`	Lädt das neueste Image für einen Dienst herunter	Eine einzelne App aktualisieren, ohne ihre Datenbank oder ihr Cache-Image zu berühren
`restart <dienst>`	Stoppt und startet den Container eines Dienstes	Eine Konfigänderung übernehmen, die kein volles `up` braucht
`down`	Stoppt und entfernt Container und Netzwerke (keine Volumes)	Einen Stack sauber abbauen, z. B. vor einem `docker compose up --build`
`config -q`	Validiert und löst die Datei auf; gibt bei Fehlerfreiheit nichts aus	Einen YAML- oder Interpolationsfehler abfangen, bevor `up` überhaupt läuft

Das ist die Arbeitsmenge. Alles andere — top, images, cp, port, events, kill — existiert, wird vielleicht ein paar Mal im Jahr gebraucht, und es lohnt sich, zu wissen, dass es existiert, statt es sich einzuprägen.

Einen Befehl auf einen Dienst in einer gemeinsamen Datei beschränken

Das ist der Teil, den die meisten Referenzen auslassen, weil sie jeden Befehl isoliert dokumentieren statt im Kontext einer Datei mit fünf oder sechs Diensten darin. Vier der obigen Befehle ändern ihr Verhalten, je nachdem, ob Sie einen Dienst benennen:

docker compose pull          # lädt das Image für jeden Dienst in der Datei
docker compose pull app      # lädt nur das Image von app — db, redis usw. bleiben unberührt

Warning: Laut der Referenz zum pull-Befehl ist der Dienstname optional — das heißt, docker compose pull ohne Argument lädt das Image jedes Dienstes, auch solcher, die Sie gar nicht anfassen wollten. Bei einem Stack mit Postgres- und Redis-Container neben Ihrer App sind das zwei zusätzliche Downloads, die Sie nicht brauchten — und bei einer langsamen Verbindung eine mehrminütige Wartezeit für ein Update, das Sie mit einem Wort hätten eingrenzen können.

Das gleiche Muster gilt für logs, restart und exec:

docker compose logs -f app     # nur der Log-Stream von app
docker compose restart app     # nur der Container von app startet neu
docker compose exec app sh     # Shell gezielt in app

Ich führe docker compose pull app && docker compose up -d app als Paar aus, wann immer ein Dienst in einem Stack ein neues Image bekommt — es aktualisiert genau diesen Container, bestätigt, dass das Image in einen healthy-Zustand gewechselt ist, und lässt die Laufzeit des Datenbank-Containers (und seinen "ready"-Status aus dem depends_on-Artikel) völlig ungestört.

up vs. up -d vs. up --build

Reines docker compose up läuft im Vordergrund und streamt die Logs jedes Containers in Ihr Terminal, bis Sie mit Ctrl-C abbrechen — nützlich für einen ersten Lauf, bei dem Sie das Hochfahren beobachten wollen, nutzlos für alles, was Sie laufen lassen wollen. up -d löst sich sofort vom Terminal. up -d --build baut jeden Dienst mit einem build:-Schlüssel neu, bevor er startet — nötig nach dem Bearbeiten eines Dockerfiles, aber nie nur nach dem Bearbeiten der docker-compose.yml selbst, denn ein einfaches up -d übernimmt YAML-Änderungen bereits.

Tip: Wenn up -d meldet, dass alles schon läuft, eine Konfigänderung aber offensichtlich nicht angewendet wurde, fügen Sie --force-recreate hinzu. Compose erstellt einen Container nur neu, wenn es eine relevante Änderung erkennt, und manche Edits — etwa ein hinzugefügter environment:-Schlüssel mit demselben aufgelösten Wert — lösen diese Erkennung nicht immer aus.

Logs lesen, ohne darin zu ertrinken

8Befehle, die praktisch den gesamten Tagesbetrieb von Compose in meinem eigenen Homelab über neun laufende Stacks abdecken, eigene Zählung in diesem Artikel

docker compose logs -f <dienst> ohne Dienstnamen verschachtelt die Ausgabe aller Container in einem Stream, mit Zeitstempel, aber ohne visuelle Trennung — bei einem Zwei-Dienste-Stack in Ordnung, bei allem Größerem unlesbar. Fügen Sie --tail 100 hinzu, um bei aktuellen Ausgaben zu starten, statt bei jedem Follow die komplette Historie zu wiederholen. Wenn eine einzelne logs -f-Session nicht reicht, um den eigentlichen Fehler zu finden, setzt dort unser Leitfaden zum Debuggen eines kaputten Compose-Stacks an — er behandelt die nächste Ebene, sobald Logs allein das Symptom nicht erklären.

Stoppen vs. Entfernen: down, stop, kill

Eine Zeile, denn die vollständige Aufschlüsselung existiert bereits anderswo auf dieser Seite: stop hält Container an, lässt sie (und das Netzwerk) aber für einen schnellen start bestehen; down entfernt sowohl Container als auch Netzwerke, was Sie vor einem Neuaufbau aus einer geänderten Compose-Datei wollen; kill überspringt das geordnete Shutdown-Signal komplett und sollte für einen Container reserviert sein, der tatsächlich hängt. Unser Leitfaden down vs. stop vs. kill deckt ab, wann welcher die richtige Wahl ist, inklusive der Exit-Code- und Signal-Details, die dieses Cheat Sheet nicht wiederholt.

config: der Befehl, den alle überspringen

docker compose config -q löst jede ${VAR}-Interpolation auf, mergt alle Override-Dateien und validiert das Ganze — und gibt dann bei Fehlerfreiheit überhaupt nichts aus. Laut der Compose-CLI-Referenz bedeutet ein Exit-Code ungleich null, dass die Datei nicht geparst oder aufgelöst werden konnte, was ihn zum günstigsten möglichen Check macht, den Sie vor up ausführen können, statt erst nachdem ein Stack nicht so hochkam wie erwartet.

Note: config -q fängt YAML-Syntaxfehler und fehlende Interpolationsvariablen ab. Es fängt nicht einen falsch konfigurierten Healthcheck oder einen Dienst, der in falscher Reihenfolge startet — das sind Laufzeitprobleme, keine Parse-Zeit-Probleme.

FAQ

Was sind die wichtigsten docker compose Befehle?

up -d, logs -f <dienst>, exec, ps, pull, restart <dienst>, down und config -q decken den großen Teil des Tagesbetriebs auf einem echten Homelab-Stack ab.

Wie führe ich einen docker compose Befehl für nur einen Dienst aus?

Fügen Sie den Dienstnamen als letztes Argument hinzu: docker compose logs -f app, docker compose restart app, docker compose pull app und docker compose exec app sh wirken alle nur auf diesen einen Container.

Was ist der Unterschied zwischen docker compose up und docker compose up -d?

Reines up läuft im Vordergrund und streamt die Logs jedes Containers in Ihr Terminal, bis Sie es stoppen. up -d startet dieselben Container losgelöst im Hintergrund — die Form, die Sie für alles wollen, was dauerhaft laufen soll.

Wie aktualisiere ich nur das Image eines Dienstes, ohne alle zu pullen?

Benennen Sie den Dienst: docker compose pull app statt docker compose pull. Ohne Dienstnamen lädt Compose das Image für jeden in der Datei definierten Dienst.

Was macht docker compose config?

Es löst die Compose-Datei auf — mergt Override-Dateien und interpoliert .env-Variablen — und validiert das Ergebnis, ohne Container zu starten. Mit -q ausgeführt ergibt das einen stillen Pass/Fail-Check vor up.

Fazit

Die anderen 30-plus Compose-Subcommands zu dokumentieren ist nicht falsch, sie werden nur nicht an einem Dienstag eingetippt. Acht Befehle, plus die Gewohnheit, einen Dienst zu benennen, wenn Sie einen Dienst meinen statt alle, decken den echten Tagesbetrieb eines Multi-Stack-Homelabs ab. Für das Stack-Layout und das Reverse-Proxy-Setup, auf dem diese Befehle operieren, deckt der Self-Hosting-Leitfaden den Rest ab; wenn einer dieser Befehle ein Problem aufdeckt statt es zu lösen, ist der Debugging-Leitfaden der nächste Schritt.