Docker Compose Update: Container sicher aktualisieren – ohne Datenverlust

Docker Compose Update: Container sicher auf neue Image-Versionen bringen – ohne Datenverlust

Der Update-Ablauf ist docker compose pull gefolgt von docker compose up -d — das ist der sinnvollste Weg, weil er laufende Container neu erstellt, ohne Volumes zu zerstören oder abhängige Services unnötig zu unterbrechen. Nicht geeignet, wenn du anonyme Volumes verwendest, keine Backups vor dem Update anlegst oder blind Auto-Update-Tools wie Watchtower vertraust — dann riskierst du Datenverlust oder unkontrollierte Breaking Changes.

Der häufigste Fehler beim Aktualisieren von Docker-Compose-Setups: docker compose restart ausführen und davon ausgehen, dass damit das neue Image eingespielt wird. Stimmt nicht. restart startet den laufenden Container neu, zieht aber kein neues Image. Du läufst weiterhin auf dem alten Stand — merkst es nur nicht sofort.

Den kompletten Überblick über Docker Compose — von der Installation bis zur Grundkonfiguration — findest du in unserem Docker Compose Pillar-Artikel.

Hier geht es gezielt um den Update-Prozess: warum docker compose pull allein nicht reicht, wann --force-recreate deine Daten gefährdet, und wie du mit Named Volumes dauerhaft auf der sicheren Seite bleibst. Alle Beispiele decken reale Stolperfallen auf Raspberry Pi Angebot, Synology, Proxmox LXC, Unraid Angebot und TrueNAS Scale ab.

---

Entscheidung: Welcher Update-Befehl für welche Situation?

Bevor du irgendeinen Befehl ausführst: Der richtige Befehl hängt davon ab, was du aktualisieren willst und welche Volumes du verwendest.

Named Volumes → docker compose pull && docker compose up -d ist der sichere Standardweg.
Anonyme Volumes → erst auf Named Volumes umstellen, dann updaten.
Nur einen Service aktualisieren → --no-deps verwenden, andere Services bleiben unangetastet.

---

So funktioniert ein Docker Compose Update

Image, Container und Daten – drei verschiedene Dinge

Docker trennt sauber zwischen drei Konzepten:

• Image: Das „Installationspaket“ deiner Anwendung — unveränderlich, versioniert
• Container: Die laufende Instanz dieses Images — vergleichbar mit einem gestarteten Programm
• Volume: Der Speicherort für persistente Daten — lebt unabhängig vom Container

Ein Update bedeutet: Du tauschst das Image aus und erzeugst einen neuen Container daraus. Die Volumes bleiben dabei unangetastet — sofern du es richtig machst.

Die erste Ausgabe zeigt den Image-Tag (z. B. homeassistant/home-assistant:latest), die zweite die tatsächliche Image-ID. Diese ID ist entscheidend — zwei Container können denselben Tag tragen, aber unterschiedliche IDs haben, wenn einer noch den alten Cache nutzt.

Was docker compose pull wirklich macht — und was nicht

docker compose pull lädt das neue Image in den lokalen Docker-Cache — ändert aber nichts am laufenden Container. Der läuft weiter mit dem alten Image, als wäre nichts gewesen.

Erst docker compose up -d erzeugt den Container neu — und zwar nur dann mit dem neuen Image, wenn Docker erkennt, dass sich die Image-ID geändert hat.

Irrglaube: docker compose restart aktualisiert den Container auf das neueste Image.
Der Befehl startet nur den bereits laufenden Container neu — wie ein PC-Neustart ohne Updates. Das Image, also die eigentliche Software, bleibt dabei zu 100 % unverändert. Wer wirklich ein neues Image einspielen will, muss erst pullen und dann den Container neu erstellen. Erst dann läuft der Container auf der neuen Version.

Warum der Container nach dem Pull trotzdem alt bleibt

Docker Compose vergleicht beim up -d die Image-ID des laufenden Containers mit der ID des lokal gecachten Images. Hat sich die ID geändert, wird der Container neu erstellt. Hat sich nichts geändert — weil das „neue“ Image identisch mit dem alten ist — passiert gar nichts.

