Jan

Watchtower vs. Ouroboros: Docker-Container automatisch updaten – und warum nur eine Option zählt

Watchtower vs. Ouroboros: Auto-Updates im Vergleich – Raspberry Pi 4

Watchtower vs. Ouroboros: Nur eines der beiden Tools wird noch aktiv gepflegt.

Wenn du Docker-Container im Homelab betreibst und nicht täglich manuell docker pull ausführen willst, ist Watchtower die einzige sinnvolle Option — aktiv gepflegt, private Registries werden unterstützt, granulare Steuerung per Label. Nicht geeignet für Produktionsumgebungen ohne Rollback-Strategie und Monitoring — dort sind unkontrollierte Auto-Updates ein ernstes Risiko.

Ouroboros ist keine Alternative. Das Projekt wurde 2019 vom Entwickler selbst archiviert. Keine Patches, keine Bugfixes, keine Unterstützung für neuere Docker-Versionen. Wer heute nach „ouroboros deprecated alternative 2024 docker“ sucht, landet überall bei Watchtower — zu Recht. Viele Blogartikel und YouTube-Videos aus 2018–2020 haben beide Tools als gleichwertig dargestellt. Diese Inhalte sind noch im Netz, ohne Hinweis auf das End-of-Life. Wer nicht auf das Datum achtet, tappt direkt in die Falle.

📑 Inhaltsverzeichnis

🖥️ Teil der Grundlagen-Serie: Docker Container updaten ohne Datenverlust

Dieser Artikel ist Teil einer Grundlagen-Serie. Weitere Artikel:

Das Problem: Dein Container läuft still auf einem veralteten Image

Kein Fehler, kein Log-Eintrag, kein Hinweis — der Container läuft seit Wochen auf einem veralteten Image, Sicherheitslücken inklusive. Ein manuelles docker pull allein ändert daran nichts, weil der laufende Container danach trotzdem noch das alte Image nutzt, bis du ihn neu startest.

docker inspect zeigt den Digest und das Alter des lokal verwendeten Images – die Lücke zum Remote-Stand ist nicht sofort sichtbar.

docker inspect zeigt den Zustand des laufenden Containers. LastTagTime verrät, wann du das Image zuletzt heruntergeladen hast — nicht, wann es auf Docker Hub aktualisiert wurde. Diese Lücke ist das Problem.

Fachbegriff: Ein Image ist der unveränderliche Bauplan eines Containers. Watchtower ist ein Tool, das laufende Container überwacht und bei einem neuen Image automatisch neu startet.

Entscheidung: Watchtower, Diun oder manuell?

Szenario Empfehlung Begründung
Homelab, unkritische Dienste Watchtower + latest Minimaler Aufwand, vollautomatisch
Homelab, kritische Dienste (z. B. Vaultwarden) Watchtower + gepinnte Tags Kontrolle über Versionswechsel
Produktionsumgebung Diun + manuelles Update Kein unkontrollierter Neustart
Nur Benachrichtigung gewünscht Diun Beobachtet, updated nicht
Ouroboros läuft noch Sofort ersetzen durch Watchtower Archiviert seit 2019, kein Support
Private Registry (Harbor, Gitea, ghcr.io) Watchtower mit Registry-Auth Wird vollständig unterstützt

Watchtower vs. Diun im direkten Vergleich:

Watchtower Diun
Automatisches Update ✅ ❌
Nur Benachrichtigung optional ✅
Kontrolle behalten eingeschränkt vollständig
Rollback eingebaut ❌ –
Empfehlung für Homelab Produktion

Watchtower vs. Ouroboros im Funktionsvergleich — Ouroboros erhält seit 2019 keine Updates mehr.

Wer volle Kontrolle will und trotzdem informiert bleiben möchte: Diun für die Benachrichtigung, manuelles Update bei Bedarf. Beide Tools schließen sich nicht aus.

Setup: Watchtower mit Docker Compose deployen

Minimales Setup

Update-Zeitfenster konfigurieren (Schedule / Interval)

Watchtower unterstützt zwei Methoden zur Zeitsteuerung — Cron-Ausdruck oder Intervall in Sekunden:

Hinweis: WATCHTOWER_SCHEDULE und WATCHTOWER_POLL_INTERVAL schließen sich gegenseitig aus. Beide gleichzeitig zu setzen führt zu einem Fehler beim Start.

