Am 17. Dezember 2025 archivierten die Maintainer das GitHub-Repository containrrr/watchtower, weil sie Docker selbst nicht mehr aktiv einsetzen. Diese Anleitung stellt drei konzeptionell unterschiedliche Nachfolger vor, zeigt, wann welches Tool passt, und nennt die Fallstricke beim Umstieg, allen voran das pauschale automatische Update von Datenbank-Containern.

Voraussetzungen

Docker Engine 24 oder neuer mit docker compose-Plugin, x86_64 oder ARM64
Ressourcen: Diun und WUD sind schlank; 1 bis 2 CPU-Kerne und 1 GB freier RAM neben den überwachten Diensten reichen
Zugriff auf den Docker-Socket (/var/run/docker.sock)
Git-Repository (GitHub, GitLab, Bitbucket oder Azure DevOps) für Renovate
Ein Benachrichtigungskanal: Telegram-Bot-Token + Chat-ID, SMTP, Discord-Webhook oder Slack-Token
Backup-Speicher (lokal oder S3-kompatibel) für Datenbankdumps vor manuellen Updates
Renovate als gehosteter Dienst (Mend Renovate Community Cloud) ist kostenlos für öffentliche und private Repositories auf GitHub, Bitbucket Cloud und Azure DevOps; alternativ selbst betrieben per GitHub Actions (Schritt 5).

Schritt 1: Watchtower abschalten und optionalen Drop-in-Fork einrichten

Entfernen Sie zuerst den alten Watchtower-Container, sonst aktualisieren zwei Tools dieselben Container doppelt oder widersprüchlich:

docker rm -f watchtower

Für eine Übergangszeit genügt es, in der Compose-Datei nur den Image-Namen zu ändern: Der Community-Fork (GitHub-Projekt nicholas-fedor/watchtower, Image nickfedor/watchtower) ist ein Drop-in-Ersatz:

services:
  watchtower:
    image: nickfedor/watchtower   # statt containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Der Fork wird aktiv gepflegt (Stand 29.09.2026: Version 1.22.3), ist aber ein Community-Projekt ohne Zusagen zu Sicherheitsupdates. Er übernimmt das Opt-out-Verhalten: Ohne weitere Einstellungen aktualisiert er alle Container, auch Datenbanken. Mittelfristig lohnt der Umstieg auf Diun, WUD oder Renovate mit Opt-in.

Verifizieren: docker ps --filter name=watchtower zeigt nur noch den neuen Container mit dem Image nickfedor/watchtower oder, wenn Sie direkt migrieren, keinen Watchtower-Container mehr.

Schritt 2: Entscheidung – welches Tool passt zu Ihrer Umgebung?

Die drei Kandidaten unterscheiden sich grundlegend:

Kriterium	Diun 4.33	WUD 9.2	Renovate
Eingriff in Container	Niemals (nur lesen)	Optional (per Trigger)	Niemals direkt (nur PRs)
Git-Repository nötig	Nein	Nein	Ja (Pflicht)
Web-Dashboard	Nein	Ja (Port 3000, Anmeldung Pflicht)	Über Git-Plattform
Semver-Filterung	Regex per Label (mit `diun.watch_repo`)	Regex per Label	packageRules in JSON
Opt-in-Standard	Standard (`watchByDefault: false`)	`WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false` setzen	Konfiguration in renovate.json
Benachrichtigungskanäle	15+ (Telegram, Slack, Ntfy …)	SMTP, Slack, Webhook …	GitHub/GitLab-PR-Kommentare
Ideal für	Manuelle Kontrolle, Homelab	Homelab mit selektivem Auto-Update	GitOps, CI/CD-Umgebungen

Verifizieren: Sie haben sich für ein Tool entschieden und wissen, ob Ihre Compose-Dateien in einem Git-Repository liegen. Nur dann kommt Renovate in Frage.

Schritt 3: Diun einrichten (Benachrichtigung ohne Auto-Update)

Diun überwacht Images und benachrichtigt, greift aber nie in laufende Container ein: die sicherste Option. Legen Sie in einem eigenen Projektordner eine compose.yaml an:

