Keeping .yaml files up to date...

Submitted ⁨⁨2⁩ ⁨days⁩ ago⁩ by ⁨neonrain@piefed.social⁩ to ⁨selfhosted@lemmy.world⁩

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!

source

Comments

Sort:hotnew top

dbkblk@lemmy.world ⁨2⁩ ⁨days⁩ ago
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!

source
- raldone01@lemmy.world ⁨2⁩ ⁨days⁩ ago
  Those damn pre-release notifications though!!!
  
  source
  - BlueBockser@programming.dev ⁨15⁩ ⁨hours⁩ ago
    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!
    
    source
  - uninvitedguest@piefed.ca ⁨1⁩ ⁨day⁩ ago
    I use email rules to filter those ones out. Linux server containers are especially egregious.
    
    source
- keksbaecker@lemmy.world ⁨2⁩ ⁨days⁩ ago
  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.
  
  source
themachine@lemmy.world ⁨2⁩ ⁨days⁩ ago
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.

source
- Appoxo@lemmy.dbzer0.com ⁨1⁩ ⁨day⁩ ago
  Same here.
  Read deployment documentation, configure compose to my standards, deploy, update where necessary to align with the update (e.g. remove an environment variable.
  
  source
frongt@lemmy.zip ⁨2⁩ ⁨days⁩ ago
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.

source
- neonrain@piefed.social ⁨2⁩ ⁨days⁩ ago
  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.
  
  source
- Appoxo@lemmy.dbzer0.com ⁨1⁩ ⁨day⁩ ago
  Hope 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))
  
  source
  - shiftymccool@piefed.ca ⁨1⁩ ⁨day⁩ ago
    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
    
    source
    -> View More Comments
IanTwenty@piefed.social ⁨2⁩ ⁨days⁩ ago
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.

source
- irmadlad@lemmy.world ⁨1⁩ ⁨day⁩ ago
  
  PatchPanda
  
  I too saw PatchPanda on selfh.st and it is on my watch list. The only thing holding me back is that it isn’t out of beta yet. So, I’m waiting on other selfhosters to plow that field before I deploy. It does look like it would solve a lot of problems tho.
  
  source
- neonrain@piefed.social ⁨2⁩ ⁨days⁩ ago
  Hmmm I’ve heard of it but haven’t tried it. I’ll dip my toe, thanks!
  
  source
eskuero@lemmy.fromshado.ws ⁨2⁩ ⁨days⁩ ago
I run changedetection and monitor the samples .yml files projects usually host directly at their git repos

source
- neonrain@piefed.social ⁨2⁩ ⁨days⁩ ago
  Ah ok cool I’ll check that out. Thanks!!
  
  source
Object@sh.itjust.works ⁨2⁩ ⁨days⁩ ago
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.

source
- neonrain@piefed.social ⁨2⁩ ⁨days⁩ ago
  That’s kind of what I’ve found but wasn’t sure if I was just missing something. Thanks!
  
  source
shnizmuffin@lemmy.inbutts.lol ⁨2⁩ ⁨days⁩ ago
RTFM

source
- lka1988@lemmy.dbzer0.com ⁨2⁩ ⁨days⁩ ago
  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 project that do not document YAML changes.
  
  source
- Nawor3565@lemmy.blahaj.zone ⁨2⁩ ⁨days⁩ ago
  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
  
  source
  - shnizmuffin@lemmy.inbutts.lol ⁨2⁩ ⁨days⁩ ago
    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.
    
    source
    -> View More Comments
- neonrain@piefed.social ⁨2⁩ ⁨days⁩ ago
  Oh you must mean THE manual. Got it.
  
  source
  - shnizmuffin@lemmy.inbutts.lol ⁨2⁩ ⁨days⁩ ago
    You can also interpret it as, “Read their fucking manuals.”
    
    source
Mora@pawb.social ⁨2⁩ ⁨days⁩ ago
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 😅

source
- mal3oon@lemmy.world ⁨2⁩ ⁨days⁩ ago
  Genuine question, is there any benefit to docker over podman?
  
  source
  - Mora@pawb.social ⁨2⁩ ⁨days⁩ ago
    Not that I am aware of. Komodo should be compatible with podman as well.
    
    source
- neonrain@piefed.social ⁨2⁩ ⁨days⁩ ago
  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!!
  
  source
mesamunefire@piefed.social ⁨2⁩ ⁨days⁩ ago
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.

source
nfreak@lemmy.ml ⁨1⁩ ⁨day⁩ ago
I 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.

source