Watchtower¶
Automated container image updater. Watches our Docker containers and pulls new versions when they're published. Has no public URL — runs as a background daemon on each managed host.
| Field | Value |
|---|---|
| Public URL | none |
| Audience | automated |
| Criticality | medium — quietly important; misbehaviour can cause silent breakage |
| Maturity | [INFO NEEDED] |
| Owner | [INFO NEEDED] |
| Last reviewed | 2026-05-05 |
1. At a glance¶
Watchtower is a small automated process that checks for new versions of our container images and updates the running containers. It saves manual upgrade work — but if it pulls a broken release, services can go down at 3am with no human in the loop. The trade-off between "stay patched" and "stay stable" is decided by how it's configured.
2. Business purpose¶
- Reduce manual patching work.
- Keep security-relevant containers current.
3. Audience¶
Automated only.
4. Hosting & cloud infrastructure¶
- Server: O1 ORA448Global VPS — Watchtower runs on O1 only.
- Coverage: updates
*.448.globalcontainers running on O1. - Gap: the Dokploy host (E2) is not covered — its 9 apps (GitLab, Teams Bot, 3 WordPress, 3 Twenty CRMs, Dokploy) get no automated updates. See KI-004.
Infrastructure map¶
| Item | Value | Notes |
|---|---|---|
| Hosts running Watchtower | O1 only | E2 not yet covered |
| Container image / version | containrrr/watchtower:[INFO NEEDED] |
|
| Schedule | [INFO NEEDED] (cron / interval) |
|
| Scope | [INFO NEEDED] — all O1 containers vs label-opted-in |
|
| Image registries pulled from | Docker Hub [CONFIRM] + possibly GitLab Container Registry |
|
| Cleanup of old images | [INFO NEEDED] (--cleanup) |
|
| Notification target | [INFO NEEDED] (likely Gotify on same host) |
Credentials in Vault¶
| Secret type | Vault path / link | Last rotated |
|---|---|---|
| Container registry pull credentials | [INFO NEEDED] |
|
| Notification webhook (Gotify token) | [INFO NEEDED] |
5. Technology behind it¶
- Type: off-the-shelf
- Product: Watchtower (containrrr/watchtower)
- Stack: small Go binary in a container
6. Data it handles¶
- Container metadata, registry credentials.
- Notification messages on update events.
7. External dependencies¶
- Container registries (where it pulls images from).
- Notification target (Gotify / email / Slack webhook).
8. Authentication & access¶
- No human auth — Watchtower talks to the local Docker socket.
- Docker socket access = root-equivalent on the host. Treat as such.
9. Maturity assessment¶
| Dimension | Status | Evidence |
|---|---|---|
| Update strategy documented | [INFO NEEDED] |
which containers are auto-updated, which are pinned? |
| Notifications enabled | [INFO NEEDED] |
"image X updated to version Y" — invaluable in incident review |
| Image-pinning policy | [INFO NEEDED] |
latest is dangerous; a sha-pinned version is safer |
| Rollback procedure | [INFO NEEDED] |
how do we recover if a new image is broken? |
| Coverage | [INFO NEEDED] |
which hosts run Watchtower? |
10. Known risks & vulnerabilities¶
[CONFIRM]Auto-update oflatesttags is risky — a broken upstream release becomes our outage.[INFO NEEDED]Supply-chain compromise propagates instantly — if a base image is poisoned, Watchtower deploys it across the estate without review.[INFO NEEDED]Docker socket access — Watchtower has root-equivalent control of the host; if its container is compromised, the host is compromised.[INFO NEEDED]Silent failures — without notifications wired up, an update that crashes a service is only discovered by users.[INFO NEEDED]Inconsistent coverage — different hosts on different policies leads to "works on host A, broken on host B".
11. Impact if it goes down¶
Updates simply stop happening. Existing services keep running on whatever version they had. Low immediate impact, slow security drift.
12. Owner & on-call¶
[INFO NEEDED]
13. References & links¶
- Vendor docs: https://containrrr.dev/watchtower/
- Notification pair: Gotify