Watchtower — automatyczne aktualizacje kontenerów Dockera

Watchtower pilnuje, żeby działające kontenery używały aktualnych obrazów. Odpytuje rejestr o skrót obrazu, a gdy ten się zmienił — pobiera nową wersję, zatrzymuje stary kontener, tworzy nowy z tą samą konfiguracją (zmienne, wolumeny, sieci, porty) i uruchamia go. Jeden kontener, jeden zamontowany socket Dockera, zero konfiguracji na start.

Problem polega na tym, że projekt, który wychodzi pierwszy w wyszukiwarce i który jest wklejany do tysięcy plików docker-compose.yml, nie jest już utrzymywany. Repozytorium containrrr/watchtower zostało zarchiwizowane, ostatnie wydanie v1.7.1 ma datę 11 listopada 2023, a obraz na Docker Hubie był budowany ostatni raz 3 stycznia 2024. Licznik pobrań tego obrazu przekroczył tymczasem 8,2 miliarda. Skala rozbieżności między tymi dwiema liczbami jest właściwym tematem tego wpisu.

Rozwój przeniósł się do forka nicholas-fedor/watchtower: 4289 gwiazdek, Apache-2.0, wydanie v1.21.0 z 19 sierpnia 2026, 54 wydania od stycznia 2025 (19 w samym 2026 roku), obraz nickfedor/watchtower odświeżany tego samego dnia, 10,8 miliona pobrań. Poniżej: co Watchtower robi, co się stało z oryginałem, jak ocenić fork i — najważniejsze — dlaczego to narzędzie nie należy do produkcji, mimo że właśnie tam najczęściej trafia.

Jak to działa

Cały mechanizm mieści się w kilku krokach, wykonywanych domyślnie raz na 24 godziny:

Watchtower czyta listę działających kontenerów przez socket Dockera.
Dla każdego z nich odpytuje rejestr o skrót (digest) obrazu wskazanego przez tag, którym kontener został uruchomiony.
Jeśli skrót różni się od tego, na którym kontener działa, pobiera nowy obraz.
Zatrzymuje kontener z zachowaniem sygnału zamknięcia i limitem czasu (domyślnie 30 sekund).
Tworzy nowy kontener z konfiguracją odczytaną ze starego i uruchamia go.
Opcjonalnie usuwa nieużywany już obraz (--cleanup).

Kluczowa konsekwencja punktu drugiego: Watchtower nie aktualizuje wersji, tylko dogania tag. Kontener uruchomiony z :latest dostanie każdą zmianę, jaka trafi pod ten tag — także zmianę łamiącą zgodność. Kontener uruchomiony z :18-alpine pozostanie na tej linii i dostanie tylko jej poprawki. Kontener przypięty do skrótu (image@sha256:...) nie dostanie nic, bo nie ma czego dogonić. To nie jest wada — to jest cała semantyka narzędzia i wybór tagu jest tu jedyną realną polityką aktualizacji, jaką masz.

Konfiguracja odbywa się przez flagi, zmienne środowiskowe WATCHTOWER_* albo etykiety na monitorowanych kontenerach. Etykiety wciąż siedzą w przestrzeni nazw com.centurylinklabs.watchtower.* — pamiątka po pierwotnym autorze narzędzia, zachowana także w forku, co przy migracji jest dobrą wiadomością.

Co się stało z oryginałem

17 grudnia 2025 opiekunowie projektu ogłosili zakończenie prac. Powód podali bez owijania: nie używają już Dockera na tyle, żeby mieć interes w utrzymywaniu narzędzia, i skończył im się zapał oraz czas. Repozytorium przeszło w tryb tylko do odczytu, a w README pojawiła się nota o braku utrzymania. Osobny projekt Shoutrrr — biblioteka powiadomień, z której Watchtower korzysta — miał pozostać aktywny.

W tym samym ogłoszeniu zawarli ostrzeżenie, które trzeba przekazać dalej, bo jest niewygodne: przejrzeli kilka aktywnych forków i ich ocena była taka, że część z nich jest zapchana kodem generowanym przez AI — działać może, ale korzystania z żadnego z nich nie polecają. Nie wskazali, których. To pozostawia każdemu użytkownikowi obowiązek samodzielnej oceny, zanim podmieni nazwę obrazu w pliku Compose'a.

