Am 17. Dezember 2025 archivierten die Maintainer das GitHub-Repository containrrr/watchtower – mit der Begründung, dass sie Docker selbst nicht mehr aktiv einsetzen und die Zeit für die Pflege fehlt. Damit verlieren zahlreiche Homelab- und Produktionsumgebungen ihr gewohntes Werkzeug für automatische Container-Updates. Dieser Artikel zeigt dir drei konzeptionell unterschiedliche Nachfolger, erklärt wann welches Tool sinnvoll ist, und warnt vor den Fallstricken, die beim Umstieg lauern – allen voran das pauschalautomatische Update von Datenbank-Containern.

Voraussetzungen

Docker-Host mit Docker Engine 24 oder neuer und dem docker compose-Plugin
Zugriff auf den Docker-Socket (/var/run/docker.sock) für Diun und WUD
Git-Repository (GitHub, GitLab, Bitbucket oder Azure DevOps) für den Renovate-Einsatz
Mindestens einen Benachrichtigungskanal: Telegram-Bot-Token + Chat-ID, SMTP-Zugangsdaten, Discord-Webhook oder Slack-Token
Backup-Speicher (lokales Verzeichnis oder S3-kompatibel) für Datenbankdumps vor manuellen Updates
Für Renovate SaaS (mend.io): kostenloses Konto für öffentliche Repositories; kostenpflichtige Pläne für private Repositories

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

Bevor du ein neues Tool startest, musst du den alten Watchtower-Container explizit entfernen. Laufen beide Tools gleichzeitig, können sie dieselben Container doppelt oder widersprüchlich aktualisieren:

docker rm -f watchtower

Wenn du kurzfristig weiter automatisch updaten möchtest, ohne sofort zu migrieren, genügt es, im Compose-File nur den Image-Namen zu ändern. Der Community-Fork nicholas-fedor/watchtower ist ein echter Drop-in-Ersatz:

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

Das ist eine Übergangslösung. Mittelfristig solltest du auf Diun, WUD oder Renovate migrieren, da der Fork keine garantierten Sicherheitspatches mehr erhält.

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

Die drei Hauptkandidaten unterscheiden sich fundamental in ihrer Philosophie. Die folgende Tabelle hilft bei der Entscheidung:

Kriterium	Diun v4.33.0	WUD	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)	Über Git-Plattform
Semver-Filterung	Regex per Label	Regex per Label	packageRules in JSON
Opt-in-Standard	watchByDefault: false	WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false	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

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

Diun überwacht Images und benachrichtigt dich – greift aber niemals in laufende Container ein. Das macht es zur sichersten Option. Lege eine docker-compose.yml an:

services:
  diun:
    image: crazymax/diun:latest
    container_name: diun
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./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 Pflicht. Ältere Anleitungen setzen diesen Wert teilweise auf true, was zu Benachrichtigungs-Spam für alle Container führt.

Anschließend aktivierst du das Monitoring einzelner Container per Label und kannst gleichzeitig die überwachten Tags eingrenzen (Minor-Pinning):

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

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

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

WUD ist die komfortabelste Option für Homelabs ohne Git-Repository: ein Web-Dashboard auf Port 3000, Semver-Filterung per Label und optionales Auto-Update per Trigger. Starte WUD mit dieser Compose-Konfiguration:

services:
  wud:
    image: getwud/wud
    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
    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=wud@example.com
      - WUD_TRIGGER_SMTP_MAIL_TO=admin@example.com
      # Optionales Basic-Auth fürs Dashboard
      - WUD_AUTH_BASIC_ADMIN_USER=admin
      - WUD_AUTH_BASIC_ADMIN_HASH=<BCRYPT_HASH>

Container, die WUD überwachen (und optional automatisch updaten) soll, bekommen Labels. Datenbank-Container beobachtest du nur – 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 via SMTP-Trigger aktivieren
      - "wud.trigger.include=smtp.mail"

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

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

Renovate ist die richtige Wahl, wenn dein Stack in einem Git-Repository liegt und du Updates ausschließlich über geprüfte Merges einspielen möchtest. Lege im Repository-Root 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
    }
  ]
}

Hinweis zu prHourlyLimit und prConcurrentLimit: Nach erstmaliger Aktivierung von docker:pinDigests öffnet Renovate für jeden Container einen eigenen PR zum Hinzufügen des SHA256-Digests. In größeren Setups können das dutzende PRs auf einmal sein – die Limits verhindern das.

Für den Self-Hosted-Betrieb via GitHub Actions erstellst du .github/workflows/renovate.yml:

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

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

PostgreSQL, MySQL und MariaDB führen bei Major- und teils auch bei Minor-Updates automatische Schema-Migrationen durch, die nicht rückgängig gemacht werden können. Ein automatisches Image-Update ohne vorherigen Dump kann zu dauerhaftem Datenverlust führen. Das folgende Skript sichert die Datenbank, bevor ein manuelles Update eingespielt wird:

#!/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

Zum Thema automatische Backups empfiehlt sich ein Blick in die Anleitungen MySQL/PostgreSQL-Backup automatisieren mit Cron und Cloud sowie Restic-Backup unter Linux und Windows mit Cron automatisieren.

Schritt 7: Migration von Watchtower zu WUD – Labels umschreiben

Watchtower arbeitete standardmäßig per Opt-out: alle Container wurden überwacht, einzelne konnten mit com.centurylinklabs.watchtower.enable=false ausgeschlossen werden. WUD dreht diese Logik um – 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 einfach ohne Label lassen