services:
  diun:
    image: crazymax/diun:4.33.0
    container_name: diun
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./diun-data:/data
    environment:
      - TZ=Europe/Berlin
      - LOG_LEVEL=info
      - DIUN_WATCH_WORKERS=10
      - DIUN_WATCH_SCHEDULE=0 */6 * * *
      - DIUN_WATCH_JITTER=30s
      - DIUN_PROVIDERS_DOCKER=true
      - DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=false
      - DIUN_NOTIF_TELEGRAM_TOKEN=<BOT_TOKEN>
      - DIUN_NOTIF_TELEGRAM_CHATIDS=<CHAT_ID>

Wichtig: DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=false ist bereits Standard. Setzen Sie es trotzdem ausdrücklich, damit niemand es später auf true stellt (Benachrichtigungen für alle Container).

Die Überwachung aktivieren Sie je Container per Label. Ohne weitere Labels meldet Diun nur einen neuen Digest hinter dem verwendeten Tag; neue Versionsnummern erst mit diun.watch_repo=true. diun.include_tags grenzt die Tags ein (Minor-Pinning):

services:
  nginx:
    image: nginx:1.26-alpine
    labels:
      - "diun.enable=true"
      - "diun.watch_repo=true"
      - "diun.max_tags=10"
      # Nur 1.26.x Patches beobachten (Minor-Pinning):
      - "diun.include_tags=^1\\.26\\.\\d+-alpine$"

  postgres:
    image: postgres:16
    labels:
      - "diun.enable=true"
      - "diun.watch_repo=true"
      - "diun.max_tags=10"
      # Nur Patch-Updates innerhalb Major 16:
      - "diun.include_tags=^16\\.\\d+$"
      - "diun.exclude_tags=^(latest|master|main)$"

Werte für <BOT_TOKEN> und <CHAT_ID> Ihres Telegram-Bots eintragen, dann docker compose up -d.

Verifizieren: docker compose logs diun zeigt nach dem Start „Found N image(s) to analyze“, wobei N der Zahl Ihrer Container mit diun.enable=true entspricht, und „Next run in …“. Im Test lief Diun 4.33.0 mit diesen Einstellungen ohne Fehler und berücksichtigte nur den markierten Container.

Schritt 4: WUD einrichten (Benachrichtigung plus optionales Auto-Update)

WUD ist die komfortabelste Option für Homelabs ohne Git-Repository: Web-Dashboard auf Port 3000, Semver-Filterung per Label, optionales Auto-Update per Trigger. Seit Version 9 ist ein Administratorkonto Pflicht, sonst beendet sich der Container direkt nach dem Start: Die ausführliche Schritt-für-Schritt-Einrichtung mit Compose-Trigger, Benachrichtigung und Umstieg von Watchtower zeigt WUD statt Watchtower: Docker-Container automatisch aktualisieren.

services:
  wud:
    image: getwud/wud:9.3.0
    container_name: wud
    restart: unless-stopped
    ports:
      - 3001:3000   # Port 3000 ist oft belegt – auf 3001 mappen
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./wud-store:/store
    environment:
      # WICHTIG: Opt-in statt Opt-out (wie Watchtower)
      - WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false
      - WUD_WATCHER_LOCAL_CRON=0 4 * * *
      # E-Mail-Benachrichtigung
      - WUD_TRIGGER_SMTP_MAIL_HOST=smtp.example.com
      - WUD_TRIGGER_SMTP_MAIL_PORT=587
      - WUD_TRIGGER_SMTP_MAIL_USER=user@example.com
      - WUD_TRIGGER_SMTP_MAIL_PASS=<PASSWORD>
      - WUD_TRIGGER_SMTP_MAIL_FROM_ADDRESS=wud@example.com
      - WUD_TRIGGER_SMTP_MAIL_TO=admin@example.com
      # Pflicht seit WUD 9: Administratorkonto fürs Dashboard
      - WUD_AUTH_ADMIN_USER=admin
      - WUD_AUTH_ADMIN_PASSWORD=<PASSWORT>
      # Update-Trigger: tauscht Container gegen die neue Version
      - WUD_TRIGGER_DOCKER_UPDATE_PRUNE=true