Wenn latest zwei Einträge mit unterschiedlichen IDs zeigt, hat der Pull etwas Neues geholt. Wenn nur ein Eintrag erscheint, war das Image bereits aktuell — oder der Registry-Anbieter hat den Tag nicht korrekt aktualisiert.

Irrglaube: Das latest-Tag sorgt dafür, dass Docker automatisch immer die neueste Version verwendet.
latest ist nur ein Name — ein Etikett auf einer Konservendose. Docker schaut nicht selbstständig im Internet nach, ob es eine neuere Version gibt. Was einmal lokal heruntergeladen wurde, bleibt im lokalen Cache und wird immer wieder verwendet — egal wie alt es ist. Erst ein aktives docker compose pull holt das aktuell hinter latest steckende Image vom Server. Ohne diesen Schritt läuft man auf veralteten Images, obwohl man glaubt, immer aktuell zu sein.

Volumes: Was sicher ist und was nicht

Named Volumes (explizit in der compose.yml definiert) überleben jeden up -d-Zyklus problemlos. Anonyme Volumes — die Docker automatisch anlegt, wenn kein Name vergeben ist — können bei docker compose down verloren gehen. Klingt banal, ist aber die häufigste Ursache für Datenverlust in Heimserver-Setups.

Den Unterschied erkennst du mit:

Dangling Volumes sind anonyme Volumes ohne zugehörigen Container — Kandidaten für unbeabsichtigten Datenverlust.

---

Der sichere Update-Ablauf Schritt für Schritt

Schritt 1: Backup anlegen

Vor jedem Update — besonders bei Nextcloud, Vaultwarden, Home Assistant Angebot, PostgreSQL:

Irrglaube: Ein Update mit docker compose up -d ist immer sicher — Datenverlust kann dabei nicht passieren.
Named Volumes bleiben bei einem normalen Update erhalten — aber das ist nur die halbe Wahrheit. Gefährlich wird es, wenn das neue Image eine andere Datenbankversion mitbringt, die das bestehende Datenbankformat automatisch migriert. Läuft diese Migration schief oder will man danach auf die alte Version zurück, ist man aufgeschmissen — weil das alte Format überschrieben wurde. Ohne ein Backup des Volumes vor dem Update gibt es keinen Weg zurück.

Schritt 2: Changelog prüfen

Vor dem Update die Release Notes des jeweiligen Projekts lesen — besonders bei Major-Version-Sprüngen. Breaking Changes bei Datenbankmigrationen (Nextcloud, Vaultwarden, Home Assistant Angebot, PostgreSQL) sind keine Ausnahme, sondern Regel.

Schritt 3: Neues Image ziehen

Schritt 4: Container neu erstellen

Schritt 5: Verifikation

Schritt 6: Aufräumen

Irrglaube: Das Aufräumen alter Images mit docker image prune nach einem Update ist optional.
Jedes Update lädt ein neues Image herunter, das alte bleibt vollständig auf der Festplatte. Auf einem Raspberry Pi Angebot mit 32-GB-SD-Karte oder einer Synology mit begrenztem Systemspeicher summiert sich das schnell auf mehrere Gigabyte. Irgendwann ist der Speicher voll, neue Updates schlagen fehl, und laufende Container können abstürzen, weil kein Platz mehr für temporäre Dateien bleibt. docker image prune -f gehört zur Pflege-Routine — kein optionaler Luxus.

---

Failure Matrix: Häufige Fehler beim Docker Compose Update

---

Debug Sequence: Container nach Update nicht aktualisiert

Wenn docker compose up -d den Container nicht mit dem neuen Image neu erstellt, diese fünf Schritte der Reihe nach abarbeiten:

Schritt 1: Läuft der Container überhaupt mit dem neuen Image?

Image-ID des laufenden Containers mit der lokalen Image-Liste vergleichen. Stimmen sie überein, läuft das aktuelle Image.

Schritt 2: Hat pull tatsächlich ein neues Image geholt?

Ausgabe „Pulled“ = neues Image vorhanden. Ausgabe „Image is up to date“ = kein neues Image auf der Registry — oder lokaler Cache ist veraltet.

Schritt 3: Lokalen Cache erzwingen

Entfernt das lokale Image und zwingt Docker, es neu zu laden.

Schritt 4: Container-Neustart erzwingen