Praktyczne skutki pozostania na zarchiwizowanym obrazie są trzy i żaden nie jest teoretyczny:

Zależności zamrożone w styczniu 2024. Obraz zawiera binarkę Go zbudowaną z ówczesnych bibliotek. Każda podatność znaleziona od tego czasu w tym drzewie zależności w nim została i skaner obrazów będzie to raportował.
Brak nadążania za API Dockera. Silnik idzie do przodu, klient w obrazie stoi. Objawy bywają nieoczywiste — narzędzie, które recytuje konfigurację starego kontenera do nowego, przy rozjazdach wersji API może po prostu zgubić jakieś pole.
Nikt nie przyjmie zgłoszenia. Repozytorium jest zamknięte na issues i pull requesty.

Narzędzie, którego jedynym zadaniem jest utrzymywanie oprogramowania w aktualnej wersji, samo od dwóch i pół roku nie dostało aktualizacji. To wystarczający powód, żeby przestać je instalować z pamięci mięśniowej.

Fork: jak go ocenić

Ostrzeżenie autorów oryginału zostaje w mocy — my kodu forka nie audytowaliśmy i nie zamierzamy udawać, że nasza rekomendacja zastępuje taki audyt. Da się natomiast sprawdzić sygnały zewnętrzne, i to jest rzecz, którą warto umieć zrobić przy dowolnym forku, nie tylko tym:

Rytm wydań, nie sam fakt istnienia. 54 wydania od stycznia 2025, 19 w 2026 roku, najnowsze tego samego dnia, w którym piszemy. Fork zrobiony raz i porzucony wygląda w tym zestawieniu zupełnie inaczej.
Czy ktokolwiek poza autorem tam zagląda. Lista współtwórców jest przeniesiona z oryginału i rośnie o nowe nazwiska; commity z ostatnich dni to dopisywanie kolejnych osób do listy autorów kodu.
Czy powstaje coś nowego, czy tylko bumpy zależności. Tu doszło sporo: rozbudowane HTTP API (historia skanów w buforze pierścieniowym, strumień zdarzeń przez SSE, metryki dla Prometheusa, Swagger UI, oddzielne sondy /livez, /readyz, /startupz), obsługa Podmana (flagi --disable-memory-swappiness i --cpu-copy-mode), okres kwarantanny dla świeżych obrazów, obrazy na riscv64 obok amd64, arm64, 386 i armhf.
Higiena zgłoszeń. 10 otwartych zgłoszeń wobec 219 pozostawionych w oryginale.
Licencja bez zmian. Apache-2.0, tak jak w oryginale.
Deprecjacje prowadzone jawnie. Stare opcje HTTP API (--http-api-update, --http-api-metrics) działają, ale są oznaczone jako przeznaczone do usunięcia w wersji 2.x na rzecz jednego --http-api-endpoints. Projekt, który zapowiada zmiany łamiące zgodność zamiast wprowadzać je po cichu, jest łatwiejszy do utrzymania po naszej stronie.

Nasze stanowisko: to wystarczające przesłanki, żeby używać forka na własnej infrastrukturze pomocniczej i w środowiskach deweloperskich. Nie są wystarczające, żeby wpuścić narzędzie z dostępem do socketu Dockera na maszynę klienta bez przeczytania, co ono robi — a przy narzędziu tej klasy przeczytanie znaczy przejrzenie diffu wobec ostatniego wydania oryginału, nie przeczytanie README. I niezależnie od oceny: przypnij konkretną wersję obrazu, nie latest. Narzędzie, które samo aktualizuje wszystko dookoła, jest ostatnim, które powinno aktualizować się bez Twojej wiedzy.

Czego autorzy sami nie polecają

W README — zarówno oryginału, jak i forka — stoi zdanie, które w dyskusjach o Watchtowerze jest pomijane najczęściej: narzędzie jest przeznaczone do domowych serwerowni, centrów multimediów i lokalnych środowisk deweloperskich, a autorzy nie zalecają używania go w środowisku komercyjnym ani produkcyjnym. Zamiast tego odsyłają do Kubernetesa z porządnym CI/CD.

Warto rozumieć, dlaczego, bo powody nie są kwestią gustu:

