For those of you that use docker, how do you make sure your docker-compose.yml (and possibly .env) files stay current with the project’s ongoing updates? I’m sure there’s an easier way than what I’m doing which is manually getting the latest ones and checking the diffs in vscodium. And I’m sure some git magic already takes care of this but I’ve been slow in learning git beyond the VERY basics. Thanks!
You must log in or register to comment.
I don’t pay any mind to example compose files. My are all quite custom anyway. Only thing that matters is paying attention to changelogs and watching for breaking changes.
This is new:
https://github.com/dkorecko/PatchPanda
Self-hostable Docker Compose stack update manager.
And
when you choose to update, PatchPanda edits compose/.env files and runs
docker compose pullanddocker compose up -dfor the target stack. You can also view live log.Discovered in the latest Self Host Weekly:
https://selfh.st/weekly/2025-11-28/
I have not tried it myself tho.
I deploy and update my service similiar to this fantastic guide: https://nickcunningh.am/blog/how-to-automate-version-updates-for-your-self-hosted-docker-containers-with-gitea-renovate-and-komodo
Basically I run Komodo, which pulls a git repo. Renovate opens a PR (and most of the time the changelog is included, so I can quickly check what happened) for new versions. Once merged a webhook fires to tell Komodo to pull the new version.
I really recommend this approach now. Once setup it is very automatic, but not to the point of YOLO-automation like Watchtower and :latest 😅
This seems really interesting. I’ll have to read up on it more and try to wrap my head around it but I’m definitely checking this out. Thank you!!
I don’t want to use automatic updates on self hosted projects but I subscribe on github / gitlab releases in my rss reader (FreshRSS) and update when I want to!
I run changedetection and monitor the samples .yml files projects usually host directly at their git repos
Ah ok cool I’ll check that out. Thanks!!
I have automatic updates through a watchtower fork, so I just leave it alone until it breaks, then I go to the project site to see what changed. This has happened maybe twice in the last couple years.
I use a watchtower fork as well to keep some containers updated but I’m curious how others keep on top of docker-compose.yml files that the project updates over time. As an example, I’ve been using a container for years and noticed today that on the github page they’ve added a section in the compose file for a health check. I never would’ve known that was added if I didn’t stumble upon it due to another issue.
Good projects will have docs associated with the docker/docker compose files.
The way we do it is, any update to the .yaml files will have a corresponding .yaml.Dev associated with it. That way it won’t be overwritten when an update occurs as well as give a recommended setup.
Other than keeping an eye on their changelog or waiting until it breaks, I don’t think you can do anything about that. I do have automatic update, but the config rarely changes from my experience.
That’s kind of what I’ve found but wasn’t sure if I was just missing something. Thanks!
RTFM
This is the kind of attitude that drives people away from open source.
Yes, people should read the manual, but at some point they will have questions, and there are a lot of projects that aren’t clear on certain things. Such as YAML changes.
I cannot recall a single self-hosted software documentation that mentions how to keep the docker config file up to date. Why bother wasting 5 seconds writing such an unhelpful comment
Tell me you don’t read the manual without saying you don’t read the manual.
I can recall a few! Mastodon. Lemmy. PiHole. Penpot. Mealie. Uptime Kuma.
They all mention required steps to upgrade between releases, including what to do to your docker installations and environment variables.
PLENTY of projects make tiny non-breaking changes to the compose files without any mention that users should update the file. For example, adding a section for a container health check. While these can be no big deal for a while over time they can add up to major changes in the config that users may not catch if they are not comparing yml files.
Oh you must mean THE manual. Got it.
You can also interpret it as, “Read their fucking manuals.”