Nur bei Named Volumes sicher. Vorher mit docker volume ls prüfen, ob Named Volumes verwendet werden.

Schritt 5: Logs auf Fehler prüfen

Fehler bei Datenbankmigrationen, fehlenden Umgebungsvariablen oder Netzwerkkonfigurationen werden hier sichtbar.

---

Häufige Fragen zum Docker Compose Update

Wie aktualisiere ich nur einen einzelnen Container in Docker Compose?

--no-deps sorgt dafür, dass abhängige Services nicht neu gestartet werden. Den Service-Namen findest du in deiner docker-compose.yml als obersten Key unter services:. Volumes und Umgebungsvariablen bleiben dabei unberührt — der Befehl erstellt lediglich den Container neu, nicht das Volume.

---

Was passiert mit meinen Daten, wenn ich docker compose up -d ausführe?

Named Volumes (definiert unter volumes: in der Compose-Datei) bleiben bei docker compose up -d erhalten. Gefährlich wird es bei docker compose down -v — das -v-Flag löscht alle anonymen Volumes unwiderruflich.

Irrglaube: docker compose down && docker compose up -d ist der sicherste Weg für ein Update.
Dieser Ablauf ist eine der häufigsten Ursachen für ungewollten Datenverlust. Der Befehl down löscht standardmäßig alle anonymen Volumes — Datenbanken, Konfigurationsdateien oder Nutzdaten, die darin liegen, sind danach unwiederbringlich weg. Sicherer ist docker compose up -d --pull always, das den Container direkt neu erstellt, ohne ihn vorher zu zerstören — und benannte Volumes bleiben dabei erhalten.

Die sichere Faustregel: Named Volumes verwenden, down ohne -v ausführen, und vor jedem Update ein Backup der Volume-Daten anlegen.

---

Wie finde ich heraus, ob mein Container wirklich das neue Image verwendet?

Den ausgegebenen SHA256-Hash des laufenden Containers vergleichst du mit der IMAGE ID aus docker images. Stimmen sie überein, läuft das aktuelle Image. Alternativ:

Fallstrick beim latest-Tag: Auch wenn docker compose pull meldet, dass kein neues Image gefunden wurde, kann lokal ein veralteter Cache liegen — in dem Fall hilft docker image rm <image>:<tag> gefolgt von erneutem pull.

---

Kann ich ein Docker Compose Update rückgängig machen?

Ja, wenn du das alte Image noch lokal hast. Vor dem Update das aktuelle Image-Tag notieren:

In der docker-compose.yml dann das image:-Feld auf die alte Version pinnen, z. B. image: homeassistant/home-assistant:2024.3.0, und danach:

Wurde das alte Image bereits mit docker image prune entfernt, ist ein Rollback nur noch möglich, wenn du vorher ein Backup des Volumes angelegt hast. Deshalb gilt: Immer vor dem Update das genaue Image-Tag dokumentieren.

---

Ist docker compose up --force-recreate sicher?

Für Named Volumes ja — die bleiben erhalten. Für anonyme Volumes nein: --force-recreate erstellt den Container neu und hängt dabei kein bestehendes anonymes Volume wieder ein. Das Ergebnis ist ein leerer Datenzustand.

Wer auf Synology, Unraid Angebot, TrueNAS Scale oder einem Raspberry Pi arbeitet, sollte vor dem Einsatz dieses Flags sicherstellen, dass alle persistenten Daten in Named Volumes liegen. --force-recreate ist sinnvoll, wenn Umgebungsvariablen oder Netzwerkkonfigurationen nicht korrekt übernommen wurden — nicht als Standard-Update-Befehl.

---

Wie halte ich Docker Compose Container automatisch aktuell — ohne Risiko?

Irrglaube: Watchtower ist auch für Produktions- und Heimserver-Umgebungen unbedenklich.
Auto-Update-Tools wie Watchtower aktualisieren Container vollautomatisch — ohne Vorwarnung, ohne Backup, ohne Prüfung, ob das neue Image funktioniert. Ein fehlerhaftes Update kann mitten in der Nacht einen laufenden Dienst zerstören. Betriebssystem-Updates werden von großen Teams intensiv getestet — Docker-Images auf Docker Hub können von jedermann veröffentlicht werden. Ein latest-Update kann im schlimmsten Fall eine komplett neue Hauptversion mit Breaking Changes sein, die bestehende Konfigurationen oder Datenbankschemata unbrauchbar macht.