Brak bramki jakościowej. Watchtower sprawdza, czy obraz się zmienił — nie czy nowa wersja działa. Nie ma testów dymnych, nie ma wdrożenia kanarkowego, nie ma automatycznego wycofania. Jeśli nowy obraz startuje i pada w pętli, dowiesz się z monitoringu, o ile go masz.
Migracje bazy danych. Aplikacja laravelowa po podmianie obrazu zwykle wymaga artisan migrate. Watchtower o tym nie wie. Da się to podwiesić na hooku po aktualizacji, tylko wtedy piszesz własny system wdrożeń w etykietach Dockera — a to jest gorsze narzędzie do tego zadania niż dowolny pipeline.
Przerwa w działaniu. Domyślnie kontener jest zatrzymywany i tworzony na nowo. --rolling-restart ogranicza to przy wielu replikach, ale pojedyncza instancja aplikacji zawsze na chwilę zniknie.
Zaufanie do rejestru bez pośredników. Wdrożenie na produkcję jest decyzją, którą ktoś podejmuje. Tu decyzję podejmuje ten, kto wypchnął obraz pod obserwowany tag — a to niekoniecznie Twój zespół, jeśli obraz jest cudzy.
Brak śladu. Pipeline zostawia numer wdrożenia, changelog i osobę, która kliknęła. Watchtower zostawia wpis w logu kontenera.

Co robimy zamiast tego u klientów: obrazy budowane w CI i tagowane skrótem commita, wdrożenie jako świadomy krok pipeline'u, aktualizacje zależności podnoszone przez Renovate albo Dependabota w repozytorium (czyli jako pull request z widocznym diffem, a nie jako zdarzenie na serwerze), a przy Kubernetesie automatyzacja obrazów po stronie Fluxa. Kolejność jest tu istotna: aktualizacja ma być zmianą w repozytorium, którą się przegląda, nie akcją, która dzieje się na maszynie o czwartej rano.

Gdzie Watchtower ma sens

To nie znaczy, że narzędzie jest bezużyteczne — znaczy, że ma węższe zastosowanie, niż sugeruje jego popularność:

Nasza własna infrastruktura pomocnicza. Mailpit, Adminer, panele podglądowe, kontenery narzędziowe na maszynie deweloperskiej. Rzeczy, których awaria kosztuje kwadrans i nikogo poza nami.
Środowiska deweloperskie i staging. Tam, gdzie świeży obraz jest wartością, a przerwa w działaniu nie ma ceny.
Domowa serwerownia. Scenariusz, do którego narzędzie zostało zaprojektowane.
Tryb monitorowania na produkcji. Bez podmieniania czegokolwiek — o tym niżej, bo to jedyny wariant produkcyjny, który uważamy za sensowny.

Konfiguracja, którą warto ustawić

Domyślne uruchomienie z dokumentacji monitoruje wszystkie kontenery na hoście i podmienia je bez pytania. Poniżej wariant, który stosujemy: opt-in przez etykietę, stała godzina, powiadomienia, kwarantanna dla świeżych obrazów.

services:
    watchtower:
        image: 'nickfedor/watchtower:1.21.0'
        restart: unless-stopped
        environment:
            # Tylko kontenery z etykietą enable=true
            WATCHTOWER_LABEL_ENABLE: 'true'
            # 6-polowy cron: codziennie 4:00 czasu lokalnego
            WATCHTOWER_SCHEDULE: '0 0 4 * * *'
            TZ: 'Europe/Warsaw'
            WATCHTOWER_CLEANUP: 'true'
            WATCHTOWER_TIMEOUT: '60s'
            # Nie ruszaj obrazu młodszego niż 24 godziny
            WATCHTOWER_COOLDOWN_DELAY: '24h'
            # Powiadomienie tylko wtedy, gdy coś się stało
            WATCHTOWER_NOTIFICATION_REPORT: 'true'
            WATCHTOWER_NO_STARTUP_MESSAGE: 'true'
            WATCHTOWER_NOTIFICATION_URL: '/run/secrets/notification_urls'
        secrets:
            - notification_urls
        volumes:
            - '/var/run/docker.sock:/var/run/docker.sock'

