Docker Compose für Self-Hosting: Der Leitfaden

Der dritte Dienst kam mit einem kopierten docker run-Befehl hinzu, der vierte mit einem leicht anderen, und der fünfte stürzte über Nacht ab — ganz ohne Restart-Policy, lautlos, bis eine Prüfung am nächsten Morgen ihn seit neun Stunden tot vorfand. An diesem Stack war nichts zufällig; jede Zeile war einmal entschieden worden, schlecht, und nie wieder überprüft. Compose behebt schlechte Entscheidungen nicht von selbst. Es zwingt Sie nur dazu, jede einzelne bewusst zu treffen, ein einziges Mal, in einer Datei, die Sie tatsächlich wieder lesen können.

Warum Compose die richtige Standardwahl ist, und wo es an seine Grenzen stößt

Docker Compose beschreibt einen Stack deklarativ: Eine einzige YAML-Datei listet jeden Dienst, sein Image, seine Volumes, sein Netzwerk, sein Restart-Verhalten. docker compose up ausgeführt, und Compose gleicht die Realität an diese Beschreibung an — es spielt keine Rolle, ob ein Container bereits existiert, gestoppt ist oder nie lief; Compose findet heraus, was nötig ist, um dorthin zu gelangen. Das ist das Gegenteil eines Shell-Skripts voller docker run-Flags, deren Begründung sechs Monate später niemand mehr kennt.

Compose bleibt das richtige Werkzeug, solange alles auf einem Host läuft. Sobald ein Homelab verlangt, dass ein Dienst den Ausfall einer ganzen Maschine überlebt — nicht nur einen Container-Neustart —, ist das ein anderes Problem (Swarm oder Kubernetes) und liegt außerhalb dieses Leitfadens. Für einen einzelnen Host, was auf die meisten Homelabs zutrifft, ist Compose keine Zwischenstufe zu etwas Ernsthafterem. Es ist bereits das ernsthafte Werkzeug.

Die sieben Entscheidungen, in einer Tabelle

Entscheidung	Falscher Standard	Was Sie stattdessen wählen sollten	Ausführlich behandelt
Restart-Policy	Gar keine restart:-Zeile	unless-stopped für dauerhaft laufende Dienste	Restart-Policies
Netzwerk	Jeder Dienst auf Composes flachem Standard-Bridge-Netzwerk	Ein internes Netzwerk pro Stack, ein gemeinsames Netzwerk für den Proxy	Netzwerk
Volumes	Das Datenverzeichnis einer Datenbank beiläufig per Bind-Mount einbinden	Named Volumes für Engine-Daten, Bind-Mounts für Konfigurationen	Volumes und Backups
Secrets	Klartext-Werte unter environment:	Mindestens env_file:, secrets: für alles Sensible	Secrets vs. .env
Build vs. Pull	Annehmen, up baue ein geändertes Dockerfile automatisch neu	up --build, oder build --no-cache, wenn der Cache selbst verdächtig ist	Build vs. Pull
Logs	Erst hinsehen, wenn schon etwas kaputt ist	docker compose logs -f --tail als feste Gewohnheit, nicht als letzten Ausweg	Begleitender Deep Dive, in Arbeit
Teardown	Aus Gewohnheit zu down -v greifen	Den Befehl danach wählen, ob Daten erhalten bleiben müssen	Down vs. Stop vs. Kill

Restart-Policy: was einen Reboot bewusst übersteht

restart: entscheidet, was nach einem Absturz oder einem Host-Reboot passiert, und Composes tatsächlicher Standard — gar keine Policy — bedeutet, dass nichts automatisch zurückkehrt. unless-stopped ist die richtige Standardwahl für fast jeden dauerhaft laufenden self-gehosteten Dienst: Er übersteht Abstürze und Reboots, respektiert aber weiterhin ein bewusstes docker compose stop. always sieht identisch aus, bis jemand einen Container absichtlich stoppt und der Docker-Daemon ihn beim eigenen Neustart trotzdem wieder hochfährt — eine echte Überraschung beim ersten Mal. Die vollständige Aufschlüsselung aller vier Policies, inklusive welche zu einem einmaligen Backup-Job passt und welche zu einem Dienst, der niemals down bleiben darf, steht im Restart-Policies-Guide.

Netzwerk: standardmäßig isoliert, bewusst freigegeben

Jedes docker compose up erzeugt sein eigenes Bridge-Netzwerk und setzt jeden Dienst dieser Datei darauf — genau richtig innerhalb eines Stacks, und genau falsch in dem Moment, in dem ein Reverse-Proxy mehrere getrennte Stacks erreichen muss. Das tatsächliche Layout dieses Homelabs: Jeder Stack (Medien, Zugangsdaten, Automatisierung) bekommt sein eigenes privates Netzwerk, das seine Compose-Datei nie verlässt, und Caddy tritt zusätzlich einem gemeinsamen Netzwerk bei, dem auch jeder andere Stack beitritt — nichts in einem Stack erreicht etwas in einem anderen, nur der Proxy überbrückt sie. Der Netzwerk-Guide behandelt die Flags internal: true und external: true, die dieses Layout ermöglichen.