Das Passwort legt WUD beim ersten Start gehasht unter ./wud-store ab; dieses Verzeichnis gehört ins Backup. Die älteren Variablen WUD_AUTH_BASIC_… gelten als veraltet.

Zu überwachende Container bekommen Labels. Datenbank-Container werden nur beobachtet, ohne Auto-Update-Trigger:

services:
  nginx:
    image: nginx:stable-alpine
    labels:
      # Diesen Container überwachen
      - "wud.watch=true"
      # Nur exakte SemVer-Tags (kein 'latest')
      - "wud.tag.include=^\\d+\\.\\d+\\.\\d+-alpine$"
      # Auto-Update über den Docker-Trigger aktivieren
      - "wud.trigger.include=docker.update,smtp.mail"

  postgres:
    image: postgres:16
    labels:
      # Nur beobachten, NIEMALS auto-updaten
      - "wud.watch=true"
      - "wud.tag.include=^16\\.\\d+$"
      # Kein Update-Trigger, nur Mail-Benachrichtigung
      - "wud.trigger.exclude=docker.update"

Wichtig: Jeder Trigger gilt für alle überwachten Container. Der Docker-Trigger aktualisiert also auch die Datenbank, wenn sie ihn nicht per wud.trigger.exclude=docker.update ausschließt. Ein SMTP-Trigger verschickt nur E-Mails.

Verifizieren: docker compose ps zeigt WUD als „healthy“, http://<host>:3001 fragt nach Benutzer und Passwort, und im Dashboard erscheinen nur die Container mit wud.watch=true. Im Test mit WUD 9.2.0 (29.09.2026) aktualisierte der Docker-Trigger einen markierten Container von 1.26.2 auf die neueste passende Version, der Container mit wud.trigger.exclude=docker.update wurde nur als „Update verfügbar“ gemeldet und blieb unverändert. Ein anschließender Start mit WUD 9.3.0 und Administratorkonto lief ebenfalls an (Health-Endpunkt 200, API ohne Login 401).

Schritt 5: Renovate einrichten (GitOps, Pull-Request-basiert)

Renovate passt, wenn Ihr Stack in einem Git-Repository liegt und Updates nur über geprüfte Merges laufen sollen. Legen Sie im Stammverzeichnis des Repositorys eine renovate.json an:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "docker:pinDigests"
  ],
  "timezone": "Europe/Berlin",
  "ignoreTests": true,
  "prHourlyLimit": 2,
  "prConcurrentLimit": 5,
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchUpdateTypes": ["minor", "patch", "digest"],
      "minimumReleaseAge": "1 day",
      "automerge": true,
      "automergeType": "branch",
      "automergeSchedule": ["* 0-3 * * *"]
    },
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["postgres", "mysql", "mariadb", "mongo"],
      "automerge": false,
      "allowedVersions": "/^\\d+\\.\\d+/"
    },
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["postgres", "mysql", "mariadb"],
      "matchUpdateTypes": ["major"],
      "enabled": false
    }
  ]
}

prHourlyLimit und prConcurrentLimit: Nach Aktivierung von docker:pinDigests öffnet Renovate je Container einen PR für den SHA256-Digest, in größeren Setups dutzende auf einmal. Die Limits verhindern das.

Für selbst betriebenes Renovate per GitHub Actions legen Sie .github/workflows/renovate.yml an:

name: Renovate
on:
  workflow_dispatch:
  schedule:
    - cron: '0 15 * * *'
jobs:
  renovate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7.0.1
      - uses: renovatebot/github-action@v46.3.6
        with:
          token: ${{ secrets.RENOVATE_TOKEN }}
        env:
          RENOVATE_GIT_AUTHOR: 'Renovate Bot <renovate@example.com>'
          RENOVATE_REPOSITORIES: 'org/repo'

Die Actions-Versionen entsprechen dem Stand vom 29.09.2026; Renovate hält sie danach aktuell.