Einzelne Container vom Update ausschließen (Opt-out und Opt-in)

Die docker-compose.yml für Watchtower mit Schedule, Cleanup und Container-Labels für Opt-out und Opt-in.

Wichtig: Das Label com.centurylinklabs.watchtower.enable=false greift nur, wenn Watchtower ohne --label-enable läuft. Im Opt-in-Modus (--label-enable) wird nur aktualisiert, was explizit enable=true trägt. Häufiger Fehler: Label korrekt gesetzt, aber Watchtower läuft im falschen Modus — dann greift das false nicht.

Private Registry einbinden (Harbor, Gitea, ghcr.io, Quay.io)

Watchtower unterstützt private Registries und Self-Hosted-Lösungen ohne Klimmzüge. Zugangsdaten hinterlegen, fertig:

Wer denkt, Watchtower funktioniere nur mit Docker Hub, irrt. Watchtower nutzt ein Standard-Protokoll für Docker-Registries. — Watchtower unterstützt jede konforme Registry, egal ob öffentlich oder selbst gehostet.

Benachrichtigungen einrichten (Gotify, Slack, E-Mail)

Watchtower auf Raspberry Pi, Synology, Unraid und Proxmox LXC

Watchtower läuft auf allen gängigen Homelab-Plattformen ohne Anpassungen:

Plattform Besonderheit
Raspberry Pi 4 Angebot (arm64) Kein Unterschied zum x86-Setup, Image ist multi-arch
Synology NAS (Container Manager) docker-compose.yml über die GUI importieren oder SSH nutzen
Unraid Als Container über Community Applications oder manuell per Template
Proxmox LXC Docker im LXC-Container installieren, dann identisches Setup

Ressourcenverbrauch: In meinem Test auf einem Raspberry Pi 4 Angebot mit 4 GB RAM lag der Watchtower-Prozess dauerhaft bei unter 15 MB RAM — CPU-Last nur kurz beim Prüfvorgang, danach wieder bei 0 %.

Watchtower mit Portainer zusammen verwenden

Portainer und Watchtower arbeiten unabhängig voneinander. Watchtower liest direkt den Docker-Socket, Portainer stört dabei nicht. Einzige Einschränkung: Wenn Portainer Stacks verwaltet und Watchtower einen Container neu startet, zeigt Portainer den Stack danach möglicherweise als „outdated“ an, weil das laufende Image vom definierten Stack-Image abweicht. Das ist ein Darstellungsproblem, kein Funktionsproblem.

Wie Watchtower intern funktioniert

Watchtower läuft selbst als Container und beobachtet alle anderen Container auf dem System. Der Ablauf bei jedem Check-Intervall:

  1. Registry-Abfrage — Watchtower fragt bei der konfigurierten Registry nach, ob für das verwendete Image ein neuerer Digest existiert. Ein Digest ist ein eindeutiger Fingerabdruck eines Images.
  2. Vergleich — Lokaler Digest vs. Remote-Digest. Stimmen sie überein: nichts passiert. Weichen sie ab: Update wird eingeleitet.
  3. Pull — Das neue Image wird heruntergeladen, während der alte Container noch läuft.
  4. Neustart — Watchtower stoppt den alten Container, startet einen neuen mit identischer Konfiguration (gleiche Volumes, gleiche Umgebungsvariablen, gleiches Netzwerk) und dem neuen Image.
  5. Aufräumen — Das veraltete Image wird optional entfernt (WATCHTOWER_CLEANUP=true).

Der Watchtower-Prüfzyklus: Registry-Abfrage, Digest-Vergleich, Pull, Neustart und optionales Cleanup in einem automatisierten Ablauf.

Wichtig: Watchtower liest die laufende Container-Konfiguration aus — nicht deine docker-compose.yml. Was du dort definiert hast, wird beim Neustart neu erstellt. Volumes und Umgebungsvariablen bleiben erhalten, solange sie beim ursprünglichen Start korrekt übergeben wurden. Container, die ursprünglich mit unvollständigem docker run gestartet wurden, können nach dem Update fehlerhaft neu starten.

Irrtümer, die dich in die Falle locken

„Das latest-Tag garantiert die neueste Version“

