- Watchtower, jahrelang der Standard-Helfer für automatische Docker-Updates, wird seit Dezember 2025 nicht mehr weiterentwickelt – Sicherheitslücken bleiben künftig ungeflickt.
- Automatische Updates sparen Zeit, können aber Datenbanken oder Anwendungen mit größeren Versionssprüngen lahmlegen, wenn niemand vorher die Änderungen prüft.
- Werkzeuge wie Diun, What’s Up Docker oder Komodo bieten heute mehr Kontrolle als das reine „alles automatisch aktualisieren“ von früher.
- Die eigentliche Sicherheitsfrage ist nicht „automatisch oder manuell“, sondern ob man weiß, was man aktualisiert – Digest-Pinning und gestufte Update-Strategien helfen dabei.
Wer mehrere Container auf seinem NAS (Network Attached Storage, also einem Speicher, der am Netzwerk hängt) oder Homeserver laufen hat, kennt das Problem: Jede Anwendung läuft in einem eigenen Docker-Container, also einer abgeschotteten kleinen Umgebung mit ihrer eigenen Software-Version. Und jede dieser Versionen kann veraltet und irgendwann unsicher werden. Von Hand jeden Container regelmäßig zu prüfen und neu zu starten, ist mühsam – deshalb greifen viele zu Automatisierung. Genau hier hat sich in den letzten Monaten aber einiges verschoben, das man kennen sollte, bevor man ein Tool einrichtet.
Der Klassiker ist tot: Watchtower archiviert
Über Jahre war Watchtower das Werkzeug, das in praktisch jeder Anleitung zum Thema Docker-Updates auftauchte: Es prüft im Hintergrund, ob es von einem laufenden Container ein neueres Image (das ist die Vorlage, aus der ein Container gestartet wird) gibt, lädt es herunter und startet den Container damit neu. Am 17. Dezember 2025 hat ein Kern-Entwickler das Projekt in einer GitHub-Diskussion mit dem Titel „Goodbye containrrr/watchtower!“ offiziell für archiviert erklärt – begründet damit, dass er selbst keinen Docker-Einsatz mehr habe und keine Zeit zur Pflege finde. Das reguläre letzte Release, Version 1.7.1, stammt sogar schon von November 2023. Das bedeutet: Wer heute noch das Original-Image einsetzt, bekommt keine Sicherheitsupdates mehr – ausgerechnet bei einem Werkzeug, das selbst tief in die eigene Docker-Umgebung eingreifen darf.
Wer am Watchtower-Prinzip festhalten will, kann auf den aktiv gepflegten Fork nicholas-fedor/watchtower wechseln, der die Entwicklung fortführt und unter anderem Fehler beim Zugriff auf GitHubs Container-Registry behoben hat. Die von Watchtower bekannten Labels dürften dort weiterhin funktionieren: Mit com.centurylinklabs.watchtower.enable=true zusammen mit der Einstellung WATCHTOWER_LABEL_ENABLE=true lassen sich nur markierte Container automatisch aktualisieren, mit monitor-only=true meldet das Tool ein Update nur, statt es auszuführen – sinnvoll etwa bei Datenbanken, bei denen ein unbeaufsichtigter Neustart riskant wäre.
Warum „einfach automatisch aktualisieren“ nicht immer die beste Idee ist
Das Grundproblem bei automatischen Updates: Ein Container-Image-Update ist nicht immer nur ein kleiner Fehlerfix. Manche Anwendungen ändern zwischen Versionen ihre Datenbankstruktur oder benötigen manuelle Zwischenschritte. Die Foto-Backup-Software Immich warnt deshalb in ihrer eigenen Dokumentation ausdrücklich davor, vor einem Update nicht die Release Notes zu lesen, und rät bei größeren Änderungen zur Vorsicht mit Werkzeugen wie Watchtower. Ein konkretes Beispiel: Immich hat seine Vektor-Datenbankerweiterung von pgvecto.rs auf VectorChord umgestellt – vor einer solchen Migration sollte man in jedem Fall vorher ein Backup der Datenbank anlegen. Ein Tool, das nachts völlig automatisch und ohne Rückfrage aktualisiert, merkt davon nichts.
Wichtig ist dabei aber auch: Automatische Updates sind nicht grundsätzlich unsicherer als manuelle. Wer monatelang gar nicht aktualisiert, lässt bekannte Sicherheitslücken einfach offen stehen – auch das ist ein Risiko. Die eigentliche Frage ist also nicht „automatisch oder manuell“, sondern ob man Kontrolle über das Was und Wann hat und im Notfall zurückrollen kann.
Die Alternativen im Überblick
Nach dem Ende von Watchtower haben sich mehrere Werkzeuge als Alternativen etabliert, die unterschiedlich viel Kontrolle bieten:
| Werkzeug | Was es tut | Aktualisiert selbst? | Besonderheit |
|---|---|---|---|
| Diun | Prüft auf neue Image-Versionen | Nein, nur Benachrichtigung | Meldet per Discord, Telegram, Gotify, Mail, MQTT, Slack oder Webhook |
| What’s Up Docker (WUD) | Erkennt Updates über Registry-Abfragen | Optional ja | Kann per SemVer-Filter z. B. nur Patch-Updates erlauben und Major-Versionen blockieren; unterstützt viele Registries (Docker Hub, GHCR, ECR, GCR, ACR, Quay u. a.) |
| Komodo | Verwaltet ganze Container-Stacks (Compose) | Ja, selektiv | Deployt bei einem Stack nur die tatsächlich geänderten Container neu, nicht alles |
| Renovate | Erstellt Pull Requests für neue Image-Versionen | Nein, nur Vorschlag | Updates müssen erst per Code-Review freigegeben werden, bevor sie live gehen |
| Portainer | GUI-Verwaltung mit GitOps-Auto-Update | Ja, aus Git-Repository | Webhook-Auslösung außerhalb von Edge-Umgebungen braucht die Business Edition (kostenlos bis 5 Knoten) |
Wer nur wissen will, dass ein Update verfügbar ist, ohne dass etwas automatisch verändert wird, ist mit Diun gut bedient. Wer selektiv automatisieren will – etwa nur kleinere Versionssprünge –, findet in WUD die feinste Steuerung. Und wer mehrere zusammenhängende Container als Stack betreibt, profitiert von Komodos gezieltem Neustart nur der geänderten Dienste.
Und bei NAS-Systemen mit eigener Docker-Oberfläche?
Auch NAS-Hersteller haben eigene Lösungen eingebaut, allerdings unterschiedlich weit ausgebaut. Unraid bietet im Docker-Tab einen „Update All“-Button sowie das Community-Plugin „CA Application Auto Update“ für zeitgesteuerte automatische Updates. Synology zeigt im Container Manager an, wenn ein Update verfügbar ist, und lädt das neue Image per Klick herunter – der Container selbst muss danach aber manuell neu erstellt werden, es gibt keinen erzwungenen automatischen Neustart. QNAP dagegen hat in der Container Station bislang keine eingebaute automatische Update-Prüfung; wer hier automatisieren will, muss auf Drittsoftware wie Watchtower zurückgreifen.
Das eigentliche Sicherheitsrisiko: nicht nur das Update selbst
Ein Grund, warum blindes automatisches Aktualisieren mit Vorsicht zu genießen ist, liegt in der Lieferkette der Images selbst. Ende März 2024 wurde die sogenannte XZ-Backdoor bekannt (CVE-2024-3094, mit dem höchstmöglichen Schweregrad CVSS 10.0): In der weit verbreiteten Kompressions-Bibliothek xz-utils steckte in den Versionen 5.6.0 und 5.6.1 eine Hintertür, die einen Umweg um die SSH-Anmeldung erlaubte. Ein Scan im August 2025 fand noch mindestens 35 Docker-Hub-Images, die diese Backdoor enthielten – teils, weil sie sie unbemerkt von einem Basis-Image geerbt hatten. Ein weiterer Scan im Dezember 2025 fand über 10.000 Docker-Hub-Images mit offen einsehbaren Zugangsdaten wie API-Schlüsseln oder Cloud-Zugangsdaten. Ein Tool, das automatisch das jeweils neueste Image zieht, prüft solche Dinge nicht – es vertraut der Registry.
Hinzu kommt ein verbreitetes Missverständnis: Der Tag „latest“ bedeutet nicht „immer die neueste stabile Version“. Es ist lediglich ein veränderlicher Verweis, der sich auch rückwirkend ändern kann und im schlimmsten Fall auf eine Nightly- oder Beta-Version zeigen kann. Aber selbst ein fest angegebener Versions-Tag wie „1.4.2“ ist theoretisch nicht unveränderlich – nur ein sogenannter Digest, eine kryptografische Prüfsumme (SHA256) des exakten Images, ist wirklich fix. Genau deshalb verlangen Sicherheitsstandards wie das CIS Docker Benchmark oder SLSA Level 3 zunehmend Digest-Pinning statt einfacher Versions-Tags.
Fazit: gestuft statt pauschal automatisieren
Die praktikabelste Strategie orientiert sich am möglichen Schaden im Ernstfall. Unkritische Container ohne eigene Datenhaltung – etwa ein einfacher Web-Proxy – können ruhig automatisch aktualisiert werden. Bei Datenbanken oder Anwendungen mit komplexer Datenstruktur lohnt sich dagegen die „monitor-only“-Einstellung oder ein Werkzeug wie Renovate, das Updates erst als Vorschlag zur Freigabe präsentiert, statt sie sofort live zu schalten. So bleibt die Zeitersparnis der Automatisierung erhalten, ohne dass ein einzelnes verpasstes Sicherheitsupdate durch ein unbeaufsichtigtes Datenbank-Update ersetzt wird.