Überarbeitet am 8. September 2026.

Docker-Container automatisch zu aktualisieren klingt erstmal perfekt: neues Image verfügbar, Container wird neu erstellt, fertig. Genau deshalb habe ich früher Watchtower eingesetzt. Heute würde ich das auf einem produktiven Server deutlich vorsichtiger angehen.

Der wichtigste Grund: Das ursprüngliche Projekt containrrr/watchtower wurde am 17. Dezember 2025 archiviert und wird nicht mehr gepflegt. Meine alte Watchtower-Anleitung ist damit selbst zu einem guten Beispiel dafür geworden, warum Infrastruktur nicht blind jahrelang automatisch weiterlaufen sollte.

Mein heutiger Ansatz ist einfacher: Updates erkennen, kurz prüfen, Backup im Blick haben und dann mit Docker Compose bewusst aktualisieren. Wer mehr Automatisierung möchte, kann sich über neue Images benachrichtigen lassen oder Änderungen über Git verwalten.

Warum ich nicht mehr alles blind automatisch aktualisiere

Ein neues Container-Image ist nicht automatisch ein risikoloses Update. Es können sich Umgebungsvariablen ändern, Datenbankmigrationen nötig werden oder Konfigurationsoptionen verschwinden. Genau das haben wir beispielsweise bei Pi-hole v6 gesehen.

Wenn ein Update nachts automatisch durchläuft und danach Nextcloud, Mailcow oder eine Datenbank nicht mehr sauber startet, ist „immer aktuell“ plötzlich kein Vorteil mehr.

Variante 1: Docker Compose bewusst aktualisieren

Für meinen privaten Server ist das oft schon die beste Lösung. Im Verzeichnis des jeweiligen Compose-Projekts:

docker compose pull
docker compose up -d
docker compose ps

pull lädt die aktuellen Images der in der Compose-Datei verwendeten Tags. up -d erstellt betroffene Container bei Bedarf neu und lässt unveränderte Dienste in Ruhe.

Danach schaue ich kurz in die Logs:

docker compose logs --tail 100

Bei wichtigen Diensten teste ich zusätzlich die Anwendung selbst: Login funktioniert? Datenbank erreichbar? Upload oder Schreibzugriff okay? Erst dann ist das Update für mich wirklich erledigt.

Die Grundlagen zu diesen Befehlen findest du in Docker Compose erklärt und in Docker-Container für Einsteiger.

Nicht überall latest verwenden

Ein großer Teil der Update-Sicherheit beginnt schon in der compose.yaml. Statt überall nur latest einzutragen, kann man bei kritischen Diensten bewusst eine Haupt- oder konkrete Version verwenden.

image: mariadb:11.8

Damit entscheidet nicht irgendein zukünftiger Major-Sprung automatisch, wann die Datenbank auf eine völlig neue Generation wechselt.

Noch reproduzierbarer sind Images, die zusätzlich auf einen Digest festgelegt werden. Das ist vor allem interessant, wenn Compose-Dateien in Git liegen und Updates über Renovate verwaltet werden.

Variante 2: Diun meldet neue Images, aktualisiert aber nichts

Diun steht für Docker Image Update Notifier. Genau der Name beschreibt den Unterschied zu Watchtower ziemlich gut: Diun beobachtet Container-Images und benachrichtigt mich, wenn sich etwas geändert hat. Das eigentliche Update entscheide ich anschließend selbst.

Das gefällt mir für einen produktiven Homeserver deutlich besser als ein Dienst, der mit Zugriff auf den Docker-Socket eigenständig jeden Container ersetzt.

Ein kleines Diun-Compose-Beispiel

services:
  diun:
    image: crazymax/diun:latest
    command: serve
    restart: unless-stopped
    volumes:
      - ./data:/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      TZ: Europe/Berlin
      DIUN_PROVIDERS_DOCKER: "true"
      DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT: "false"
      DIUN_WATCH_SCHEDULE: "0 */6 * * *"

In den Containern, die beobachtet werden sollen, wird anschließend ein Label gesetzt:

labels:
  - "diun.enable=true"

