Docker im Homelab: Container verstehen und sinnvoll einsetzen

Docker hilft dir, mehrere Anwendungen auf einem Homeserver nachvollziehbar zu betreiben. Der Nutzen entsteht aber erst, wenn du Anwendung, Daten und Konfiguration unterscheiden kannst.

Ein Container lässt sich ersetzen. Deine Fotos, Dokumente oder Datenbankinhalte müssen diesen Austausch überleben. Darum beginnen wir mit den Begriffen und dem Betriebsmodell, bevor weitere Dienste dazukommen.

Wenn du noch keine Serverplattform gewählt hast, beginne mit Homelab starten: den ersten Homeserver planen.

Was Docker macht

Docker startet Anwendungen aus vorbereiteten Softwarepaketen, den Images. Ein laufender Container ist eine Instanz eines solchen Images mit eigener Konfiguration und einer beschreibbaren Schicht.

Bei Linux-Containern teilen sich die Container den Kernel ihres Linux-Hosts. Eine virtuelle Maschine hat dagegen ein eigenes Gastbetriebssystem mit eigenem Kernel. Auf einem Desktop kann zwischen Docker und dem eigentlichen Betriebssystem zusätzlich eine Linux-VM liegen. Container sind deshalb nicht einfach «kleine VMs». Die Docker-Einführung zu Containern (externer Link) erklärt diese Abgrenzung.

Für dein Homelab bedeutet das: Mehrere Dienste können sich denselben Linux-Host teilen. Du musst jedoch weiterhin dessen Betriebssystem pflegen und genügend RAM, CPU-Leistung und Speicher bereitstellen.

Die Begriffe, die du wirklich brauchst

Diese Tabelle ist zugleich eine Dokumentationsvorlage. Wenn du für einen Dienst die letzte Spalte beantworten kannst, kennst du die wesentlichen Betriebsabhängigkeiten.

Wann Container sinnvoll sind

Container passen gut zu Diensten, deren Hersteller ein gepflegtes Container-Image und eine dokumentierte Installation anbietet. Das können Webanwendungen, Datenbanken oder Komponenten einer Dokumentenverwaltung sein.

Eine VM bleibt sinnvoll, wenn du ein anderes Gastbetriebssystem, einen eigenen Kernel oder eine vom Hersteller dafür vorgesehene Appliance benötigst. Für unbekannte Software ist eine zusätzliche VM-Grenze häufig eine bewusste Schutzentscheidung.

Installiere im ersten Homelab nicht alles gleichzeitig. Wähle einen Dienst ohne wichtige Nutzdaten, lerne Start, Protokolle und Wiederherstellung kennen und ergänze danach Anwendungen mit Datenbanken.

Daten müssen ausserhalb der austauschbaren Containerschicht liegen

Änderungen in der beschreibbaren Containerschicht bleiben bei einem einfachen Neustart erhalten. Wird der Container entfernt und neu erstellt, ist diese Schicht weg.

Für dauerhafte Daten verwendest du Volumes (externer Link) oder Bind Mounts (externer Link), jeweils am vom Anwendungshersteller vorgesehenen Containerpfad.

Ein Mount kann vorhandene Dateien am Zielpfad verdecken. Das heisst nicht automatisch, dass die Dateien gelöscht wurden. Prüfe bei einer plötzlich leeren Anwendung zuerst die tatsächlichen Mounts.

Bei Bind Mounts kann der Container abhängig von den Rechten auch Hostdateien verändern. Gib ihm nur die Verzeichnisse, die er benötigt, und verwende lesenden Zugriff, wenn Schreiben unnötig ist.

Compose macht den Aufbau nachvollziehbar

Mit Docker Compose (externer Link) beschreibst du Dienste, Netzwerke und Speicher in einer YAML-Datei. Dadurch musst du die Installation nicht aus einzelnen Befehlen oder Screenshots rekonstruieren.

Für eine Anwendung gehören zusammen:

• die Compose-Datei mit den Diensten und ihren Einstellungen
• die bewusst ausgewählte Image-Version
• zusätzliche Konfigurationsdateien
• erforderliche Secrets wie Passwörter und Schlüssel
• persistente Nutzdaten und gegebenenfalls eine Datenbank

