Watchtower ist tot: Container-Updates 2026 richtig machen mit Diun (Notify statt blindem Auto-Pull)

Am 17. Dezember 2025 wurde das Watchtower-Repository archiviert – keine neuen Releases, keine Security-Patches mehr. Genau die Zielgruppe, die Watchtower jahrelang für automatische Container-Updates eingesetzt hat – Self-Hoster mit Compose-Stacks auf einem VPS –, braucht jetzt einen gepflegten Nachfolger. Die naheliegende, aktiv gewartete Alternative ist Diun (Docker Image Update Notifier). Der entscheidende Unterschied im Konzept: Diun pullt nicht automatisch, sondern benachrichtigt Sie, wenn ein neues Image vorliegt. Dieser Beitrag baut ein minimales, lauffähiges Beispiel auf und erklärt, warum „Notify“ die bewusstere und sicherere Entscheidung ist.

Was Diun macht – und warum nicht Auto-Pull

Diun hängt sich an das Docker-Socket, liest die laufenden Container aus und prüft in einem Zeitplan bei der jeweiligen Registry, ob zu einem Image-Tag ein neuerer Digest existiert. Findet es eine Änderung, schickt es eine Benachrichtigung – über Telegram, E-Mail und rund zwanzig weitere Kanäle. Mehr nicht. Es zieht kein Image, es startet keinen Container neu.

Das klingt nach weniger Komfort als Watchtowers „einmal einrichten, nie wieder anfassen“. Genau darin liegt aber der Punkt. Ein blinder Auto-Pull auf latest bedeutet: Der Container läuft nach dem nächsten Neustart auf einer Version, die Sie nie getestet haben. Bei einer zustandslosen Web-App ist das meist unkritisch. Bei einer Postgres-Datenbank ist es ein Risiko: Ein Sprung von postgres:16 auf postgres:17 erfordert eine Migration des Datenverzeichnisses – ein automatischer Pull, der stillschweigend das Major-Image tauscht, kann die Datenbank beim Neustart nicht mehr öffnen. Solche Änderungen wollen Sie kontrolliert, mit Backup und Wartungsfenster durchführen. Diun stellt genau diese Entscheidung wieder in Ihre Hand: Sie erfahren dass ein Update da ist, entscheiden aber selbst ob und wann.

Das minimale Setup

Eine einzige compose.yaml genügt. Der Container startet mit dem Argument serve, bekommt das Docker-Socket read-only gemountet und persistiert seinen Zustand unter /data:

services:
  diun:
    image: crazymax/diun:4.33.0
    container_name: diun
    command: serve
    volumes:
      - "./data:/data"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    environment:
      - "TZ=Europe/Berlin"
      - "LOG_LEVEL=info"
      - "DIUN_WATCH_SCHEDULE=0 */6 * * *"
      - "DIUN_WATCH_JITTER=30s"
      - "DIUN_PROVIDERS_DOCKER=true"
      - "DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true"
      # Benachrichtigung per Telegram:
      - "DIUN_NOTIF_TELEGRAM_TOKEN=<YOUR_BOT_TOKEN>"
      - "DIUN_NOTIF_TELEGRAM_CHATIDS=<YOUR_CHAT_ID>"
    restart: unless-stopped

Starten und die Logs beobachten:

docker compose up -d
docker compose logs -f diun

Beim ersten Lauf erfasst Diun alle laufenden Container und legt für jedes Image einen Ausgangs-Digest in ./data ab. Ab dann prüft es nach dem DIUN_WATCH_SCHEDULE und meldet nur noch echte Änderungen.

Die vier Bausteine

Docker-Provider. DIUN_PROVIDERS_DOCKER=true aktiviert die Docker-Integration; dafür braucht Diun das Socket-Mount. DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true überwacht automatisch alle laufenden Container, ohne dass Sie an jedem Container ein Label setzen müssen. Wollen Sie stattdessen selektiv arbeiten, lassen Sie diesen Schalter weg und markieren einzelne Container mit dem Label diun.enable=true.