secrets:
    notification_urls:
        file: './secrets/notification_urls.txt'

Monitorowany kontener włącza się do zabawy etykietą:

labels:
    com.centurylinklabs.watchtower.enable: 'true'

Wybór kontenerów

Semantyka etykiety enable zależy od tego, czy ustawisz --label-enable, i to jest miejsce, w którym łatwo się pomylić:

Bez --label-enable monitorowane są wszystkie kontenery poza tymi, które mają etykietę ustawioną na false. Czyli model „wypisz się".
Z --label-enable monitorowane są wyłącznie kontenery z etykietą true. Czyli model „zapisz się" — jedyny, który uważamy za rozsądny, gdy na hoście stoi cokolwiek, czego nie chcesz stracić.

Poza tym są bardziej precyzyjne filtry: --disable-containers (nazwy, także wyrażeniami regularnymi), --enable-containers-by-label i --disable-containers-by-label (pary klucz=wartość, przy czym samo klucz= sprawdza obecność etykiety), --monitor-image-names (wzorce nazw obrazów razem z tagiem, dopasowywane do pełnej nazwy). Kontenery zatrzymane wchodzą do gry tylko z --include-stopped, a wstają po aktualizacji dopiero z --revive-stopped.

Tryb monitorowania — wariant produkcyjny

Najbardziej użyteczna flaga w całym narzędziu, jeśli mówimy o środowisku, na którym komuś zależy:

WATCHTOWER_MONITOR_ONLY: 'true'

Watchtower sprawdza wtedy obrazy, wysyła powiadomienia i wykonuje hooki, ale niczego nie podmienia. Dostajesz na Slacka informację „obraz aplikacji ma nową wersję", a decyzję i moment wdrożenia zachowujesz dla siebie. Da się to ustawić także per kontener, etykietą com.centurylinklabs.watchtower.monitor-only, co pozwala mieć na jednym hoście kontenery aktualizowane automatycznie i takie, które tylko raportują.

Jedno zastrzeżenie z dokumentacji: w tym trybie obrazy nadal mogą być pobierane, bo porównanie skrótów przez API Dockera tego wymaga. Miejsce na dysku i transfer są więc zużywane tak samo — nie zmienia się tylko stan kontenerów.

Jeśli chcesz wyłącznie powiadomień, warto wiedzieć, że istnieją narzędzia zaprojektowane dokładnie do tego (na przykład Diun) i nie potrzebują uprawnień do podmieniania kontenerów. Watchtower w trybie monitorowania nadal ma pełny dostęp do socketu Dockera — ograniczenie jest w konfiguracji, nie w uprawnieniach.

Harmonogram i uruchomienie jednorazowe

Domyślny odstęp to 86400 sekund. Zamiast interwału lepiej użyć --schedule z sześciopolowym wyrażeniem cron (pierwsze pole to sekundy — 0 0 4 * * * to czwarta rano, nie 0 4 * * *). Wymaga to ustawionej strefy czasowej przez TZ albo zamontowanego /etc/localtime; bez tego harmonogram chodzi w UTC i zdziwienie przychodzi po pierwszej zmianie czasu. Flagi --schedule i --interval wykluczają się wzajemnie.

Osobny tryb to --run-once: jedno przejście i wyjście, z automatycznym ustawieniem polityki restartu na no. To najlepszy sposób wpięcia Watchtowera w istniejący pipeline albo crona hosta — aktualizacja dzieje się wtedy, kiedy Ty chcesz, a nie kiedy wypadnie interwał. Jest też --update-on-start, jeśli chcesz przejścia przy starcie i dalej według harmonogramu.

Restart kroczący i healthcheck

--rolling-restart aktualizuje kontenery po jednym. Istotny szczegół, który ratuje ten tryb: jeśli kontener ma zdefiniowany healthcheck, Watchtower czeka, aż zgłosi stan zdrowy, przed przejściem do następnego. Po pięciu minutach bez sukcesu loguje ostrzeżenie i idzie dalej — nie zatrzymuje całego cyklu, co jest wyborem projektowym wartym zapamiętania, bo oznacza, że niesprawna nowa wersja nie wstrzyma aktualizacji pozostałych kontenerów.