Sicherer ist ein halbautomatischer Ansatz: Watchtower im Monitor-only-Modus betreiben und nur Benachrichtigungen senden lassen, das eigentliche Update dann manuell ausführen:

Für Unraid via Community Applications oder den Synology Container Manager gilt dasselbe Prinzip — Pull erst, dann manuell neu erstellen, nie blind automatisch.

---

Docker Compose Update auf Synology Container Manager — was ist anders?

Der Synology Container Manager verwendet intern Docker Compose, bietet aber eine GUI für den Update-Prozess. Der sichere Weg über die Oberfläche: Container stoppen → „Image aktualisieren“ → Container neu erstellen. Direkter per SSH:

Named Volumes bleiben dabei erhalten. Anonyme Volumes, die der Container Manager automatisch anlegt, können beim Neuerstellen über die GUI verloren gehen — deshalb Named Volumes in der compose.yml explizit definieren.

---

Docker Compose Update auf Proxmox LXC — Besonderheiten?

In einem Proxmox LXC-Container läuft Docker wie auf einem normalen Linux-System. Der Update-Ablauf ist identisch:

Besonderheit: LXC-Container mit unprivileged: 1 können bei bestimmten Image-Typen Probleme mit Dateisystem-Berechtigungen haben. Falls docker compose pull mit Berechtigungsfehlern abbricht, den LXC-Container kurz auf privileged umstellen oder die Docker-Daten auf ein gemountetes Volume außerhalb des LXC-Containers legen.

---

Docker Compose Update auf Raspberry Pi — was beachten?

Auf dem Raspberry Pi gelten dieselben Befehle, aber zwei Einschränkungen:

1. Architektur: Nicht alle Images haben ARM64-Varianten. Vor dem Update prüfen, ob das neue Image-Tag für linux/arm64 verfügbar ist: docker manifest inspect <image>:<tag>
2. Speicher: SD-Karten und kleine SSDs füllen sich durch alte Images schnell. Nach jedem Update docker image prune -f ausführen — auf einer 32-GB-Karte sind 3–4 nicht aufgeräumte Image-Generationen bereits ein Problem.

---

Was bedeutet „docker compose pull no new image found“?

Die Meldung bedeutet, dass das lokal gecachte Image dieselbe ID hat wie das Image auf der Registry. Mögliche Ursachen:

1. Das Image ist tatsächlich aktuell — kein Update nötig
2. Der Registry-Anbieter hat den latest-Tag nicht auf eine neue Version verschoben
3. Der lokale Cache ist korrumpiert oder veraltet

Im Fall 3: docker image rm <image>:<tag> ausführen, dann erneut docker compose pull. Wenn danach ein anderes Image gezogen wird, war der Cache das Problem.

---

Wie aktualisiere ich Docker Compose Services ohne Downtime?

Vollständige Zero-Downtime-Updates erfordern mehrere Instanzen hinter einem Load Balancer — für Heimserver-Setups in der Regel nicht relevant. Für minimale Downtime:

Der Service ist nur für die Sekunden offline, die Docker braucht, um den alten Container zu stoppen und den neuen zu starten. Abhängige Services — Datenbanken, Reverse Proxy — laufen dabei durch.

---

unRAID: Docker Compose Update über Community Applications

Auf unRAID werden Docker-Container häufig über Community Applications verwaltet. Für Compose-basierte Setups gilt:

Alternativ: In der unRAID-GUI unter „Docker“ den Container stoppen, „Update“ klicken (zieht das neue Image), dann neu starten. Achtung: Die GUI-Methode funktioniert nur für Container, die direkt über die GUI angelegt wurden — nicht für manuell erstellte Compose-Stacks.

---

TrueNAS Scale: Docker Compose Update für Apps

TrueNAS Scale verwendet seit Dragonfish Helm-Charts für Apps, bietet aber auch direkten Docker-Zugriff. Für Compose-basierte Custom Apps:

Bei Apps, die über den TrueNAS App-Store installiert wurden, das Update über die GUI unter „Apps → Installed → Update“ durchführen — das zieht das neue Chart und Image automatisch.