Falsch. latest ist nur ein konventioneller Name — kein technischer Mechanismus. Image-Anbieter können latest auf jede beliebige Version zeigen lassen, es vergessen zu aktualisieren oder bewusst auf einer stabilen Version einfrieren. Wer wirklich kontrollierte Updates will, verwendet konkrete Versionstags (nginx:1.25.3) und ändert diese bewusst. Das gibt volle Kontrolle darüber, wann welche Version eingespielt wird — und Watchtower updated dann nur, wenn sich der Digest des gepinnten Tags ändert.

„Automatische Updates sind generell eine gute Idee“

Für Homelab-Setups ohne kritische Abhängigkeiten: vertretbar. Für alles andere brauchst du mindestens drei Dinge:

  • Benachrichtigungen — damit du weißt, was wann aktualisiert wurde
  • Ein Backup des Datenverzeichnisses vor dem Update-Fenster
  • Monitoring, das erkennt, wenn ein Container nach dem Update nicht mehr läuft — Uptime Kuma ist dafür die pragmatischste Self-Hosted-Option

Watchtower hat keinen eingebauten Rollback-Mechanismus. Wenn das neue Image einen etwas Wichtiges ändert, läuft der Dienst danach entweder gar nicht mehr oder verhält sich anders als erwartet. Die Absicherung liegt bei dir.

„Watchtower updated auch das Host-System und Docker selbst“

Watchtower schaut ausschließlich auf laufende Docker-Container und deren Images. Das Betriebssystem (Ubuntu, Debian, Raspberry Pi OS), Docker selbst, Docker Compose oder andere Programme auf dem Host bleiben von Watchtower völlig unberührt. Host-Updates musst du weiterhin manuell oder über einen separaten Mechanismus (z. B. unattended-upgrades) einrichten.

Häufig gestellte Fragen

Ist Ouroboros noch sicher zu verwenden?

Nein. Ouroboros ist seit 2019 archiviert — kein Maintainer, keine Patches, keine Fixes. Das Projekt liegt auf GitHub eingefroren und bekommt keine Sicherheitsupdates mehr. Wer Ouroboros heute noch einsetzt, läuft mit einem Tool, das selbst nicht mehr gewartet wird — und das für automatische Updates zuständig sein soll. Das ist ein Widerspruch, den du dir nicht leisten willst. Die Antwort auf „ouroboros end of life replacement watchtower“ ist eindeutig: Watchtower deployen, fertig.

Kann Watchtower meine Umgebungsvariablen und Volumes überschreiben?

Nein — solange deine docker-compose.yml korrekt gepflegt ist. Watchtower zieht das neue Image, stoppt den alten Prozess und startet ihn mit exakt denselben Parametern neu. Volumes bleiben unangetastet, Umgebungsvariablen bleiben erhalten. Das Problem entsteht, wenn Container ursprünglich manuell mit unvollständigem docker run gestartet wurden. Deshalb: Alles in der docker-compose.yml definieren.

Wie richte ich Watchtower auf einem Raspberry Pi ein?

Identisch zum Standard-Setup. Das containrrr/watchtower-Image ist multi-arch und läuft nativ auf arm64 (Raspberry Pi 4, Pi 5). Kein Unterschied in der docker-compose.yml, kein Cross-Compilation-Problem. Für docker container auto update raspberry pi homelab ist Watchtower die pragmatischste Lösung ohne Cronjob oder Skript.

Wie deploye ich Watchtower auf Synology im Container Manager?

Zwei Wege:

  1. GUI: Container Manager → Projekt → Neu → docker-compose.yml einfügen → Starten
  2. SSH: Per SSH auf die Synology verbinden, docker-compose.yml ablegen, docker compose up -d ausführen

Besonderheit: Auf Synology läuft Docker unter einem anderen Nutzer. Stelle sicher, dass der Docker-Socket korrekt eingebunden ist (/var/run/docker.sock) und die Zeitzone gesetzt ist (TZ=Europe/Berlin), damit der Schedule korrekt greift.

Wie deploye ich Watchtower auf Unraid?

Über Community Applications (CA) gibt es ein fertiges Watchtower-Template — das ist der einfachste Weg. So kommst du hin: Öffne in Unraid das Menü „Apps“ → tippe in die Suche „Watchtower“ → der Eintrag erscheint aus dem CA Store. Falls du den CA Store noch nicht installiert hast, findest du ihn unter: https://forums.unraid.net/topic/38582-plug-in-community-applications/