Volumes: die eine Entscheidung, die Daten verlieren kann

Bind-Mounts binden einen bestimmten Host-Ordner direkt in einen Container ein — direkt, mit einem einfachen ls einsehbar, und die richtige Wahl für Konfigurationen und Medien. Named Volumes liegen unter Dockers eigenem Speicherpfad und sind die richtige Wahl für Datenbank-Engine-Daten, weil eine Datenbank konsistente Dateisystem-Semantik erwartet, die ein Bind-Mount nicht immer garantiert. Der Unterschied zählt am meisten beim Teardown: docker compose down -v löscht jedes in dieser Datei deklarierte Named Volume, sofort, ohne Rückfrage — der Beinahe-Unfall, der den Volumes-und-Backups-Guide ausgelöst hat, waren echte dreißig Sekunden, nicht zu wissen, ob ein Jahr an Daten noch existierte.

Secrets: Zugangsdaten aus einer Datei fernhalten, die Sie versehentlich committen könnten

environment: ist der Weg des geringsten Widerstands und der leichteste Weg, ein Credential zu leaken — der Wert steht direkt in der Compose-Datei und erscheint im Klartext unter docker inspect. env_file: verschiebt den Wert in eine separate, gitignorte Datei, was den versehentlichen Commit verhindert, aber nicht verhindert, dass docker inspect ihn weiterhin zeigt, sobald der Container läuft. Der secrets:-Block, eigenständig in Compose v2 und nicht auf Swarm beschränkt, mountet einen Wert stattdessen als schreibgeschützte Datei — echter Mehraufwand für einen einzelnen Host, aber die einzige der drei Optionen, die niemals in einem Environment-Dump auftaucht. Der vollständige Vergleich, inklusive wo jede Option tatsächlich leckt, steht im Guide Secrets vs. .env-Dateien.

Build vs. Pull: sicherstellen, dass ein Rebuild wirklich neu baut

Ein einfaches docker compose up prüft nie, ob sich ein Dockerfile geändert hat — es verwendet stillschweigend das bereits lokal getaggte Image weiter. up --build baut neu, respektiert dabei aber weiterhin Dockers Layer-Cache, sodass nur die Layer ab der ersten geänderten Anweisung tatsächlich neu ausgeführt werden; build --no-cache verwirft den Cache vollständig und ist die einzige Option, die garantiert jede Änderung widerspiegelt — auf Kosten der langsamsten Variante. Der Guide Build vs. Pull enthält die tatsächlichen Rebuild-Zeiten und die Volume-Maskierungsfalle, die einen korrekten Rebuild trotzdem veraltet aussehen lassen kann.

Logs: die Gewohnheit, die aus einem Rätsel eine Zwei-Minuten-Lösung macht

docker compose logs -f --tail=100 <dienst> ist der erste Befehl, den Sie ausführen sollten, sobald irgendetwas verdächtig aussieht — bevor Sie den Container neu starten, bevor Sie die Compose-Datei anfassen, bevor Sie raten. Zuerst neu zu starten ist der mit Abstand häufigste Fehler: Es löscht, was auch immer im stdout-Puffer des Containers stand, und zerstört damit genau den einen Beweis, der den Absturz erklärt hätte. Ein eigener Deep Dive zum Lesen von Compose-Logs wie eine Debugging-Session, nicht wie eine scrollende Textwand, ist als nächster Spoke dieser Serie in Arbeit.

Teardown: stop, down, down -v und kill sind vier verschiedene Befehle

docker compose stop pausiert Container und lässt Netzwerk und Volumes unangetastet — der schnellste Weg zurück mit start. down entfernt zusätzlich die Container und das Standardnetzwerk, lässt Named Volumes aber weiterhin unangetastet. down -v ist der einzige der vier, der Daten löscht. kill überspringt die SIGTERM-Karenzzeit vollständig und sollte nur dann eingesetzt werden, wenn ein Container bereits bekanntermaßen nicht mehr reagiert. Der Guide Down vs. Stop vs. Kill enthält die vollständige Entscheidungstabelle und das SIGTERM-dann-SIGKILL-Timing dahinter.

Eine echte Compose-Datei, mit allen sieben Entscheidungen annotiert

So sieht der tatsächliche Medien-Stack in diesem Homelab aus — Jellyfin hinter Caddy, jede Entscheidung aus der Tabelle oben direkt in der Datei sichtbar statt implizit:

