neonrainKeeping .yaml files up to date...
https://piefed.social/c/selfhosted/p/1519723/keeping-yaml-files-up-to-date
frongtI 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.
AppoxoHope you have backups.
Broke my neck a few times (I currently am waiting out the jellyfin patches and stay on 10.10.7 (i think))
Broke my neck a few times (I currently am waiting out the jellyfin patches and stay on 10.10.7 (i think))
Easy, reliable backups are key. I’ve used komodo with automatic updates for over a year and watchtower before that for a couple more. I’ve only had one issue when Nginx Proxy Manager had a release that deleted all of its own data. Didn’t take long to realize that the services were still up and what the problem was. Restored the missing data from Proxmox backups, pinned the Nginx version for a while, then turned auto backup on again. I’ll stick to this until checking updates is less work than fixing the occasional problem
Just a few days ago, my docker host upgraded the docker engine from 28 to 29.
Woke up to 10 notifications from my uptime monitoring that they are offline.
Funny thing is: The external monitor showed they are down. The internal monitor showed no issues.
But after I went through with the long procrastinated upgrade from debian 11 to debian 13, migrating the data and doing nothing to the compose files, all services worked without any issue.
I don’t know what my old host did or did not but now it works, I guess? Not complaining but the whole routing thing is a bit beyond me
I don’t want to use automatic updates on self hosted projects but I suscribe on github / gitlab releases on my rss flux and update when I want to!
Thank you for this idea. I wasn’t aware, that you can subscribe to an rss feed for releases on gitlab/github.
I think that I will follow your approach.
Those damn pre-release notifications though!!! (Githubs fault for not implementing filtering)
I use email rules to filter those ones out. Linux server containers are especially egregious.
If you also use FreshRSS, you can configure filters to automatically mark new articles as read (e.g.
!intitle:‘beta’). Since I only view unread articles, that effectively deletes them and I never have to see them!
shnizmuffinYou can also interpret it as, “Read their fucking manuals.”
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.
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.
mesa
EskueroI run changedetection and monitor the samples .yml files projects usually host directly at their git repos
I deploy and update my service similiar to this fantastic guide: nickcunningh.am/…/how-to-automate-version-updates…
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 😅
How To: Automate version updates for your self-hosted Docker containers with Gitea, Renovate, and Komodo
In this guide I will go over how to automatically search for and be notified of updates for container images every night using Renovate, apply those updates by merging pull requests for them in Gitea, and automatically redeploy the updated containers using Komodo.
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 pull and docker compose up -d for 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.
irmadladI 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.
nfreakI set this up a while back (and recently moved to Forgejo, see the update note at the beginning of the article):
nickcunningh.am/…/how-to-automate-version-updates…
Probably a tad overkill honestly but it works amazingly well, and turns every potential upgrade into an approval process so nothing will update when you don’t want it to.
How To: Automate version updates for your self-hosted Docker containers with Gitea, Renovate, and Komodo
In this guide I will go over how to automatically search for and be notified of updates for container images every night using Renovate, apply those updates by merging pull requests for them in Gitea, and automatically redeploy the updated containers using Komodo.