Verifizieren: Nach einem manuellen Start des Workflows (Actions → Renovate → Run workflow) öffnet Renovate im Repository ein Issue „Dependency Dashboard“ und beim ersten Lauf einen Pull Request „Configure Renovate“ oder, wenn renovate.json schon vorhanden ist, die ersten Update-PRs.

Schritt 6: Datenbank-Container schützen und Backup-Pattern einrichten

PostgreSQL, MySQL und MariaDB führen bei Major- und teils Minor-Updates Schema-Migrationen durch, die sich nicht rückgängig machen lassen. Ein automatisches Image-Update ohne vorherigen Dump kann zu dauerhaftem Datenverlust führen. Das Skript sichert die Datenbank vor einem manuellen Update:

#!/bin/bash
# Datei: /usr/local/bin/backup-and-update.sh
CONTAINER=${1:-postgres}
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR=/opt/backups

mkdir -p "$BACKUP_DIR"
# Datenbank-Dump erstellen
docker exec "$CONTAINER" pg_dumpall -U postgres > "$BACKUP_DIR/db_${DATE}.sql"
if [ $? -eq 0 ]; then
  echo "Backup OK: $BACKUP_DIR/db_${DATE}.sql"
  docker compose pull "$CONTAINER"
  docker compose up -d "$CONTAINER"
else
  echo "FEHLER: Backup fehlgeschlagen, Update abgebrochen!"
  exit 1
fi

Skript mit chmod +x /usr/local/bin/backup-and-update.sh ausführbar machen und im Projektordner des Stacks aufrufen, z. B. backup-and-update.sh postgres.

Verifizieren: Das Skript meldet „Backup OK“ mit dem Pfad der Sicherung, ls -lh /opt/backups zeigt eine Datei größer als 0 Byte, und docker compose ps zeigt den Datenbank-Container danach wieder als laufend.

Automatische Backups: MySQL/PostgreSQL-Backup automatisieren mit Cron und Cloud und Restic-Backup unter Linux und Windows mit Cron automatisieren.

Schritt 7: Migration von Watchtower zu WUD – Labels umschreiben

Watchtower arbeitete per Opt-out: alle Container überwacht, Ausschluss mit com.centurylinklabs.watchtower.enable=false. WUD arbeitet mit Opt-in. Die Migration der Labels:

# VORHER (Watchtower Opt-out):
labels:
  - "com.centurylinklabs.watchtower.enable=false"   # Ausschließen
  - "com.centurylinklabs.watchtower.scope=web-tier" # Scope-Gruppen

# NACHHER (WUD Opt-in) – Logik umkehren:
labels:
  - "wud.watch=true"   # NUR markierte Container werden überwacht
# Container OHNE Label werden bei WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false ignoriert
# DB-Container: wud.watch=true plus wud.trigger.exclude=docker.update (nur melden)

Wichtigste Regel: WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false ausdrücklich setzen, denn der Standard ist true. Sonst überwacht WUD wie Watchtower alle Container.

Verifizieren: Im WUD-Dashboard erscheinen nur Container mit wud.watch=true. In den Logs meldet docker compose logs wud nach dem Start „Cron finished (N containers watched …)“, wobei N der Zahl Ihrer markierten Container entspricht.

Troubleshooting / Typische Fehler

Doppeltes Update durch parallelen Betrieb: Watchtower läuft noch. docker rm -f watchtower vor dem Start des neuen Tools.
WUD überwacht trotzdem alle Container: WUD_WATCHER_LOCAL_WATCHBYDEFAULT fehlt oder ist true; auf false setzen.
Diun meldet alle Container: DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true (oft in älteren Anleitungen). Auf false setzen, Opt-in per diun.enable=true.
WUD-Container beendet sich sofort: Seit WUD 9 Pflicht: WUD_AUTH_ADMIN_USER und WUD_AUTH_ADMIN_PASSWORD setzen.
WUD-Dashboard nicht erreichbar: Port 3000 belegt. Auf einen freien Port mappen, z. B. 3001:3000.
Renovate merged keine PRs automatisch: Ohne CI wartet Renovate auf Testergebnisse. "ignoreTests": true in renovate.json setzen.
Renovate erkennt eine Compose-Datei nicht: Erkannt werden compose.yaml, docker-compose.yml und ähnliche Namen. Andere Dateinamen über managerFilePatterns (früher fileMatch) ergänzen.
Renovate PR-Flood nach Digest-Aktivierung: Limits setzen: "prHourlyLimit": 2 und "prConcurrentLimit": 5.
Kaputtes Image sofort deployed: Kein minimumReleaseAge. Mindestens "minimumReleaseAge": "1 day" in Renovate; WUD/Diun-CRON verzögert legen.
latest-Tag ohne Semver-Kontrolle: :latest erlaubt keine Minor/Major-Unterscheidung. Auf konkrete Tags pinnen (z. B. nginx:1.26-alpine).