services:
  jellyfin:
    image: jellyfin/jellyfin:10.10
    restart: unless-stopped        # Entscheidung 1 — dauerhafter Dienst, respektiert manuellen Stop
    networks:
      - media-internal             # Entscheidung 2 — privates Netzwerk, nur dieser Stack sieht es
      - proxy-shared                # Entscheidung 2 — die einzige Brücke zum Reverse-Proxy
    volumes:
      - ./jellyfin/config:/config  # Entscheidung 3 — Bind-Mount, direkt einsehbare Konfiguration
      - media-library:/media       # Entscheidung 3 — Named Volume für die eigentlichen Mediendaten
    env_file:
      - .env                        # Entscheidung 4 — Zugangsdaten raus aus der Compose-Datei selbst

  caddy:
    image: caddy:2.9
    restart: unless-stopped
    networks:
      - proxy-shared                 # Entscheidung 2 — tritt dem gemeinsamen Netzwerk jedes Stacks bei, sonst nichts
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile
      - caddy-data:/data

networks:
  media-internal:
    internal: true                  # Entscheidung 2 — kein ausgehender Internetzugang von diesem Netzwerk
  proxy-shared:
    external: true                  # Entscheidung 2 — stackübergreifend geteilt, übersteht jedes einzelne down

volumes:
  media-library:
  caddy-data:

Jede der sieben Entscheidungen ist sichtbar, ohne eine zweite Datei zu öffnen: unless-stopped für einen Dienst, der oben bleiben soll, zwei Netzwerke mit zwei unterschiedlichen Aufgaben, ein Named Volume, reserviert für die Daten, die tatsächlich gesichert werden müssen, und env_file:, das die .env schützt, die die .gitignore dieses Repos bereits ausschließt. Dieses Image zu bauen oder neu zu bauen ist hier ein einfaches docker compose pull — nichts in diesem Stack hat ein lokales Dockerfile, Build vs. Pull ist für ihn also gar keine lebendige Entscheidung, was selbst das korrekte Ergebnis dieses Entscheidungsbaums ist.

Das Fazit

Eine Compose-Datei hat keine „richtige" Restart-Policy, kein „richtiges" Netzwerk-Layout oder einen „richtigen" Teardown-Befehl eingebaut — sie macht nur jede der sieben Entscheidungen sichtbar, an einem Ort, statt verstreut über eine Shell-History, die niemand aufbewahrt hat. Alle sieben beim ersten Mal richtig zu treffen, für jeden neuen Dienst, ist der Unterschied zwischen einem Homelab, das seine eigenen Reboots übersteht, und einem, das nur stabil wirkt, weil es nie getestet wurde. Starten Sie mit dem Homelab-Einsteiger-Guide, falls der Stack noch gar nicht existiert, und arbeiten Sie sich dann durch jeden der sieben Spokes oben, während die Dienste hinzukommen.

Häufige Fragen

Lohnt sich Docker Compose 2026 noch?

Ja — es bleibt der Standardweg, einen Multi-Container-Stack auf einem einzelnen Host zu beschreiben und auszuführen, und die sieben Entscheidungen aus diesem Leitfaden (Restart, Netzwerk, Volumes, Secrets, Build, Logs, Teardown) sind in jedem Werkzeug, das es ersetzt, einschließlich Kubernetes, unvermeidbar.

Was ist der Unterschied zwischen Docker Compose und Kubernetes für ein Homelab?

Compose gleicht den Zustand eines Stacks auf einem Host ab; Kubernetes gleicht ihn über viele Hosts hinweg ab. Ein Homelab, das auf einer einzigen Maschine läuft, gewinnt wenig von Kubernetes' Komplexität und verliert die Einfachheit einer einzigen lesbaren YAML-Datei — Compose bleibt die bessere Wahl, bis ein Dienst wirklich den Ausfall einer physischen Maschine überleben muss.

Brauche ich Docker Swarm, wenn ich bereits Compose nutze?

Für ein Single-Host-Homelab nicht. Swarm fügt Multi-Host-Orchestrierung hinzu, die Compose nicht hat, aber der secrets:-Block und die meisten Compose-v2-Funktionen funktionieren eigenständig, ganz ohne aktivierten Swarm-Modus.

Wie viele Dienste sind zu viele für eine Compose-Datei?

Es gibt keine feste Zahl, aber eine einzelne Datei, die unzusammenhängende Stacks mischt (Medien, Zugangsdaten, Automatisierung), zwingt sie auf dasselbe Standardnetzwerk und denselben Lebenszyklus — die Aufteilung in eine Compose-Datei pro Stack, verbunden nur über ein gemeinsames Proxy-Netzwerk, hält sie isoliert und lässt jeden unabhängig abbauen.

Ist Docker Compose sicher genug für den self-gehosteten Produktiveinsatz?

Das kann es sein, aber Sicherheit entsteht durch die sieben Entscheidungen dieses Leitfadens, bewusst getroffen — Netzwerkisolation, eine echte Secrets-Strategie und eine Restart-Policy, die Fehler nicht verschleiert —, nicht durch Compose selbst. Keine der sieben ist standardmäßig sicher; alle sieben sind es durch bewusste Wahl.