Zeitplan. DIUN_WATCH_SCHEDULE ist ein normaler Cron-Ausdruck; 0 */6 * * * prüft alle sechs Stunden. Das reicht für die meisten Fälle und schont die Registry-Rate-Limits. DIUN_WATCH_JITTER verteilt viele parallele Prüfungen zeitlich leicht, damit nicht alle Requests gleichzeitig losgehen.

Zustand unter /data. Hier merkt sich Diun die zuletzt gesehenen Digests. Ohne persistentes Volume würde es nach jedem Neustart alles als „neu“ melden – deshalb der Bind-Mount ./data:/data.

Notifier. Die DIUN_NOTIF_TELEGRAM_*-Variablen verdrahten den Ausgabekanal. Token kommt vom BotFather, die Chat-ID von Ihrem Bot. Mehrere Empfänger geben Sie kommasepariert an.

Lieber E-Mail statt Telegram?

Der Kanal ist reine Konfiguration. Für SMTP tauschen Sie die beiden Telegram-Zeilen gegen den Mail-Notifier:

      - "DIUN_NOTIF_MAIL_HOST=smtp.example.com"
      - "DIUN_NOTIF_MAIL_PORT=587"
      - "DIUN_NOTIF_MAIL_SSL=false"
      - "DIUN_NOTIF_MAIL_USERNAME=<YOUR_SMTP_USER>"
      - "DIUN_NOTIF_MAIL_PASSWORD=<YOUR_SMTP_PASSWORD>"
      - "DIUN_NOTIF_MAIL_FROM=diun@example.com"
      - "DIUN_NOTIF_MAIL_TO=admin@example.com"

Der Ablauf im Überblick:

   +----------------+     liest      +---------------------+
   |     Diun       | -------------> |  docker.sock (ro)   |
   |  command:serve |   Container    |  laufende Container  |
   +-------+--------+                +---------------------+
           | Schedule 0 */6 * * *
           v
   +----------------+   neuer Digest?   +------------------+
   |   Registry     | <---------------- |   Vergleich mit  |
   |   (Digest)     | ----------------> |   /data (State)  |
   +----------------+       ja          +--------+---------+
                                                 | Notify only
                                                 v
                                    +---------------------------+
                                    |  Telegram / E-Mail        |
                                    |  -> Sie entscheiden Pull  |
                                    +---------------------------+

Drei typische Stolperfallen

1. latest verrät Ihnen nichts Nützliches. Diun meldet einen Digest-Wechsel korrekt, aber latest sagt nicht, welche Version dahintersteckt. Pinnen Sie deshalb sowohl Diun selbst (crazymax/diun:4.33.0 statt latest) als auch Ihre überwachten Container auf konkrete Tags. Dann ist jede Meldung ein bewusster, nachvollziehbarer Versionssprung statt einer Blackbox.

2. Das Socket ist ein Sicherheitsfaktor. Wer Zugriff auf /var/run/docker.sock hat, kann auf dem Host praktisch alles. Mounten Sie es read-only (:ro) – Diun braucht nur Lesezugriff – und behandeln Sie den Diun-Container so vorsichtig wie jeden anderen mit Socket-Zugang. Ein Socket-Proxy ist der nächste Schritt, wenn Sie es enger ziehen wollen.

3. Fehlendes /data-Volume erzeugt Melde-Spam. Ohne persistenten Zustand startet Diun bei jedem Neustart bei null und benachrichtigt Sie über sämtliche Images erneut. Prüfen Sie, dass ./data wirklich als Volume gemountet ist und beschreibbar bleibt.

Wie es weitergeht

Damit steht ein wartbarer Ersatz für Watchtower, der Sie informiert, statt hinter Ihrem Rücken zu handeln. Naheliegende nächste Schritte: einzelne Container gezielt per diun.enable-Label steuern, weitere Kanäle wie Gotify oder ein generischer Webhook, und der Blick in die offizielle Doku zum Docker-Provider, zu den Watch-Optionen und zur Installation. Die aktuellen Image-Tags finden Sie auf Docker Hub.