On-demand Docker updates for when Watchtower blinks
Teaching my agent to update Docker stacks within policy — including the source-built ones that have no image to pull.
I wanted my containers to stay current without me babysitting them — but on my terms, not whatever the registry shipped last night. So I sat down with my agent, walked it through how I’d do the job by hand, and turned that into a reusable skill.
Two gaps Watchtower leaves open
Watchtower auto-pulls :latest on a schedule. Convenient — until you look closely. It takes no backups, treats every container the same, and when its mail relay is misconfigured it updates silently, happily dragging apps past my “pin it and let it age” policy. It also only understands registry images.
And some of my containers don’t have one. My self-hosted time-tracker is built from source, so docker compose pull simply skips it — Watchtower can never touch it.
What I built instead
A small skill that updates the way I would: preview what would actually change, back up state first (database dump or volume tar, onto the data drive, not root), recreate only what changed, verify health, and keep a rollback point. It honours the rules I already follow — pinned versions, at least four weeks old, databases patched within their major only.
Two paths, one careful procedure
For registry images it’s a controlled pull and recreate. For source-built apps it does the thing a pull can’t: fetch the new release tag, rebuild, and let the migrations run — which is exactly how the time-tracker went 5.6 → 5.8 cleanly, database and all.
Automation isn’t about removing the human. It’s about making the careful path the easy one.
The result: updates I can trigger on demand — a sane fallback for when Watchtower fails or drifts, and a way to update the custom containers that never had an image to pull in the first place.