Watchtower

Watchtower monitors your running Docker containers, polls the registry for new image versions on a schedule, and when it finds one, pulls the updated image, gracefully stops the old container, and restarts it with exactly the same options the original container was launched with. For homelab stacks and personal self-hosted setups, it eliminates the manual maintenance loop of remembering to update each container individually.

The default behaviour is to watch all running containers and update anything with a newer image available. Labels on individual containers override this: you can set a container to never update automatically, to only update if explicitly triggered, or to follow a different schedule from the rest of the stack. This granularity is important because not all containers should update the same way.

Notifications are built in via the Shoutrrr notification library, which covers Slack, Discord, email, Gotify, ntfy, and a webhook endpoint. When Watchtower applies an update you get a message listing which containers were updated and the image versions involved. That is enough information to know what changed without needing to check manually.

The caution is real and worth taking seriously: automatic updates can break things. A new image version with a changed environment variable name, a required database migration, or a removed configuration option will cause a container to fail after update. Databases and anything with persistent state are the highest-risk candidates. The standard practice is to exclude those from Watchtower and manage their updates manually while letting stateless application containers update freely.

Watchtower is not a deployment pipeline — it is a maintenance shortcut for setups where unattended updates are acceptable. For production services, the right tool is a CI/CD system that tests changes before they reach running containers.

Watchtower: Pros & Cons