Dwa ograniczenia: tryb nie współpracuje z kontenerami powiązanymi (wymagają skoordynowanej aktualizacji łańcucha zależności), a w połączeniu z --cleanup usuwanie obrazów jest odkładane do końca cyklu, co przy kilkudziesięciu kontenerach chwilowo zajmuje więcej miejsca na dysku.

Powiadomienia

Powiadomienia idą przez Shoutrrr, w formacie URL-a usługi:

<usługa>://<dane-uwierzytelniające>@<host>/<ścieżka>?<klucz>=<wartość>

Można podać kilka adresów rozdzielonych przecinkiem albo — i tak jest zalecane — wskazać plik, bo te adresy zawierają tokeny. W Compose'ie oznacza to sekret montowany pod /run/secrets/ i zmienną WATCHTOWER_NOTIFICATION_URL wskazującą na ścieżkę pliku, nie na wartość.

Dwie flagi decydują o tym, czy powiadomienia będą czytane, czy wyciszone po tygodniu: --notification-report wysyła raport z cyklu zamiast strumienia pojedynczych zdarzeń, a --no-startup-message usuwa wiadomość wysyłaną przy każdym starcie kontenera. Poziom szczegółowości ustawia się osobno.

Hooki cyklu życia

Cztery punkty zaczepienia, wyłączone domyślnie (--enable-lifecycle-hooks): pre-check przed cyklem, pre-update przed zatrzymaniem kontenera, post-update po uruchomieniu nowego, post-check po zakończeniu cyklu. Definiuje się je etykietami na monitorowanym kontenerze:

labels:
    com.centurylinklabs.watchtower.enable: 'true'
    com.centurylinklabs.watchtower.lifecycle.pre-update: '/usr/local/bin/przed-aktualizacja.sh'
    com.centurylinklabs.watchtower.lifecycle.post-update: '/usr/local/bin/po-aktualizacji.sh'

Polecenia wykonują się wewnątrz monitorowanego kontenera przez API exec Dockera, więc wszystko, czego używają (powłoka, jq, klient bazy), musi być w tym obrazie. Domyślny limit czasu to minuta, do nadpisania osobnymi etykietami. Hooki można uruchomić pod wskazanym UID i GID — globalnie flagami albo per kontener etykietami, które mają pierwszeństwo. I rzecz, która potrafi zmylić przy diagnozowaniu: jeśli kontener nie działa, faza zatrzymania jest pomijana, więc hook pre-update się nie wykona.

To jest miejsce, w którym można zrobić kopię bazy przed podmianą obrazu albo odpalić migracje po niej. Powtórzymy jednak wcześniejszą uwagę: jeśli logika wdrożenia rozrasta się w etykietach Dockera, sygnał jest taki, że potrzebny jest pipeline, a nie kolejna etykieta.

HTTP API

Fork rozbudował tę część najbardziej. Serwer jest domyślnie wyłączony; włącza się go, wskazując zestaw końcówek i token:

WATCHTOWER_HTTP_API_ENDPOINTS: 'update,containers,metrics,health'
WATCHTOWER_HTTP_API_TOKEN: '/run/secrets/watchtower_token'

Dostępne są między innymi: POST /v1/update (wyzwolenie aktualizacji, z filtrami po nazwie kontenera i obrazu oraz trybem asynchronicznym), POST /v1/check (sprawdzenie bez aktualizacji), GET /v1/containers i /v1/containers/details, GET /v1/history (historia skanów z bufora pierścieniowego, do 500 wpisów), GET /v1/images, GET /v1/config, GET /v1/events (strumień SSE), GET /v1/status i GET /v1/metrics (format Prometheusa) oraz sondy /livez, /readyz, /startupz bez uwierzytelnienia.

Końcówka /v1/update jest ciekawa właśnie w kontekście zastrzeżeń z poprzedniej sekcji: pozwala odwrócić kierunek sterowania. Watchtower przestaje wtedy zgadywać, kiedy aktualizować, a zaczyna być wykonawcą polecenia z Twojego pipeline'u po udanym buildzie i testach. Token API czytany z pliku sekretu, port niewystawiony poza sieć Compose'a.

