How to keep containers up to date?

General
1

I’m curious about what the best practice is in 2025 to keep containers updated.

What do you do? (And if you’re in the camp of “don’t fix what ain’t broken” and don’t want updates, what is your plan for security?)

As far as I’m aware, these are the available tools to do that that:

(Sorry, I’m a new user - I can only have two links in a post…)

  • containrrr/watchtower 21.6k stars, dead project, possibly some alive forks
  • Diun - 3.5k stars, only notifies / doesn’t actually update containers
  • getwud/wud - 1.9k stars, looks alive
  • pyouroboros/ouroboros 1.6k stars, dead project

About logging what gets updated

I’m hoping for something that updates my containers automatically, but also logs what it does persistently, including the sha256 sum of the “old” image, so if a new container is buggy for some reason, I know what container version was running before so I can revert to it. And persistently, so that even if a week and two reboots go by before I discover that a container is misbehaving, I can still see when it got updated and the old/new versions.

I don’t see that any of the tools above do that.

As a brute force solution of my own, I was thinking of a cron job periodically doing something like:

sudo docker image ls --digests --format json | \
    jq '{Repository, Tag, Digest, ID, Size}' | \
    jq -s 'sort_by(.Repository,.Tag,.Digest)'

and then persisting the output in git, which would sort of be enough information to see when hello-world:latest or whatever got updated along with the old and new sha256 sums, but I’m surprised these sha256 sum of the new and old versions aren’t present in the output of at least watchtower when I tried. I personally think automatic updates without persistent logging of what got updated is just asking for trouble.

But what is the 2025 best practice here?

2

I guess people who want to have a rollback feature use either Docker Swarm or Kubernetes. both have built-in rollbacks, but even that would require using specific version tags. I also use specific version tags with Docker Compose, so not knowing what version I had before was never a problem to me.

So if you use specific tags, the problem is not logging image IDs before pulling the new version with the same tag, but to change the compose file automatically and including the new version. I would try something like Renovate to detect new versions based on a docker compose file, let it send a pull request to a git repository and configure a pipeline to automatically deploy the new version when I accept the PR.

Renovate / Manager / Docker Compose

There are limitations sicne Docker image tags can be in many formats:

https://docs.renovatebot.com/modules/versioning/docker/

I could have sworn you were an old user, but I guess I saw your profile picture or name somewhere else.