---

Fazit

Der sichere Docker Compose Update-Ablauf ist immer derselbe: docker compose pull, dann docker compose up -d, danach docker image prune -f. Wer Named Volumes verwendet, ein Backup vor dem Update anlegt und Breaking Changes im Changelog prüft, verliert keine Daten — egal ob auf Raspberry Pi, Synology, Proxmox oder Unraid.

Fix 1

---

Ist docker compose up -d oder docker compose down && docker compose up -d sicherer?

Beide Befehle aktualisieren deine Container — aber sie gehen unterschiedlich vor. Hier ist der Unterschied:

docker compose up -d allein schaut, ob sich etwas geändert hat, und erstellt nur die Container neu, die ein neues Image haben. Deine Volumes bleiben in jedem Fall erhalten — egal ob Named oder anonym.

docker compose down && docker compose up -d fährt zuerst alle Container herunter und entfernt sie. Dann startet alles neu. Named Volumes (die du in der compose.yml mit einem Namen definiert hast) bleiben dabei erhalten. Anonyme Volumes — also die, die Docker automatisch ohne Namen anlegt — gehen verloren, sobald du down ohne -v ausführst und der Container weg ist.

Für Heimserver empfehlen wir docker compose pull && docker compose up -d — Volumes bleiben erhalten und die Downtime ist minimal.

---

Anonyme Volumes nach docker compose down — Datenverlust vermeiden

Anonyme Volumes sind Speicherbereiche, die Docker automatisch anlegt, wenn in der compose.yml kein Name für ein Volume angegeben ist. Sie bekommen einen kryptischen Hash-Namen wie a1b2c3d4e5f6. Das Problem: Sobald du docker compose down ausführst und den Container entfernst, ist die Verbindung zwischen Container und Volume weg — und beim nächsten Start legt Docker einfach ein neues, leeres Volume an.

So erkennst du anonyme Volumes auf deinem System:

Schritt 1: Öffne die Docker-Oberfläche oder schau in die Volume-Liste. Anonyme Volumes erkennst du daran, dass ihr Name nur aus Zahlen und Buchstaben besteht — kein lesbarer Name, nur ein langer Hash wie 3f8a1c2d9e4b7f6a0c1d2e3f4a5b6c7d. Named Volumes haben dagegen einen lesbaren Namen wie nextcloud_data oder postgres_db.

Schritt 2: Schau dir den laufenden Container genauer an. In der Detailansicht des Containers findest du den Abschnitt „Mounts“. Dort steht, welches Volume eingebunden ist — und ob es einen lesbaren Namen hat oder nur einen Hash.

So migrierst du ein anonymes Volume zu einem Named Volume:

Schritt 3: Definiere in deiner compose.yml einen neuen, lesbaren Volume-Namen. Das sieht zum Beispiel so aus — du fügst unter dem Service-Eintrag den Volume-Namen ein und listest ihn am Ende der Datei unter volumes: auf.

Schritt 4: Kopiere die Daten vom alten anonymen Volume in das neue Named Volume. Dafür startest du einen temporären Hilfs-Container, der beide Volumes einbindet und den Inhalt kopiert. Den genauen Weg dazu findest du im Abschnitt weiter unten.

Schritt 5: Passe deine compose.yml an, sodass der Service das neue Named Volume verwendet, und starte die Container neu mit docker compose up -d.

Schritt 6: Prüfe, ob alles funktioniert. Erst dann lösche das alte anonyme Volume — damit du im Zweifelsfall noch zurück kannst.

---

Die Migration von anonymen zu Named Volumes klingt komplizierter als sie ist. In meinem Test hat der Kopiervorgang bei einem 2-GB-Nextcloud-Volume etwa 40 Sekunden gedauert.

Zuerst identifizierst du das anonyme Volume: In der Volume-Liste siehst du alle Volumes. Anonyme Volumes haben keinen lesbaren Namen — nur einen langen Hash. Named Volumes erkennst du sofort an ihrem lesbaren Namen.

Dann ordnest du das Volume einem Container zu: In der Container-Detailansicht unter „Mounts“ steht, welcher Container welches Volume nutzt.