Verwende als Ausgangspunkt die Compose-Vorlage des Anwendungsherstellers. Ergänze deine Pfade und Zugriffsregeln erst, wenn ihre Bedeutung klar ist.

Dieser Artikel verwendet aktuelle Compose-Befehle in der Form docker compose. Die folgenden Prüfungen setzen eine bereits eingerichtete Linux-Docker-Engine mit Compose voraus. Führe sie auf dem Docker-Host in Bash aus. Das Konto benötigt Zugriff auf Docker; dieser Zugriff besitzt bei einer üblichen rootful Engine weitreichende Hostrechte.

Mit einem kompakten Prüfblock beginnen

Wechsle in das vorhandene Verzeichnis der zu prüfenden Compose-Anwendung. Im Block steht ein ausdrücklich zu ersetzender Pfad. Die Befehle ändern die Container nicht.

cd '/PFAD/ZUM/BESTEHENDEN/COMPOSE-PROJEKT' || exit 1
docker version
docker compose version
docker compose config --quiet
docker compose ps --all
docker compose logs --tail 100

Erwartet wird:

• docker version zeigt Client und erreichbaren Server.
• docker compose version bestätigt ein verfügbares Compose.
• config --quiet endet bei gültiger Konfiguration ohne Ausgabe.
• ps --all zeigt auch gestoppte Container.
• Die letzten Logzeilen helfen, Startfehler und fehlende Abhängigkeiten zu erkennen.

Logs können vertrauliche Daten enthalten. Prüfe sie vor dem Weitergeben und entferne Passwörter, Tokens und persönliche Inhalte.

Die Referenzen zu config (externer Link), ps (externer Link) und logs (externer Link) erläutern die verwendeten Optionen.

Ein laufender Container beweist noch nicht, dass die Anwendung nutzbar ist. Melde dich zusätzlich an und teste eine typische Funktion.

Container sprechen über das richtige Netzwerk

Compose erstellt standardmässig ein Netzwerk für das Projekt. Dienste darin können sich über ihren Servicenamen erreichen. Eine Anwendung kann ihre Datenbank dadurch zum Beispiel über den Namen db ansprechen, sofern der Datenbankdienst so heisst und beide das passende Netzwerk teilen.

Die Adresse localhost bezeichnet im üblichen getrennten Container-Netzwerk den jeweiligen Container selbst. Sie verweist nicht automatisch auf den Host oder einen anderen Container.

Verwende keine fest kopierten Container-IP-Adressen: Diese können sich beim Ersetzen ändern. Die Compose-Netzwerkdokumentation (externer Link) beschreibt Service-Namen und die Verbindung mehrerer Projekte.

Eine Datenbank, die nur von der Anwendung verwendet wird, braucht normalerweise keine Portfreigabe auf dem Host.

Ein veröffentlichter Port erweitert die Erreichbarkeit

Eine Portzuordnung besteht aus einem Hostport und einem Containerport. Ohne explizite Hostadresse bindet Docker veröffentlichte Ports standardmässig an alle Hostadressen. Damit kann ein Dienst je nach Netzwerk und Firewall auch ausserhalb des Hosts erreichbar werden.

Die Docker-Dokumentation zur Portveröffentlichung (externer Link) zeigt auch die Bindung an die Loopback-Adresse. Das eignet sich, wenn nur lokale Prozesse auf dem Host zugreifen sollen.

Prüfe deshalb bei jeder Anwendung:

1. Muss sie nur aus anderen Containern erreichbar sein?
2. Braucht sie Zugriff aus dem Heimnetz?
3. Soll sie von unterwegs ausschliesslich über VPN erreichbar sein?
4. Ist eine öffentliche Bereitstellung überhaupt erforderlich?

Eine Portzuordnung ist keine Zugriffskontrolle. Auch im Heimnetz braucht eine sensible Anwendung passende Anmeldung und Berechtigungen.

Startreihenfolge und Betriebsbereitschaft trennen

Ein gestarteter Datenbankcontainer kann noch mit der Initialisierung beschäftigt sein. Die abhängige Anwendung darf dann nicht davon ausgehen, dass bereits Anfragen beantwortet werden.

Compose kann mit depends_on die Startreihenfolge beeinflussen. Für tatsächliche Bereitschaft braucht es einen geeigneten Healthcheck und die Bedingung service_healthy. Das ist in der Dokumentation zur Startreihenfolge (externer Link) beschrieben.

