Renovate bot is the answer. I self host it. Feel free to ask questions
this post was submitted on 06 May 2025
48 points (98.0% liked)
Selfhosted
61512 readers
1358 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
This. Helm charts and renovate. The (frequently) included release notes help ease upgrades. If the charts / apps you deploy publish good release notes, you will get them in the renovate, easing your mind when upgrading.
It's not perfect. Some don't publish release notes, or the release notes only include the chart changes and not app changes. But if provided, there's a link to the source to double check.
Also having something like ArgoCD that allows you to preview chart changes before syncing is very useful.
Wow, thanks for all the great answers so far. As for why not latest:
- Read a lot online and read multiple times it's "bad practice"
- Own experience: had latest on an app which crashed and wouldn't come up again. Got the backup of the persistent volume back and then had the problem that latest at that point is not the same as latest when I spun it up. Actually had no idea which version I was running last and consequently what I would need to pull to fit my backup. In case I have to restore my cluster, this problem is multiplied.
- I run NixOS on everything, so I am clearly biased towards reproducibility.
- I am running Services for family and a fire brigade (nothing mission critical, just support stuff, but still...). Stability is important, as sometimes I do not have the time to immediately react to an issue. I prefer a lazy Sunday morning to update/fix and then leave it alone and stable.
So, probably a combination of latest for low criticality and pinned on critical stuff (e.g. authentication, access, etc.)
It is bad practice because of point 2 and if you have multiple replicas you can probably get different versions running simultaneously (never tried it). Get Rennovate. It creates PRs to increment the version number and it tries to give you the release notes right in the PR.
Just FYI - you're going to spend far, FAR more time and effort reading release notes and manually upgrading containers than you will letting them run :latest and auto-update and fixing the occasional thing when it breaks. Like, it's not even remotely close.
Pinning major versions for certain containers that need specific versions makes sense, or containers that regularly have breaking changes that require you to take steps to upgrade, or absolute mission-critical services that can't handle a little downtime with a failed update a couple times a decade, but for everything else it's a waste of time.
I always use a version tag, but I don't spend any time reading release notes for 95% of my containers. I'll go through and update versions a couple times a year. If something breaks, at least I know that it broke because I updated it and I can troubleshoot then. The main consideration for me is to not accidentally update and then having a surprise problem to deal with.
I generally just use latest for most services. For critical stuff I pin the major version number. Also anything that doesn't gracefully handle major version updates like Postgres and similar.
If something breaks I fix it, or restore from the nightly backup if I can't.
RSS feed of the releases?
Personally I just use latest and forget about it.
I have been using https://newreleases.io/ to keep track of updates, it will send you messages when things get an update. you can change how often
Thanks for the tip! I haven't heard of that and I've been looking for something to keep track of this stuff as well.
maybe this might help you at least a little https://docs.github.com/en/code-security/getting-started/dependabot-quickstart-guide
I use What's up Docker (https://github.com/getwud/wud) for this. It talks to the Docker daemon, is configured with labels. I get notifications when new versions and I can also look at a dashboard that aggregates all the updates and provides links to release notes.
Admittedly, I don't use Kubernetes, so I can't tell you whether What's up Docker supports it. A bunch of docker compose files is enough for me.
It can also update docker compose files with new tags for you, but I'm allergic to auto updates
I use RSS feeds, bump version numbers when a new release is out, git commit/push and the CI does the rest (or I'll run the ansible playbook manually).
I do check the release notes for breaking changes, and sometimes hold back updates for some time (days/weeks) when the release affects a "critical" feature, or when config tweaks are needed, and/or run these against a testing/staging environment first.
For the biggest projects I added the ICS files from endoflife.date
So for example now I will increase version of nextcloud only when my calendar notifies me that it reached EOL (=exits beta status)
For the smaller ones I have the same problem of you, targeting a specific version is not effortless and targeting :latest is not safe like the very useful Borg warehouse that had two consecutive breaking changes in how they manage Cron jobs...
Or even lethal, like Zipline V4 isn't compatible with the Zipline V3 database, and you're supposed to do "export, wipe, import" BEFORE updating. But I was on :latest so... (luckily it was hosting just temporary data and it was easier to just delete everything and start again)
I need something like this but I install bare metal over docker most of the time. As of now I just subscribe to RSS feeds for releases, but I'd like something I don't personally need to remember
I also have several machines at home (all run proxmox) and a VPS
Definitely renovate it and keeping your code in a bit using gotops principles. When I run k8s I used flux to reconcile my reponstate to my clusters.
When using semantic versioning of anything, it's an intention to run that specific version. AKA version pinning or locking. Meaning you DON'T want it automatically updating unless you do it manually.
You especially don't want this happening in a k8s cluster if you intend to run replicas with pulls enabled for obvious reasons.
As for being notified of updates, there are some tools out there for this, but I believe they only check for pulling specific tags, or latest tag. The way container registries work wouldn't make it obvious what exactly you'd want to update, because there is no concept of tag inheritance. This means if a new tag showed up in a repo, you wouldn't know if it's an update to your specific current version of aomething, or just another tag. They don't work like packages in this sense.