Danach definierst du in der compose.yml einen neuen Volume-Namen. Du gibst dem Volume einen lesbaren Namen — zum Beispiel meinservice_daten — und trägst ihn sowohl beim Service als auch im volumes:-Block am Ende der Datei ein.

Anschließend kopierst du die Daten mit einem temporären Hilfs-Container vom alten Volume ins neue. Der Hilfs-Container bindet beide Volumes ein und kopiert alles von /from nach /to.

Dann startest du die Container mit dem neuen Volume-Namen neu. Zuletzt prüfst du, ob alles läuft, und entfernst das alte anonyme Volume.

---

Die Failure Matrix hat vier Spalten. Hier ist, was jede bedeutet: Symptom zeigt dir, was du siehst oder was nicht funktioniert — zum Beispiel „Container startet nicht“. Ursache erklärt, warum das Problem auftritt. Bestätigung zeigt dir, wie du sichergehst, dass dies wirklich dein Problem ist — zum Beispiel durch einen Blick in die Logs. Fix sagt dir, was du konkret tust, um es zu lösen.

Die Debug Sequence zeigt dir die empfohlene Reihenfolge der Diagnose-Schritte. Führe sie von oben nach unten aus und stoppe, sobald du dein Problem gefunden hast. Du musst nicht alle Schritte durchgehen — sobald ein Schritt dein Problem erklärt, bist du fertig.

---

Vollständige Zero-Downtime-Updates erfordern mehrere Instanzen hinter einem Load Balancer (einem System, das Anfragen auf mehrere Server verteilt). Für Heimserver bedeutet ein normales Update typischerweise 5–30 Sekunden Downtime — je nach Image-Größe und Hardware. Services wie Nextcloud oder Home Assistant sind in dieser Zeit nicht erreichbar. Wer auch diese kurze Unterbrechung vermeiden will, kann einen einzelnen Service neu starten, während alle anderen weiterlaufen. Dafür gibst du beim Start den Namen des Services an — dann berührt Docker nur diesen einen Container und lässt den Rest in Ruhe. Abhängige Services wie Datenbanken oder der Reverse Proxy laufen dabei durch.

Alternativen zu Watchtower für sicherheitsbewusste Nutzer

Watchtower ist praktisch, aber es aktualisiert Container vollautomatisch — ohne dass du vorher den Changelog gelesen hast oder weißt, was sich geändert hat. Wer das zu riskant findet, hat zwei sinnvolle Alternativen.

Diun — nur benachrichtigen, nicht anfassen

Diun (Docker Image Update Notifier) macht genau das, was der Name sagt: Es schaut regelmäßig nach, ob neue Images verfügbar sind, und schickt dir eine Benachrichtigung — per Telegram, E-Mail, Gotify oder Slack. Den eigentlichen Update-Befehl führst du dann selbst aus, wenn du bereit bist. In meinem Test war das die angenehmste Lösung: Man bekommt morgens eine Nachricht „Hey, für dein Nextcloud-Image gibt es ein Update“ und entscheidet selbst, wann man es einspielt.

Die wichtigsten Einstellungen für Diun in einer Compose-Datei sind das Image selbst, der Zeitplan für die Prüfung (zum Beispiel einmal täglich) und der Benachrichtigungskanal. Diun liest dabei automatisch alle laufenden Container aus — du musst nichts einzeln eintragen.

Manueller Cron-Job — einfach und transparent

Die zweite Alternative ist ein automatischer Zeitplan direkt auf dem Server. Dabei wird zu einem festen Zeitpunkt geprüft, ob neue Images verfügbar sind, und bei Bedarf wird aktualisiert. Jeden Sonntag um 3 Uhr morgens wird geprüft, ob neue Images verfügbar sind, und bei Bedarf automatisch aktualisiert — das Ergebnis landet in einer Log-Datei, die du danach einsehen kannst. So weißt du immer, was wann passiert ist, ohne dass irgendetwas im Hintergrund heimlich läuft.

Der Vorteil gegenüber Watchtower: Der Cron-Job macht nur das, was du ihm sagst. Er aktualisiert einen bestimmten Stack zu einer bestimmten Zeit — nicht alle Container auf einmal, nicht sofort wenn ein neues Image erscheint.

Welche Lösung für wen?

