Watchtower mit Docker: Container automatisch aktualisieren (mit Best Practices)
Watchtower prüft im Hintergrund, ob für laufende Docker-Container neue Images vorliegen, und ersetzt sie automatisch. Diese Anleitung zeigt das Setup per docker compose: Zeitplan, Benachrichtigungen, selektives Update per Label und welche Container du besser NICHT blind aktualisierst.

Wer mehrere Docker-Container betreibt, kennt das Problem: Images bekommen laufend Sicherheits- und Funktions-Updates, aber die laufenden Container ziehen diese nicht von selbst. Manuell docker pull und docker compose up -d über ein Dutzend Stacks zu fahren, kostet Zeit und wird gerne vergessen. Watchtower automatisiert genau das: Es überwacht deine laufenden Container, erkennt neue Image-Versionen in der Registry und ersetzt die Container automatisch durch die aktualisierte Variante - mit den exakt gleichen Einstellungen, Volumes und Netzwerken. Diese Anleitung zeigt dir das komplette Setup per docker compose, wie du einen Zeitplan und Benachrichtigungen einrichtest, wie du gezielt nur bestimmte Container aktualisierst und - mindestens genauso wichtig - welche Dienste du besser von der Automatik ausnimmst.
Was ist Watchtower und wann ist es sinnvoll?
Watchtower ist ein kleiner Container (containrrr/watchtower), der über den Docker-Socket mit der Docker-Engine spricht. In einem festen Intervall oder nach Zeitplan vergleicht es das laufende Image jedes Containers mit dem aktuellen Stand in der Registry (Docker Hub, GHCR usw.). Gibt es eine neuere Version desselben Tags, lädt Watchtower das Image, stoppt den alten Container und startet ihn mit identischer Konfiguration aus dem neuen Image neu.
Das ist ideal für einen privaten Homeserver oder ein NAS, auf dem du unkritische, zustandsarme Dienste laufen lässt und nicht jeden Container von Hand pflegen willst. Auf Produktivsystemen solltest du Watchtower dagegen mit Bedacht einsetzen - dazu weiter unten ein eigenes Kapitel. Eine wichtige Grundregel vorab: Watchtower aktualisiert immer denselben Tag. Hast du einen Container auf :latest laufen, holt es die neueste latest. Hast du auf :1.2.3 gepinnt, passiert nichts, weil dieser Tag fix bleibt. Genau dieses Pinnen ist dein wichtigstes Sicherheitsnetz.
Voraussetzungen
- Ein Linux-Host (Debian/Ubuntu empfohlen) mit installiertem Docker. Prüfen mit
docker --versionunddocker compose version(Plugin-Schreibweisedocker compose, nicht das altedocker-compose). - Falls Docker fehlt: Installation über das offizielle Skript
curl -fsSL https://get.docker.com | sudo shund den eigenen Benutzer mitsudo usermod -aG docker $USERin die Gruppedockeraufnehmen. - Zugriff auf den Docker-Socket
/var/run/docker.sock- das ist auf einem Standard-Docker-Host gegeben. - Optional: Ein Telegram-Bot, ein Discord-Webhook oder ein Mail-Konto, wenn du Benachrichtigungen über durchgeführte Updates erhalten möchtest.
- Ein Verzeichnis für den Stack, z. B.
/opt/watchtoweroder./watchtowerin deinem Projektordner.
Schritt 1: Projektordner und Compose-Datei anlegen
Lege auf dem Host einen Ordner für Watchtower an und wechsle hinein:
sudo mkdir -p /opt/watchtower
cd /opt/watchtowerErstelle dort eine Datei docker-compose.yml mit folgendem Inhalt. Diese Variante läuft nach einem festen Zeitplan und räumt alte, nicht mehr genutzte Images auf:
services:
watchtower:
image: containrrr/watchtower:latest
container_name: watchtower
restart: unless-stopped
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- TZ=Europe/Berlin
- WATCHTOWER_SCHEDULE=0 0 4 * * *
- WATCHTOWER_CLEANUP=true
- WATCHTOWER_INCLUDE_RESTARTING=trueDie wichtigsten Stellen erklärt:
- Volume
/var/run/docker.sockist der einzige Mount, den Watchtower braucht. Darüber spricht es mit der Docker-API. Einen Port veröffentlicht der Container nicht. WATCHTOWER_SCHEDULEist ein Cron-Ausdruck mit Sekundenfeld (sechsstellig).0 0 4 * * *bedeutet: jeden Tag um 04:00 Uhr. So laufen Updates in einem ruhigen Wartungsfenster statt mitten am Tag.WATCHTOWER_CLEANUP=truelöscht nach einem erfolgreichen Update das alte Image, damit der Speicher nicht zumüllt.TZ=Europe/Berlinsorgt dafür, dass der Zeitplan in deiner lokalen Zeit interpretiert wird.
Alternativ zum Cron-Zeitplan kannst du auch ein einfaches Intervall in Sekunden setzen, etwa WATCHTOWER_POLL_INTERVAL=86400 für einmal täglich. Verwende entweder Schedule oder Poll-Intervall, nicht beides gleichzeitig.
Schritt 2: Stack starten
Starte Watchtower im Hintergrund:
docker compose up -dDocker lädt das Image und startet den Container. Prüfe, ob er läuft, und sieh dir das Log an:
docker ps
docker logs watchtowerIm Log siehst du beim Start eine Zeile, die das nächste geplante Update-Fenster nennt (Scheduling first run) und wie viele Container überwacht werden. Damit ist die Grundinstallation abgeschlossen - Watchtower kümmert sich ab jetzt selbstständig.
Schritt 3: Ein Update sofort testen
Du musst nicht bis 04:00 Uhr warten, um zu sehen, ob alles funktioniert. Mit einem einmaligen Durchlauf prüft Watchtower sofort alle Container und beendet sich danach wieder:
docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
containrrr/watchtower:latest --run-onceIm Output siehst du pro Container, ob ein neues Image gefunden wurde (Found new image) und welche Container aktualisiert bzw. übersprungen wurden. Das ist die schnellste Methode, das Verhalten zu verifizieren, ohne den Dauer-Container neu zu konfigurieren.
Schritt 4: Benachrichtigungen einrichten (empfohlen)
Gerade wenn Updates nachts unbeaufsichtigt laufen, willst du mitbekommen, was Watchtower geändert hat. Watchtower nutzt dafür die Bibliothek shoutrrr und unterstützt unter anderem Telegram, Discord, Slack und E-Mail. Du gibst das Ziel als URL über die Variable WATCHTOWER_NOTIFICATION_URL an - sobald diese gesetzt ist, aktiviert Watchtower den shoutrrr-Notifier automatisch.
Beispiel Telegram
Erstelle über den BotFather einen Bot, notiere dir das Bot-Token und deine Chat-ID. Ergänze in der docker-compose.yml im environment-Block:
- WATCHTOWER_NOTIFICATION_URL=telegram://BOT_TOKEN@telegram?chats=CHAT_ID
- WATCHTOWER_NOTIFICATION_REPORT=trueBeispiel Discord
Lege im Discord-Server unter Kanal bearbeiten - Integrationen - Webhooks einen Webhook an und übernimm dessen ID und Token:
- WATCHTOWER_NOTIFICATION_URL=discord://WEBHOOK_TOKEN@WEBHOOK_IDNach dem Anpassen den Stack mit docker compose up -d neu erstellen. Beim nächsten Lauf - oder bei einem --run-once-Test - bekommst du eine Nachricht mit der Liste der aktualisierten Container.
Schritt 5: Selektiv aktualisieren - nur ausgewählte Container
Standardmäßig überwacht Watchtower alle laufenden Container. Das ist selten gewollt. Du hast zwei saubere Wege, das einzugrenzen.
Variante A: Opt-in per Label (empfohlen)
Setze Watchtower in den Label-Modus, sodass es nur Container anfasst, die ausdrücklich markiert sind. Ergänze bei Watchtower:
- WATCHTOWER_LABEL_ENABLE=trueVersieh anschließend jeden Container, den du automatisch aktualisieren willst, mit dem passenden Label. Beispiel für einen Dienst, den du updaten lassen möchtest:
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
labels:
- com.centurylinklabs.watchtower.enable=true
volumes:
- ./uptime-kuma-data:/app/dataAlle Container ohne dieses Label bleiben unangetastet. Das ist die sicherste Strategie, weil neue Container nicht versehentlich in die Automatik rutschen.
Variante B: Opt-out - alles ausser bestimmten Containern
Willst du umgekehrt alle Container automatisch aktualisieren, aber einzelne ausnehmen, lässt du WATCHTOWER_LABEL_ENABLE weg und setzt am auszunehmenden Container das Gegenteil:
labels:
- com.centurylinklabs.watchtower.enable=falseDieser Container wird dann dauerhaft übersprungen, der Rest aktualisiert. Welche Variante besser passt, hängt davon ab, ob du im Normalfall lieber zu viel oder zu wenig automatisierst - Variante A (Opt-in) ist für die meisten Setups die ruhigere Wahl.
Best Practice: Was du NICHT blind auto-updaten solltest
Automatische Updates sind bequem, aber sie sind kein Selbstzweck. Einige Container-Typen können durch ein unbeaufsichtigtes Update Schaden nehmen. Halte dich an diese Regeln:
- Datenbanken niemals blind auto-updaten. PostgreSQL, MySQL/MariaDB, MongoDB und Co. führen bei Major-Updates oft Schema- oder Datei-Migrationen durch. Ein automatischer Sprung von z. B. PostgreSQL 15 auf 16 kann die Daten unbrauchbar machen, weil das Datenverzeichnis nicht automatisch migriert wird. Solche Container per
com.centurylinklabs.watchtower.enable=falseausnehmen und manuell - mit gelesenen Release-Notes - aktualisieren. - Kritische Stateful-Dienste mit Vorsicht behandeln. Auch Anwendungen wie Nextcloud, GitLab oder Vaultwarden bringen bei größeren Versionssprüngen eigene Migrationsschritte mit. Lieber gezielt und kontrolliert aktualisieren.
- Tags pinnen statt
:latestjagen. Wenn ein Dienst produktiv wichtig ist, pinne den Tag auf eine Major-Version (z. B.louislam/uptime-kuma:1odertraefik:v3). Watchtower zieht dann nur Patch- und Minor-Updates innerhalb dieses Major-Strangs und nicht überraschend eine Version mit Breaking Changes. - Vorher Backups. Egal wie - vor jedem Update sollten Volumes und Datenverzeichnisse gesichert sein. Auf einer Synology gehören die Bind-Mount-Ordner unter
/volume1/docker/<app>in einen Hyper-Backup-Job; auf einem Linux-Host sicherst du die Verzeichnisse unter/opt/<app>bzw../<app>-data. - Im Zweifel nur benachrichtigen statt aktualisieren. Für Produktivumgebungen ist der reine Benachrichtigungsbetrieb oft sinnvoller: Watchtower meldet dann nur, dass ein Update verfügbar wäre, führt es aber nicht selbst aus. Das erreichst du, indem du den auto-aktualisierten Kreis per Label klein hältst und Updates auf alles andere manuell anstößt.
Hinweis für Synology-Nutzer (Container Manager)
Watchtower lässt sich auch auf einer Synology unter DSM 7.2 betreiben. Lege dazu in der File Station unter docker einen Ordner /volume1/docker/watchtower an, hinterlege dort die docker-compose.yml und erstelle im Container Manager ein neues Projekt, das auf diesen Ordner zeigt. Der Docker-Socket-Mount /var/run/docker.sock:/var/run/docker.sock funktioniert dort genauso. Beachte: Wenn du das DSM-Update-Verhalten der Container Manager nicht stören willst, beschränke Watchtower per Label-Modus auf die Container, die du wirklich automatisch pflegen möchtest.
Updates und Wartung von Watchtower selbst
Watchtower kann sich auch selbst aktualisieren - es behandelt seinen eigenen Container wie jeden anderen. In der Regel musst du also nichts tun. Willst du manuell auf den neuesten Stand gehen, genügt:
cd /opt/watchtower
docker compose pull
docker compose up -dDie docker-compose.yml selbst gehört in deine üblichen Backups, damit du die Konfiguration nach einem Neuaufsetzen schnell wiederherstellen kannst. Eigene persistente Daten legt Watchtower nicht an, der Container ist zustandslos.
Troubleshooting
- Watchtower aktualisiert nichts: Im Log prüfen. Häufigste Ursache ist ein gepinnter Tag (dann ist das korrektes Verhalten) oder aktiver Label-Modus ohne gesetzte Labels an den Ziel-Containern.
- Container wird übersprungen: Prüfe, ob das Label
com.centurylinklabs.watchtower.enableauffalsesteht oder ob bei aktivemWATCHTOWER_LABEL_ENABLE=truedastrue-Label fehlt. - Keine Benachrichtigungen: Die
WATCHTOWER_NOTIFICATION_URLtesten - ein Tippfehler im Token oder in der Chat-/Webhook-ID ist die häufigste Ursache. Ein--run-once-Lauf zeigt schnell, ob die Zustellung klappt. - Permission denied auf den Socket: Auf Hosts mit strenger Rechtevergabe muss der Watchtower-Container Zugriff auf
/var/run/docker.sockhaben. Im Standard-Setup ist das gegeben; bei rootless Docker weicht der Socket-Pfad ab. - Privater Registry-Login nötig: Für Images aus privaten Registries die Datei
~/.docker/config.jsonals/config.jsonin den Watchtower-Container mounten, damit die Anmeldedaten verfügbar sind.
Fazit
Watchtower nimmt dir die lästige Routine ab, Docker-Images aktuell zu halten - mit einem einzigen kleinen Container, einem Socket-Mount und ein paar Umgebungsvariablen. Der Schlüssel zu einem stressfreien Betrieb liegt nicht in der Installation, sondern in der Strategie: Tags pinnen, den Label-Modus zum gezielten Opt-in nutzen, Datenbanken und kritische Stateful-Dienste von der Automatik ausnehmen und vor jedem Update Backups bereithalten. So bekommst du den Komfort automatischer Updates für die unkritische Mehrheit deiner Container, ohne die Kontrolle über die wichtigen Dienste aus der Hand zu geben.
Weitere Anleitungen in den Kategorien Docker und Synology / NAS.
Quellen: Watchtower Dokumentation, containrrr/watchtower auf GitHub, Docker Engine Installation