Uwaga do strumienia zdarzeń: ma osobny token, bo przeglądarkowy EventSource nie ustawia własnych nagłówków i token trafia do parametru w adresie — czyli do historii przeglądarki i logów proxy. Dokumentacja mówi o tym wprost i zaleca uwierzytelnianie nagłówkiem tam, gdzie to możliwe.

Rejestry prywatne i zdalne hosty

Do obrazów z rejestru prywatnego Watchtower potrzebuje pliku config.json w formacie klienta Dockera — albo skopiowanego z ~/.docker/config.json po docker login, albo napisanego ręcznie z zakodowanym base64 ciągiem użytkownik:hasło. Montuje się go do kontenera:

docker run [...] -v /sciezka/config.json:/config.json nickfedor/watchtower

Przy Docker Hubie nazwą rejestru jest https://index.docker.io/v1/. Dla Google Cloud użytkownikiem jest _json_key, a hasłem zawartość pliku z kluczem serwisowym.

Watchtower może też pilnować zdalnego demona przez DOCKER_HOST wskazujący na tcp://host:port, z --tlsverify i katalogiem certyfikatów. Wersja API jest domyślnie negocjowana automatycznie; jeśli ustawisz DOCKER_API_VERSION ręcznie, jest walidowana i przy niezgodności następuje powrót do negocjacji.

Bezpieczeństwo

Trzy rzeczy do rozstrzygnięcia przed uruchomieniem, wszystkie wynikające z jednego faktu.

Zamontowany /var/run/docker.sock to uprawnienia równoważne rootowi na hoście. Kontener z tym socketem może uruchomić dowolny obraz z zamontowanym katalogiem głównym systemu. Watchtower nie jest tu wyjątkiem — jest po prostu kontenerem, któremu to dajesz świadomie.

Socket. Jeśli host obsługuje coś więcej niż domową serwerownię, rozważ proxy do socketu, przepuszczające tylko potrzebne wywołania API, zamiast montowania go bezpośrednio. Watchtower potrzebuje listowania, pobierania obrazów, zatrzymywania, tworzenia i uruchamiania kontenerów — to i tak dużo, ale mniej niż wszystko.