Die wichtigste Regel: WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false muss in der WUD-Umgebung explizit gesetzt sein. Andernfalls verhält sich WUD genauso wie Watchtower und überwacht alle Container by default – die Opt-out-Falle vererbt sich.

Troubleshooting / Typische Fehler

Doppeltes Update durch parallelen Betrieb: Watchtower-Container vergessen zu stoppen. Lösung: docker rm -f watchtower vor dem Start des neuen Tools.
WUD überwacht trotzdem alle Container: WUD_WATCHER_LOCAL_WATCHBYDEFAULT fehlt oder steht auf true. Explizit auf false setzen.
Diun meldet alle Container: DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true (oft in älteren Anleitungen). Auf false setzen, dann nur per diun.enable=true-Label opt-in.
WUD-Dashboard nicht erreichbar: Port 3000 ist durch eine andere Anwendung belegt. Im Compose-File auf einen freien Port mappen, z. B. 3001:3000.
Renovate merged keine PRs automatisch: Kein CI vorhanden, Renovate wartet auf Testergebnisse. Pflichteinstellung: "ignoreTests": true in renovate.json.
Renovate erkennt compose.yaml nicht: Standardmäßig matcht Renovate nur docker-compose.yml. Weitere Dateinamen über fileMatch in renovate.json ergänzen.
Renovate PR-Flood nach Digest-Aktivierung: docker:pinDigests öffnet für jeden Container einen PR. Limits setzen: "prHourlyLimit": 2 und "prConcurrentLimit": 5.
Kaputtes Image sofort deployed: Kein minimumReleaseAge gesetzt. Mindestens "minimumReleaseAge": "1 day" in Renovate; WUD/Diun-CRON auf einen verzögerten Zeitraum legen.
latest-Tag ohne Semver-Kontrolle: :latest erlaubt keine Minor/Major-Unterscheidung. Immer auf konkrete Tags pinnen (z. B. nginx:1.26-alpine).

Häufige Fragen

Muss ich sofort von Watchtower wegmigrieren?

Nein, aber mittelfristig ja. Das Original-Repository erhält keine Sicherheitspatches mehr. Kurzfristig bietet sich der Drop-in-Fork nickfedor/watchtower an – nur den Image-Namen im Compose-File ändern. Spätestens innerhalb der nächsten Monate solltest du auf Diun, WUD oder Renovate wechseln, je nach Anforderung.

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

Diun liest nur – kein Eingriff in laufende Container, nur Benachrichtigungen. WUD kann benachrichtigen und automatisch updaten, führt das Update aber direkt auf dem Docker-Host durch. Renovate öffnet Pull Requests im Git-Repository; der eigentliche Update passiert erst beim Merge. Git bleibt „Source of Truth".

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

WUD mit WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false ist der komfortabelste Einstieg: Web-Dashboard unter http://host:3001, Opt-in per Label, Semver-Regex-Filterung und optionales Auto-Update. Diun ist die schlankere Alternative, wenn kein Auto-Update gewünscht ist und du nur Benachrichtigungen möchtest.

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

In Diun: diun.include_tags nur auf Patch-Ebene der aktuellen Major-Version setzen. In WUD: keinen Auto-Update-Trigger zuweisen (wud.trigger.exclude=.*), nur Benachrichtigung. In Renovate: "automerge": false für postgres/mysql/mariadb und "enabled": false für Major-Updates. Vor jedem manuellen Update immer einen Datenbankdump erstellen.

Kann ich Diun und WUD gleichzeitig betreiben?

Technisch ja, da Diun nur liest. Sinnvoll ist das allenfalls in einer Übergangsphase. Dauerhaft entsteht doppelter Benachrichtigungs-Overhead für dieselben Container.

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

In Diun: Label diun.include_tags=^1\.26\.\d+$ beobachtet nur Patches von 1.26.x. In WUD: Label wud.tag.include=^1\.26\.\d+$. In Renovate: "allowedVersions": "1.26.x" in packageRules für das betreffende Image. Das Image-Tag im Compose-File selbst sollte auf 1.26 (nicht latest) stehen.

Was passiert, wenn Renovate keine CI-Pipeline findet?

Renovate wartet auf Testergebnisse, die nie ankommen, und merged PRs nie automatisch. Setze in renovate.json das Feld "ignoreTests": true, wenn kein CI vorhanden ist.

Fazit

Die Archivierung von Watchtower ist kein Grund zur Panik, aber ein klarer Anlass, das Update-Management bewusst zu gestalten. Wer bisher alle Container pauschal automatisch aktualisiert hat, sollte diesen Ansatz nicht einfach in ein neues Tool übertragen. Die drei vorgestellten Nachfolger decken unterschiedliche Reifegrade ab: Diun für alle, die maximale Kontrolle und reine Benachrichtigung wollen; WUD für Homelabs mit selektivem Auto-Update und Web-Überblick; Renovate für GitOps-Setups, in denen jede Änderung über einen geprüften PR läuft. Der gemeinsame Nenner aller drei: Opt-in per Label, Semver-Filterung und ein harter Schutz für Datenbank-Container sind keine Optionen, sondern Pflicht.

Für die Absicherung deines Docker-Hosts insgesamt lohnt sich außerdem ein Blick auf 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 (v4.33.0) · Linuxiac: WUD Konfigurationsanleitung · Renovate Docker-Dokumentation · Matt Dyson: Automatic Docker Container Updates with Renovate · Linux Handbook: Watchtower-Alternativen Übersicht