Watchtower

Watchtower is a small companion container that watches other running Docker containers and updates them on its own: it polls each container’s image registry, compares digests, pulls anything new, and restarts the container with the same options, volumes, and environment it originally launched with. For years it was the default answer to “how do I stop manually re-pulling images on my homelab server.” That answer changed in December 2025, when the containrrr team archived the repository for good.

What Watchtower actually does

Point Watchtower at the Docker socket and, by default, it checks every running container on a fixed interval, once every 24 hours unless configured otherwise, comparing each container’s image digest against what the registry currently serves. When a new digest shows up, Watchtower pulls it, gracefully stops the old container, and starts a replacement using the same image name, ports, volumes, environment variables, and restart policy, no manual docker run required. A --cleanup flag, or the WATCHTOWER_CLEANUP environment variable, removes the outdated image afterward instead of leaving it to pile up on disk. Scope can be narrowed to specific container names, or flipped to opt-in per container with the com.centurylinklabs.watchtower.enable=true label, handy for automating updates on background utilities while leaving anything user-facing to a manual restart. Update notifications route through shoutrrr, containrrr’s own library, covering Slack, Discord, Telegram, Gotify, and a long list of other services.

An archived project: what that actually changes

Not much changes on day one. Watchtower is a stateless binary: no license server to expire, no cloud backend to shut down, no forced update. A container already running containrrr/watchtower keeps polling and updating others indefinitely. What disappears is the safety net: if a registry API shifts in a way Watchtower doesn’t already handle, or a dependency turns up a security issue, nobody at containrrr is left to patch it. Shoutrrr, the notification library it depends on, is still maintained separately, so that piece of the pipeline isn’t stranded. For a brand-new deployment in 2026, that’s a real trade-off to weigh against Diun, covered further down, which is still under active development.

Installing Watchtower with Docker

$ docker run -d \
--name watchtower \
-v /var/run/docker.sock:/var/run/docker.sock \
containrrr/watchtower

For something that survives a reboot, with cleanup and a daily poll interval baked in:

services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_POLL_INTERVAL=86400

Run docker compose up -d and Watchtower checks every container on the host once a day, cleaning up old images as it goes. To switch from watching everything to an opt-in model, add WATCHTOWER_LABEL_ENABLE=true to the environment block, then tag only the containers that should auto-update with com.centurylinklabs.watchtower.enable=true in their own compose file. Anything without the label gets left alone, the safer default for containers that need a manual look before restarting, like a database.

Homelab use cases

The clearest fit is a stack of low-risk, easily-replaceable containers: an RSS reader, a link shortener, a status page, anything where a bad auto-update just means a manual restart instead of lost data. Point Watchtower at those and skip the weekly “anything need updating” check entirely. It pairs naturally with a stack manager: deploy and edit compose files through Dockge or click through containers in Portainer, then let Watchtower handle the pull-and-restart cycle for whatever’s labeled. Because notifications route through shoutrrr, a Watchtower instance can post to the same Discord or Slack channel already used for other homelab alerts, so an update shows up next to the rest of the day’s notices instead of needing a separate dashboard check. The Docker & Containers category rounds out other tools built around this workflow.

Watchtower vs Diun

Watchtower and Diun get compared constantly because they look like they solve the same problem, but they don’t. Watchtower updates containers; Diun only reports that an update exists and leaves the pulling and restarting to a human. That distinction matters more now that Watchtower is archived: Diun remains under active development, with releases as recent as mid-2026, while Watchtower’s codebase is frozen at v1.7.1.

Category	Watchtower	Diun
Action on new image	Pulls and restarts automatically	Notifies only, no restart
Maintenance status	Archived December 2025, read-only	Actively maintained
License	Apache License 2.0	MIT License
Best fit	Low-risk containers that are fine restarting unattended	Anything where a human should approve the update first

Watchtower: pros and cons

• Free and open source under the Apache License 2.0, no account or license key required
• Genuinely hands-off: once labeled, containers update themselves with no further input
• Built-in cleanup flag keeps old images from quietly filling up disk space
• Notifications cover most chat and push services through shoutrrr

• Archived as of December 2025: no further bug fixes, security patches, or new features
• Requires Docker socket access, the same root-equivalent trade-off as Portainer and Dockge
• Auto-restarting a container is occasionally the wrong call for anything stateful, like a database, without careful labeling

FAQ

Is Watchtower free?

Yes, entirely, under the Apache License 2.0. There’s no paid tier, account, or license key involved, and there never was.

Is Watchtower still safe to use in 2026?

The container still runs and still works as documented. The concern isn’t function, it’s that no one is left to fix a future bug or security issue, which matters more the longer the archive date recedes into the past.

Does Watchtower update every container by default?

Yes, unless it’s restricted to named containers or switched to the opt-in label model with WATCHTOWER_LABEL_ENABLE=true, in which case only containers carrying com.centurylinklabs.watchtower.enable=true get touched.

Should I use Watchtower or Diun for a new setup?

For anything where an unattended restart is genuinely fine, Watchtower still works exactly as it did before the archive. For anything where a person should review an update first, or for a setup meant to keep receiving fixes, Diun is the actively maintained option.

Watchtower still does the one job it was built for: unattended container updates, no scripts required. What changed in December 2025 is the safety net behind it, not the container itself. For a homelab stack that’s already labeled and running, there’s no urgent reason to rip it out. For a new deployment, it’s worth reading the archive notice first and weighing whether Diun’s notify-only, actively-maintained approach fits better long-term. The Docker & Containers category and the homelab setup guide for beginners cover the rest of the stack Watchtower usually sits alongside.