Etykiety wykonują polecenia. Przy włączonych hookach każdy, kto może dodać etykietę do kontenera (czyli każdy z dostępem do plików Compose'a albo do API Dockera), może wykonać dowolne polecenie w tym kontenerze. Hooki są wyłączone domyślnie i to jest dobra wartość domyślna.

HTTP API. Token trzymaj w sekrecie, portu nie wystawiaj poza sieć wewnętrzną. Końcówka /v1/update to zdalne wyzwolenie podmiany kontenerów — dla atakującego to gotowy przycisk.

Osobna kwestia to kwarantanna świeżych obrazów. --cooldown-delay (na przykład 24h, 3d, 1w) każe pominąć obrazy młodsze niż podany czas, liczony ze znacznika utworzenia w rejestrze. Ma to sens wobec scenariusza, w którym cudze konto w rejestrze zostaje przejęte i pojawia się złośliwy obraz — daje czas na reakcję świata. Dokumentacja uczciwie zaznacza dwie rzeczy: to nie jest mechanizm bezpieczeństwa, a opóźnienie dotyczy wszystkich aktualizacji, także krytycznych poprawek.

Migracja z zarchiwizowanego obrazu

Jeśli masz gdzieś działającego containrrr/watchtower, przejście jest krótkie:

Podmień obraz na nickfedor/watchtower:1.21.0 — z przypiętą wersją, nie latest.
Etykiet nie ruszasz: przestrzeń nazw com.centurylinklabs.watchtower.* jest zachowana.
Przejrzyj flagi HTTP API, jeśli ich używasz — --http-api-update, --http-api-containers i --http-api-metrics działają, ale są przeznaczone do usunięcia w wersji 2.x na rzecz --http-api-endpoints.
Przy okazji ustaw --label-enable i tryb monitorowania tam, gdzie automatyczna podmiana nie była świadomą decyzją, a domyślnym zachowaniem, którego nikt nie zmienił.
Sprawdź, czy dotyczą Cię nowe flagi zgodności z Podmanem, jeśli hosty nie chodzą na Dockerze.

Punkt czwarty jest najważniejszy. Migracja jest dobrym momentem, żeby zapytać, czy automatyczna aktualizacja na tym hoście była kiedykolwiek zamierzona.

Na co uważać

Oryginał jest zarchiwizowany — obraz z 3 stycznia 2024, bez poprawek bezpieczeństwa, bez możliwości zgłoszenia błędu.
Autorzy oryginału ostrzegają przed forkami i nie wskazują, którym można zaufać. Ocena jest po Twojej stronie.
Autorzy nie polecają Watchtowera do środowisk komercyjnych i produkcyjnych. To zdanie z README, nie nasza interpretacja.
latest to nie wersja, a polityka. Watchtower dogania tag; przypięcie do skrótu obrazu wyłącza go całkowicie.
Domyślnie monitoruje wszystko na hoście. Bez --label-enable jedyną ochroną jest etykieta false na każdym kontenerze, o którym pamiętasz.
Cron ma sześć pól. Wyrażenie pięciopolowe z crontaba zachowa się inaczej, niż myślisz.
Bez TZ harmonogram chodzi w UTC.
Tryb monitorowania nadal pobiera obrazy i nadal ma pełny dostęp do socketu.
--remove-volumes usuwa wolumeny anonimowe. Nazwane zostają, ale dane w anonimowym wolumenie znikną razem ze starym kontenerem.
--no-restart z --cleanup przy samoaktualizacji Watchtowera może zostawić przemianowany kontener bez uruchomienia następnego.
Restart kroczący nie działa z kontenerami powiązanymi i odkłada usuwanie obrazów do końca cyklu.
Hooki wymagają narzędzi w monitorowanym obrazie i nie wykonają fazy pre-update, jeśli kontener nie działa.

Podsumowanie

Watchtower rozwiązuje realny problem — utrzymywanie kontenerów przy aktualnych obrazach bez ręcznej pracy — i robi to prościej niż cokolwiek innego w tej kategorii. Trzeba go jednak dziś oceniać razem z kontekstem, w jakim się znalazł: oryginał jest zarchiwizowany, rozwój toczy się w forku, a sami autorzy nigdy nie zalecali tego narzędzia do produkcji.

Co daje:

automatyczną podmianę obrazów z zachowaniem konfiguracji kontenera — zmiennych, wolumenów, sieci i portów,
wybór kontenerów etykietami, wzorcami nazw i par klucz=wartość, z modelem „zapisz się" pod --label-enable,
harmonogram sześciopolowym cronem albo tryb jednorazowy do wpięcia w pipeline,
tryb monitorowania, w którym narzędzie tylko raportuje dostępne aktualizacje — jedyny wariant, jaki uważamy za sensowny na produkcji,
powiadomienia przez Shoutrrr do kilkudziesięciu usług, z adresami trzymanymi w sekretach,
hooki w czterech punktach cyklu życia, wykonywane w monitorowanym kontenerze,
HTTP API z wyzwalaniem aktualizacji, historią skanów, strumieniem zdarzeń, metrykami dla Prometheusa i sondami stanu,
restart kroczący czekający na stan zdrowy kontenera, obsługę rejestrów prywatnych, zdalnych demonów po TLS i kwarantannę świeżych obrazów,
aktywny fork z rytmem 19 wydań w 2026 roku i obrazami na pięć architektur, włącznie z riscv64.

Licencja: Apache-2.0, w oryginale i w forku. Przy komercyjnym użyciu jest to licencja bez pułapek — pozwala na użycie, modyfikację i dystrybucję, daje wyraźną licencję patentową, a jedyne realne obowiązki dotyczą sytuacji, w której rozprowadzasz zmodyfikowaną wersję dalej: zachowanie noty o prawach autorskich, pliku NOTICE i oznaczenie wprowadzonych zmian. Samo uruchamianie kontenera w firmie nie pociąga za sobą niczego.

Ryzyko w tym projekcie nie leży więc w licencji, tylko w utrzymaniu i zaufaniu — a to są rzeczy, których nie rozstrzyga plik LICENSE. Przy narzędziu, które ma prawo zatrzymać i odtworzyć dowolny kontener na hoście, warto to nazwać wprost: przypnij wersję obrazu, ogranicz zasięg etykietą, na produkcji zostaw sam tryb monitorowania, a decyzję o wdrożeniu zostaw pipeline'owi i człowiekowi.