Podman is an alternative to Docker which integrates better with systemd and it also offers a way to automatically update containers.

Are you updating 1000’s of stacks every week? I update a couple critical things maybe once a month, and the other stuff maybe twice a year.

I don’t recommend auto updates, because updates break things and dealing with that is a lot of work.

I just started playing with Dockhand and it looks like it has a built in update schedule mechanism. It’s fills a comparable role as Portainer, so maybe check that out.

deleted by creator

https://github.com/mag37/dockcheck

I run this script whenever I want to update my containers. Then it’s simple to individually select the containers to up date, or all of them.

I run about 70 containers. I really don’t find it that difficult. I do run a Watchtower fork, but I run it with --run-once --cleanup. I do that once a month after I feel confident that everyone else has done all the beta testing on the new updates for me. So hats off to all you guys who just yolo your updates. You are an invaluable resource to the selfhosting community. Thank you.

As far as Linux updates, I’m running Ubuntu Jammy so those updates don’t usually introduce breaking changes and I complete them as they become available. I use Portainer, but I am unaware of any auto—update features for Docker containers. You can feed it a new yaml and it will replace or recreate the container based on that yaml, but it doesn’t do it automatically. Portainer is just a handy way to consolidate all your container administration in one place in lieu of using the terminal.

There are other options to updating your containers like WUD, or similar. They will alert you that there is an update, but you have to manually initiate the update. Anecdotally, I’ve only encountered one breaking change and that was when Portainer updated, but was incompatible at the time with the current version of Docker, or something like that. Memory is foggy this morning. It took about an hour to find a fix, and implement it, so it wasn’t an excruciating change up.

Yah so dont use it ! Use Nix instead.

With Portainer you can do GitOps and have something like Dependabot notify you of updates. I don’t believe, Portainer offers completely unattended container updates.

If you want it automated, use one of the recent Watchtower forks. It’s not recommended as automated updates may break things or introduce malware through compromised accounts, however it has worked pretty well for my personal stuff. I wouldn’t recommend it for business use.

Since there’s no lack of solutions here I’m going to add one more. If you manage to create bash to update the containers then you can have it run with a systemd service that’s easy to set up. It’s very easy to set up and it’ll work the same as running the command no your computer.

One thing that helps with the “should I update?” anxiety: knowing what changed and whether it actually matters for your setup before pulling the trigger.

I built Maintenant (GitHub) and one of the features I added for exactly this reason is update detection — it checks OCI registries via HEAD requests (no image pulls, no bandwidth waste) and tells you which containers have newer images available. The Pro tier goes further with CVE detection and risk scoring that cross-references whether the container is exposed to the internet, has dependents, etc.

It won’t auto-update anything — that’s a deliberate choice, the tool is observe-only and never touches your stack. But it gives you the information to decide when updating is worth the risk, instead of either blindly auto-updating with Watchtower or manually checking Docker Hub every week.

Also does container monitoring, HTTP/TCP checks, heartbeats for cron jobs, and SSL cert tracking if you want to consolidate. Single container, zero config, ~17 MB RAM. AGPL-3.0.

deleted by creator

At work I use kubernetes and quite like that (upgrading containers without downtime FTE), but I didn’t bother trying to set up the infrastructure myself. Some argue, it’s not with the efford for self hosting, I dunno.

What I do like to use is Dockge, to keep docker but also keep your sanity. It even offers a single button for “docker compose pull”, which is great of you don’t have to many compose files / stacks. Combine with a simple shell script to batch pull/build all stacks in one go, plus some backup solution, and it’s actually nice to use and does all that I need. I love CLIs, but I’ve had situations where the GUI came in very handy.

#! /bin/bash
# note: this will update and START all dockge stacks, even if you stopped them before
shopt -s nullglob
for proj in /opt/dockge /opt/stacks/*/; do
  echo "> $proj"
  docker compose -f "$proj/compose.yaml" up --pull always --build --detach
  echo ""
done

Going to throw Dockhand into the list “things you can try to make container management easier”: https://github.com/Finsys/dockhand

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

6 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.

[Thread #214 for this comm, first seen 5th Apr 2026, 15:30] [FAQ] [Full list] [Contact] [Source code]

keeping all these containers up to date

Updates are a good way to get the security holes fixed, but unfortunately it’s also often how the holes get in in the first place.

I mean, for most projects it’s kind of sensible to assume that over long time, the code will become rather more secure and less buggy, so eventually the pros/cons might come out in favor of a strategy of updating every time. But it’s good to know that every update is inherently a double edged sword.

That’s why I like the model that distros like Debian do: they keep the code stable for long time, and only send updates for which a typically independent party (package maintainer) has already decided that a given update indeed is a necessary bugfix, or even specifically a security fix. Similar policy of course could be applied to a Docker container as well, but I don’t know how many projects do this, and it would be a per-project policy, most probably not quite independent.