Im Template-Dialog füllst du die wichtigsten Felder so aus:

  • Repository: containrrr/watchtower
  • Volume-Mapping: Pfad im Container /var/run/docker.sock → Pfad auf dem Host /var/run/docker.sock (Typ: „Socket“)
  • Umgebungsvariable 1: WATCHTOWER_SCHEDULE → z. B. 0 0 3 * * * für täglich um 3 Uhr nachts
  • Umgebungsvariable 2: WATCHTOWER_CLEANUP → true (löscht alte Images nach dem Update automatisch)

Die weiteren Einstellungen wie zusätzliche Umgebungsvariablen für Benachrichtigungen findest du unter dem Tab „Show more settings“ im Template-Dialog — dort sind sie standardmäßig ausgeblendet.

In meinem Test hat das Template auf Unraid 6.12 direkt funktioniert, ohne manuelle Anpassungen. Wichtig: Stelle sicher, dass der Socket-Typ wirklich auf „Socket“ und nicht auf „Path“ gesetzt ist — sonst startet Watchtower zwar, findet aber keine anderen Container zum Aktualisieren.

Wie deploye ich Watchtower in Proxmox LXC?

Watchtower läuft im LXC-Container, in dem Docker installiert ist — nicht direkt auf dem Proxmox-Host. Setup:

  1. LXC-Container mit Docker aufsetzen (privilegierter Container oder mit nesting=1 und keyctl=1)
  2. Identisches docker-compose.yml-Setup wie oben
  3. Docker-Socket ist unter /var/run/docker.sock verfügbar
Was ist der Unterschied zwischen Watchtower Schedule und Interval?

WATCHTOWER_SCHEDULE nimmt einen 6-stelligen Cron-Ausdruck (Sekunden, Minuten, Stunden, Tag, Monat, Wochentag). WATCHTOWER_POLL_INTERVAL nimmt eine Zahl in Sekunden. Beide steuern dasselbe — wann Watchtower prüft. Beide gleichzeitig zu setzen führt zu einem Startfehler. Für einfache Fälle reicht WATCHTOWER_POLL_INTERVAL=86400 (täglich). Für präzise Zeitfenster (z. B. nachts um 3 Uhr) nimm WATCHTOWER_SCHEDULE=0 0 3 * * *.

Kann ich Watchtower als Ersatz für einen Cron-Job mit docker pull verwenden?

Ja — und Watchtower ist die bessere Lösung. Ein Cron-Job mit docker pull aktualisiert nur das lokale Image-Archiv. Der laufende Container bleibt unberührt, bis du ihn manuell neu startest. Watchtower erledigt Pull und Neustart in einem Schritt, mit identischer Konfiguration. Für docker pull automatisch cron job alternative ist Watchtower die direkte Antwort.

Was passiert, wenn ein neues Image einen Breaking Change enthält?

Watchtower zieht das neue Image und startet den Prozess neu — ohne zu prüfen, ob sich das Verhalten geändert hat. Kein eingebauter Rollback-Mechanismus. Wenn das neue Image einen Breaking Change mitbringt, läuft der Dienst danach entweder gar nicht mehr oder verhält sich anders als erwartet.

Absicherung für docker auto update rollback strategie:
– Gepinnte Versionstags statt latest in kritischen Diensten
– Backup des Datenverzeichnisses vor dem Update-Fenster
– Monitoring (z. B. Uptime Kuma), das erkennt, wenn ein Container nach dem Update nicht mehr antwortet
– Benachrichtigungen aktivieren, damit du weißt, wann ein Update stattgefunden hat

Fazit

Watchtower ist für Homelab-Setups die einzige sinnvolle Wahl für automatische Container-Updates — Ouroboros ist seit 2019 tot und kommt nicht in Frage. Wer kritische Dienste betreibt, kombiniert gepinnte Versionstags mit Benachrichtigungen und Monitoring, statt blind auf latest zu vertrauen.

Unsere Empfehlungen

* Affiliate-Links – beim Kauf erhalten wir ggf. eine Provision.

Preisvergleich

Produkt smartkram Fachhandel Amazon eBay
Raspberry Pi 4 smartkram ↗ reichelt elektronik DE ↗ Amazon ↗ eBay ↗

* Affiliate-Links – beim Kauf erhalten wir ggf. eine Provision.

✍️ Autor: homeserverlab-Redaktion

🔄 Zuletzt aktualisiert: 8. Juni 2026

Das könnte dich auch interessieren

Das könnte dich auch interessieren

/von