Checking is easy. Deciding is the part worth talking about.
Checking
If the pull reports "Image is up to date", nothing changed. If it downloads layers, the tag has moved under you — which tells you something important about that tag.
When to update immediately
A published CVE affecting the software, anything internet-facing, and anything holding credentials. Vaultwarden, a VPN endpoint, a reverse proxy — these get updated the day a fix lands.
When to wait
Databases. A major version bump on a database image can perform a one-way upgrade of the data directory on first start, and the old binary will then refuse to open it. Pinning
Same logic for anything with plugins. Updating the core while the extensions lag behind produces an application that starts, looks fine, and fails on the one workflow nobody tested.
The update that bites hardest
An image whose entrypoint changed. Configuration that used to be read from a file is now expected in an environment variable, the container starts, logs nothing useful and serves 500s. This is why the recreate-with-old-tag escape route matters: keep the previous tag pinned somewhere you can find it at 2am.
Automating it
Watchtower will pull and recreate containers automatically. It is genuinely useful for a homelab and genuinely dangerous on a server with data on it, for every reason above. If you use it, scope it to specific containers rather than everything, and never include a database.
Panel-side there is an update check per container that compares the running image against the registry without pulling, which is the safe half of the operation — you get told something is available, and you decide. That distinction is the whole point: automated notification, manual decision.
Checking
Code:
# what you have
docker image inspect myimage:tag --format '{{.Id}} {{.Created}}'
# what the registry has now
docker pull myimage:tagIf the pull reports "Image is up to date", nothing changed. If it downloads layers, the tag has moved under you — which tells you something important about that tag.
When to update immediately
A published CVE affecting the software, anything internet-facing, and anything holding credentials. Vaultwarden, a VPN endpoint, a reverse proxy — these get updated the day a fix lands.
When to wait
Databases. A major version bump on a database image can perform a one-way upgrade of the data directory on first start, and the old binary will then refuse to open it. Pinning
postgres:16 rather than postgres:latest is not caution, it is the difference between a planned migration and an unplanned one.Same logic for anything with plugins. Updating the core while the extensions lag behind produces an application that starts, looks fine, and fails on the one workflow nobody tested.
The update that bites hardest
An image whose entrypoint changed. Configuration that used to be read from a file is now expected in an environment variable, the container starts, logs nothing useful and serves 500s. This is why the recreate-with-old-tag escape route matters: keep the previous tag pinned somewhere you can find it at 2am.
Automating it
Watchtower will pull and recreate containers automatically. It is genuinely useful for a homelab and genuinely dangerous on a server with data on it, for every reason above. If you use it, scope it to specific containers rather than everything, and never include a database.
Panel-side there is an update check per container that compares the running image against the registry without pulling, which is the safe half of the operation — you get told something is available, and you decide. That distinction is the whole point: automated notification, manual decision.