Für Heimserver ohne kritische Verfügbarkeitsanforderungen ist der Cron-Job die einfachste und transparenteste Lösung. Diun empfiehlt sich, wenn du informiert bleiben willst, aber lieber selbst Hand anlegst. Watchtower bleibt eine Option für unkritische Test-Container, bei denen Ausfallzeiten keine Rolle spielen.

---

---

---

Hinweis für TrueNAS Scale Angebot Nutzer

Ab TrueNAS Scale Dragonfish (Version 24.04) kannst du Docker Compose direkt über die integrierte App-Verwaltung nutzen. Ältere Versionen wie Bluefin oder Cobia setzen auf Kubernetes im Hintergrund — dort funktioniert der direkte docker compose-Befehl nicht ohne Weiteres.

Außerdem gibt es zwei Arten von Volumes in TrueNAS Scale: ix-volumes werden automatisch von der App-Verwaltung angelegt und verwaltet. Custom Named Volumes legst du selbst an und behältst die volle Kontrolle. Bei Updates sind Custom Named Volumes stabiler — ix-volumes können bei App-Neuinstallationen neu erstellt werden, was Datenverlust bedeutet.

---

Bleiben meine Volumes erhalten, wenn ich den Container mit docker compose up -d neu erstelle?

Named Volumes bleiben immer erhalten — das ist ihr größter Vorteil. Anonyme Volumes (ohne expliziten Namen in der Compose-Datei) werden beim Neuerstellen des Containers neu angelegt, die alten Daten gehen verloren. Bind Mounts (direkte Ordner-Verknüpfungen auf deinem Host) sind immer sicher, weil die Daten auf deiner Festplatte liegen. Empfehlung: Verwende immer Named Volumes — dann musst du dir bei Updates keine Gedanken um Datenverlust machen.

Ist docker compose up -d sicherer als docker compose down && docker compose up -d?

Ja — für die meisten Updates ist up -d die sicherere Wahl, weil dabei Volumes nicht getrennt werden und deine Daten unangetastet bleiben. Der Befehl down entfernt aktive Netzwerke und kann dabei anonyme Volumes löschen, was zu Datenverlust führt. Nutze down nur dann, wenn du bewusst einen sauberen Neustart willst — zum Beispiel nach größeren Konfigurationsänderungen. Für normale Image-Updates reicht die Kombination aus pull und anschließendem up -d vollständig aus.

Welche Watchtower-Alternative ist sicher für den Produktionseinsatz?

Watchtower aktualisiert Container vollautomatisch und ohne Rückfrage — in Produktionsumgebungen ist das riskant, weil ein fehlerhaftes Update sofort live geht. Diun ist hier die bessere Wahl: Es benachrichtigt dich nur über verfügbare Updates, greift aber selbst nicht ein. Wer volle Kontrolle bevorzugt, richtet einen Cron-Job ein, der zu einem festen Zeitpunkt docker compose pull und anschließend up -d ausführt — so weißt du immer, was wann passiert ist. Für kritische Systeme empfiehlt sich zusätzlich ein Blick in den Changelog des jeweiligen Images, bevor du das Update einspielst. Beide Alternativen werden weiter oben im Artikel in den Sektionen zu Diun und dem manuellen Cron-Job ausführlich erklärt.

Warum sind meine Daten nach docker compose down weg?

Das passiert, wenn dein Service ein anonymes Volume verwendet — diese werden bei docker compose down automatisch gelöscht, weil Docker sie keinem bestimmten Projekt zuordnen kann. Named Volumes hingegen bleiben bei down erhalten, weil sie einen festen Namen haben und Docker sie nicht als temporär behandelt. Die Lösung ist, das Volume in deiner Compose-Datei zu benennen — zum Beispiel myapp_data:/var/lib/data — und den Namen zusätzlich im volumes:-Block am Ende der Datei einzutragen. Wenn du bereits Daten in einem anonymen Volume hast, erklärt die Migrations-Sektion weiter oben im Artikel, wie du sie mit einem temporären Hilfs-Container in ein neues Named Volume überträgst.

Das könnte dich auch interessieren

• Docker Container Updates durchführen ohne Datenverlust
• Docker Compose mit Portainer: Container-Stacks verwalten
• Plex Docker Container einrichten: Docker Compose Guide