Diese Prüfung beim Compose-Start ersetzt keine Wiederverbindungslogik der Anwendung. Fällt eine Datenbank später aus, muss der Dienst damit umgehen können.

Was eine Restart Policy leistet

Für dauerhaft gewünschte Dienste ist unless-stopped häufig eine sinnvolle Wahl: Docker kann den Container nach einem Ausfall oder einem Neustart der Engine wieder starten. Ein bewusst gestoppter Container bleibt auch nach einem Engine-Neustart gestoppt.

always behandelt diesen letzten Fall anders. Welche Regel passt, hängt davon ab, ob ein manueller Stopp dauerhaft gelten soll. Die genauen Unterschiede stehen bei Docker Restart Policies (externer Link).

Ein Healthcheck-Status unhealthy startet einen normalen Docker-Container für sich allein nicht neu. Restart Policies reagieren auf das Ende des Containerprozesses. Eine Neustartschleife sollte deshalb Anlass zur Fehlersuche sein.

Updates kontrolliert durchführen

Ein Container-Neustart lädt kein neues Image. Ein Update bedeutet typischerweise, das gewünschte Image zu beziehen und den Container mit der vorgesehenen Konfiguration neu zu erstellen.

Vorher brauchst du einen geprüften Wiederherstellungsweg:

1. Versionshinweise des Anwendungsherstellers lesen.
2. Unterstützten Upgrade-Pfad und Datenbankversion prüfen.
3. Konfiguration und konsistente Daten sichern.
4. Bisherige Image-Version dokumentieren.
5. Update zuerst bei wenig kritischen Diensten durchführen.
6. Anmeldung, Datenzugriff und abhängige Funktionen testen.

Nach einer Datenbankmigration reicht ein altes Image möglicherweise nicht für die Rückkehr. Dann werden zusätzlich ein passender Datenstand und ein dokumentiertes Restore benötigt. Die PostgreSQL-Dokumentation zu Backup und Restore (externer Link) unterscheidet mehrere Sicherungsverfahren.

Den vollständigen Betriebsplan für Backups, Restore-Tests, Updates und geschützten Fernzugriff findest du in Selfhosting sicher betreiben.

Grenzen der Isolation kennen

Ein Container ist keine pauschale Sicherheitsgarantie. Umfangreiche Rechte, Host-Mounts oder Zugriff auf die Docker-Verwaltung können die Trennung stark schwächen.

Die Docker-Sicherheitsdokumentation (externer Link) erläutert die Bedeutung von Kernel-Isolation, Berechtigungen und der Angriffsfläche des Daemons. Vermeide unmotiviertes privileged und gib Anwendungen nicht beiläufig Zugriff auf den Docker-Socket.

Auch die Mitgliedschaft in der Gruppe docker entspricht bei einer rootful Engine praktisch administrativem Zugriff auf den Host. Docker weist darauf in den Linux-Nachinstallationsschritten (externer Link) ausdrücklich hin.

Für Passwörter können Compose Secrets (externer Link) eine bessere Übergabeform als Umgebungsvariablen sein. Die Anwendung muss das Lesen aus einer Datei unterstützen. Auch die Secret-Datei auf dem Host braucht angemessenen Schutz.

Dein nächster sinnvoller Schritt

Wähle einen einzelnen bestehenden Dienst und beantworte diese Fragen:

• Kenne ich Herkunft und Version des Images?
• Liegen alle wichtigen Daten in dokumentierten Mounts?
• Kann ich den Aufbau aus Konfiguration und Backup wiederherstellen?
• Sind nur die erforderlichen Ports erreichbar?
• Verstehe ich die Abhängigkeiten und die Startregel?
• Habe ich eine Funktion der Anwendung nach einem Neustart geprüft?

Erst danach lohnt es sich, weitere Dienste hinzuzunehmen. Ein kleiner, verstandener Docker-Aufbau ist eine tragfähige Grundlage für dein Homelab.

Quellen und Prüfstand

Stand: 10. September 2026. Die technischen Aussagen stützen sich auf die im jeweiligen Abschnitt verlinkten offiziellen Docker- und PostgreSQL-Dokumentationen. Befehle sind Diagnosebeispiele für eine bestehende Installation; eine vollständige Installation muss zur gewählten Linux-Distribution und Anwendung passen.