Diun unterstützt verschiedene Benachrichtigungswege. Welche davon sinnvoll sind, hängt vom eigenen Setup ab. Der entscheidende Punkt für mich ist: Benachrichtigen und Aktualisieren sind zwei getrennte Schritte.

Achtung: Auch Diun braucht Zugriff auf Docker

Damit Diun laufende Container erkennen kann, benötigt der Docker-Provider Zugriff auf den Docker-Socket. Dieser Socket ist sicherheitstechnisch mächtig und sollte nicht gedankenlos an beliebige Container durchgereicht werden.

Ich würde deshalb nur vertrauenswürdige Images einsetzen und den Zugriff nicht als harmlose Kleinigkeit betrachten. Wer seine Compose-Dateien ohnehin in Git verwaltet, kann komplett auf diese lokale Docker-Erkennung verzichten und stattdessen Renovate verwenden.

Variante 3: Renovate aktualisiert die Compose-Datei per Pull Request

Renovate kann Docker-Images direkt in Compose-Dateien erkennen. Liegt meine Serverkonfiguration beispielsweise in einem privaten Git-Repository, kann Renovate bei einer neuen Version einen Pull Request erzeugen.

Das hat einen großen Vorteil: Ich sehe die Änderung, kann Release Notes prüfen und entscheide erst danach, ob sie übernommen wird. Das ist kontrollierter als ein nächtlicher Container-Tausch ohne Review.

Renovate unterstützt dabei auch Docker-Digests. Ein Image kann lesbar mit Tag eingetragen und gleichzeitig auf einen konkreten SHA256-Digest festgelegt werden. Renovate aktualisiert diesen Digest anschließend über einen Pull Request.

image: nginx:1.29-alpine@sha256:...

Für einen einzelnen kleinen Server ist das vielleicht mehr GitOps als nötig. Wer seine Docker-Konfigurationen aber ohnehin versioniert, bekommt damit einen sehr nachvollziehbaren Updateprozess.

Was ich nicht mehr empfehlen würde: Ouroboros als Watchtower-Ersatz

In einer früheren Version dieses Artikels hatte ich Ouroboros als Alternative genannt. Das nehme ich wieder heraus. Nur weil ein Werkzeug einmal eine Watchtower-Alternative war, heißt das nicht, dass es Jahre später noch die beste Empfehlung ist.

Genau das ist übrigens auch der Grund, warum ich solche alten Infrastrukturartikel gerade Stück für Stück überarbeite.

Backups vor kritischen Updates

Container selbst sind schnell neu erstellt. Die wichtigen Dinge liegen aber in Datenbanken und Volumes. Vor einem größeren Update von Nextcloud, MariaDB, PostgreSQL oder einem anderen zustandsbehafteten Dienst möchte ich deshalb ein aktuelles Backup haben.

Für meine Serverdaten nutze ich unter anderem Borg. Die aktuelle Einrichtung habe ich hier beschrieben: BorgBackup unter Debian und Ubuntu einrichten.

Nach dem Update alte Images aufräumen

Wenn ein Update erfolgreich läuft und kein schneller Rollback auf das alte Image mehr nötig ist, sammeln sich mit der Zeit ungenutzte Images an.

Vor dem Löschen schaue ich zuerst:

docker image ls

Ungenutzte Images lassen sich später gezielt mit den normalen Docker-Prune-Funktionen bereinigen. Dabei sollte man genauso wenig blind löschen wie bei Volumes.

Mein heutiger Workflow

Für einen kleinen selbst gehosteten Server würde ich es heute ungefähr so halten:

  1. Neue Version erkennen – beispielsweise über Diun oder Renovate.
  2. Release Notes beziehungsweise Breaking Changes prüfen.
  3. Bei wichtigen Diensten Backup kontrollieren.
  4. docker compose pull ausführen.
  5. docker compose up -d ausführen.
  6. Status, Logs und die Anwendung selbst testen.
  7. Alte Images erst später aufräumen.

Das sind ein paar Schritte mehr als „Watchtower macht das nachts automatisch“. Dafür weiß ich am nächsten Morgen aber auch ziemlich genau, warum meine Dienste noch laufen.

Weiterführend: Diun-Dokumentation, Renovate für Docker Compose und die Docker-Compose-Dokumentation.