Häufige Fragen

Muss ich sofort von Watchtower wegmigrieren?

Ja. Das Original erhält keine Updates mehr und startete im Test vom 04.10.2026 auf Docker Engine 29.8 gar nicht: Watchtower 1.7.1 spricht die Docker-API 1.25 an, die Engine verlangt mindestens 1.40. Übergangsweise hilft der Drop-in-Fork nickfedor/watchtower (Schritt 1), für kontrollierte Updates Diun, WUD oder Renovate.

Was ist der größte konzeptionelle Unterschied zwischen den drei Tools?

Diun liest nur und benachrichtigt. WUD kann zusätzlich direkt auf dem Docker-Host aktualisieren. Renovate öffnet Pull Requests, das Update passiert erst beim Merge; Git bleibt die maßgebliche Quelle („Source of Truth“).

Welches Tool eignet sich für ein einfaches Homelab ohne Git-Repository?

WUD mit WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false: Web-Dashboard unter http://host:3001, Opt-in per Label, Semver-Regex-Filterung, optionales Auto-Update. Diun ist die schlankere Alternative, wenn nur Benachrichtigungen gewünscht sind.

Wie schütze ich Datenbank-Container in allen drei Tools?

Diun: diun.include_tags nur auf Patch-Ebene der aktuellen Major-Version. WUD: Update-Trigger ausschließen (wud.trigger.exclude=docker.update). Renovate: "automerge": false für postgres/mysql/mariadb und "enabled": false für Major-Updates. Vor jedem manuellen Update einen Dump erstellen (Schritt 6).

Kann ich Diun und WUD gleichzeitig betreiben?

Technisch ja, da Diun nur liest; sinnvoll höchstens übergangsweise, sonst doppelte Benachrichtigungen.

Wie pinne ich auf Minor-Tags und erhalte nur Patch-Updates?

Diun: diun.watch_repo=true und diun.include_tags=^1\.26\.\d+$. WUD: wud.tag.include=^1\.26\.\d+$. Renovate: "allowedVersions": "1.26.x" in packageRules. Das Image-Tag im Compose-File steht auf 1.26, nicht latest.

Was passiert, wenn Renovate keine CI-Pipeline findet?

Sie wartet auf nie eintreffende Testergebnisse und merged nie automatisch; Lösung "ignoreTests": true (siehe Troubleshooting).

Fazit

Übertragen Sie pauschale Auto-Updates nicht einfach in ein neues Tool. Diun passt für reine Benachrichtigung, WUD für Homelabs mit selektivem Auto-Update und Web-Überblick, Renovate für GitOps-Setups mit geprüften PRs. Bei allen drei gilt: Opt-in per Label, Semver-Filterung und harter Schutz für Datenbank-Container sind Pflicht.

Zur Absicherung des Docker-Hosts: Traefik als Docker Reverse Proxy mit HTTPS einrichten und Docker-Netzwerke und Volumes verstehen.

Weiterführende Anleitungen und Quellen

Quellen: Watchtower-Archivierungs-Diskussion auf GitHub · Diun offizielle Dokumentation (crazymax.dev) · Diun GitHub Repository · Watchtower-Fork von Nicholas Fedor · WUD offizielle Dokumentation · Renovate Docker-Dokumentation · Matt Dyson: Automatic Docker Container Updates with Renovate · Linux Handbook: Watchtower-Alternativen Übersicht