Feedback wanted: what stops you keeping Renovate updated?

[jamietanna]

As we receive feedback from our community, generally through Request Help, we pay attention to the versions of Renovate y'all are using when self-hosting Renovate.

We'd love to hear why you may be using older versions of Renovate.

In-scope:

• The frequency of Renovate updates
• The frequency of major version releases in Renovate
• Organisation difficulties with upgrading
  • (Share as much or as little as possible, but it would be useful to understand a little of why)
• Time constraints
  • I.e. "my team doesn't have time to keep this updated alongside everything else"
• Apathy/not feeling there's a need to keep updated
• Not knowing what it's worth upgrading for
• Not aware of security advisories or risks of using older Renovate versions

Out-of-scope:

• Not having a good dependency management tool to update your Renovate version (😜)

Other inputs are also very welcome - we're trying to get an understanding of what leads to this, and if there's anything we can to do improve the situation

Issues captured out of the discussion:

• docs: add an example / preset for "keeping Renovate updated" #41855

[chrede88]

I'm only speculating here as I try to keep renovate up-to-date, but I think the very high release cadence can end up deterring some users as the amount of time needed to keep up with the new releases can become to high.

[Peej11]

I try to keep Renovate (and everything else) as up to date as possible by using it. It's obviously very helpful for that purpose. The high release cadence is really the only sticking point but there are some ways to workaround it. Up until maybe a week or so ago I only did major/minor with no patch or sha pinning. This worked well and I'd only get an update every day or two normally. I recently updated all images to pin them with hashes so now I'm back to updating several times a day most days. I keep my sanity here now by just allowing it to automerge itself for patch and minor releases, but commit history still has a lot of activity to sort through if I need to go back and find something.

[viceice]

I usually update daily and sometimes on demand if I need a fix

[LouisXhaferi]

Not strictly keeping us from updating, but a byproduct of updating: The high release cadence is in the way when trying to find out what actually changed since our last update. Usually this is OK, since Renovate tends to just work ™️ , but especially if anything goes wrong, it's a real pain to skim through potentially pages of release notes to possibly find a cause for the issues.

So maybe the problem isn't the high release cadence itself, but rather low visibility to what has changed recently on a high level.

I will also acknowledge that in the last few weeks this was worse than usually, but I spent way too long trying to debug stuff that was broken in 43.150.0 and potentially fixed in some unreleased version since.

[jamietanna]

Interesting and fair - out of interest, have you seen octochangelog before?

For example, I use it when reviewing the changelog when updating the Mend-hosted Renovate - on Renovate PRs we receive i.e.

43.198.0 → 43.202.1 ([changelog](https://octochangelog.com/compare?repo=renovatebot%2Frenovate&from=43.198.0&to=43.202.1))

Octochangelog then helps group the changes (based on Renovate's changelog) into features/bugs/etc

Worth seeing if that helps / if there are any other actionable areas we could look at, especially considering the Releases are autogenerated from the merged PRs

[LouisXhaferi]

That's definitely helpful!

[jamietanna]

Nice! I've added it for config:recommended users in #43712

[ggjulio]

Using renovate operator with argocd + renovate.

Upgrading renovate itself is as simple as merging a PR with the whole changelog as description. No issue whatsoever keeping it up to date.
However it's a little bit noisy getting +3 releases a day.

[viceice]

I'm using a daily schedule, so just one PR per day

[bmillwood]

A bit off-topic because I do keep Renovate updated, but I might as well take this opportunity to say what I find difficult about it:

• I use the GitHub Action. The changelogs I get in my Renovate PRs updating itself are (perhaps ironically) some of the least useful I get. e.g. something like https://github.com/renovatebot/github-action/releases/tag/v46.1.12 is purely a list of dependency upgrades, without telling me what behaviour change that might imply. If I want to understand what actually changed, I'd need to look into the changelogs of the underlying docker image itself.
• Partly as a consequence of the above issue, I switched to pinning the version parameter and using Renovate to update that. But those changelogs are still quite heavy with stuff that doesn't affect me at all! e.g. I don't need to read any of your documentation changes or your own dependency upgrades.
• On my personal repos, I update every week or two. This has already been long enough that on occasion I'll get the "truncated due to platform limits" message (e.g. here). (NB. that PR has already been edited to cut out some stuff, so it may not be very close to the limit now.)

So my asks for making Renovate upgrades more convenient for me would be "make changelogs more informative and easier to read", e.g.

• maybe stop including things that aren't relevant for people upgrading,
• consider e.g. deduplicating changelog entries when one dependency is upgraded twice,
• perhaps harder: the github action changelog could "inline" changelogs from the Renovate docker image?

[jamietanna]

perhaps harder: the github action changelog could "inline" changelogs from the Renovate docker image?

I think as you've noticed (related: renovatebot/github-action#1035 (comment)) the GitHub Action, by default, doesn't pin the Renovate CLI version, so that's why you don't actually see much insight in the changelogs for the Action itself

[jamietanna]

maybe stop including things that aren't relevant for people upgrading,

This is an interesting one - what sort of things are relevant to you when you upgrade? And what sort of things aren't?

(This is a difficult one - lots of folks have different things they use and care about)> maybe stop including things that aren't relevant for people upgrading,

[bmillwood]

I think as you've noticed (related: renovatebot/github-action#1035 (comment)) the GitHub Action, by default, doesn't pin the Renovate CLI version

I hadn't noticed! But that makes sense.

This is an interesting one - what sort of things are relevant to you when you upgrade? And what sort of things aren't?

The easiest wins are updates to documentation or Renovate's own test suite or build system. Stuff that doesn't at all change what code runs when I run Renovate.

After that is a question of, which changes do change what code I'm running, but not in a way that affects the behaviour I observe? Or going further, what changes do I need to actually react to?

In principle dependency upgrades could affect my experience, but I've never known it to happen, so I skip over those when I'm reading changelogs. I also skip over updates to components I don't use: it's helpful that many are prefixed with "manager/whatever".

But the more I think about it, perhaps the pragmatic choice for me is actually to blind-merge everything with the possible exception of major version bumps, and only look at the changelog in retrospect if something goes wrong... in which case maybe you putting effort into improving any of these things would be wasted on me :)

[bmillwood]

btw I don't know if it's new that my PRs link to e.g. https://octochangelog.com/compare?repo=renovatebot%2Frenovate&from=44.82.0&to=44.115.7 , maybe it's been there the whole time, but I only recently noticed it and it does help me ignore documentation and testing updates :)

[jamietanna]

We added the octochangelog.com link a couple of months ago (#43712) to all Renovate PRs bumping Renovate, as I use that view for my reviews of the changelogs, when I'm deciding whether to upgrade all Mend-hosted applications :)

We're also experimenting with more of a Renovate-specific changelog breakdown for what may be user facing and isn't i.e. see https://github.com/mend/renovate-ce-ee/releases/download/15.6.0/44.103.0.md, via Mend Renovate Self-Hosted's 15.6.0 release

The easiest wins are updates to documentation or Renovate's own test suite or build system. Stuff that doesn't at all change what code runs when I run Renovate.

Yep, fair

or build system

Interestingly, the Semantic Commit build(deps)s are actually for dependencies that are user-facing - chore(deps) can be ignored

After that is a question of, which changes _do change what code I'm running, but not in a way that affects the behaviour I observe? Or going further, what changes do I need to actually react to?

And yep, this is also a difficult one because we don't know exactly what features you're using and even if we did, can a one-liner in the changelog cover that appropriately? It's a tough one we're trying to work through a better solution for!

[RonaldPhilipsen]

Working in a mostly airgapped environment means I have to manually upgrade renovate every once in a while, ghcr.io doesn't actually return all releases when querying the API through a mirror, which means renovate never sees new versions of itself.

[pjonsson-rise]

I'm not sure if I qualify for this thread since I'm running a Renovate from this month, but I'll chime in anyways.

Renovate updates was one of the first thing I throttled once I got Renovate working because of the cascade of pull requests updating the Docker image. Right now my schedule is every 2 weeks, but I'm such a recent user that I can't tell if that is a good choice. If there is a way so I immediately got security updates and a monthly update otherwise, I think that would be fine for me most of the time. There will be exceptions to this, as an example, when you get the release age support for ghcr.io datasource released I don't want to wait for a whole month.

When it comes to changelogs, my interest is roughly

1. Security fixes
2. "Features" (might be something I wasn't aware of and should start using)
3. Bug fixes (always uninteresting until something breaks, and then it's the most important thing in the world)

in that order, and the rest is just noise for me. I can't actually tell from a quick skim of the changelog, but I definitely don't care about internal things relating to developing Renovate itself, for example test updates and version bumps of CI actions, even if I understand that is important for the Renovate developers.

From my limited experience (and without thousands of repositories to keep updated), I don't think it's particularly hard to stay updated for those who are self-hosting on GitHub, it's just a regex manager + VERSION variable that Renovate can update:

env:
  # renovate: datasource=docker depName=renovatebot/renovate packageName=ghcr.io/renovatebot/renovate
  RENOVATE_VERSION: 44.104.2@sha256:c87b1c55ab98286dad9df0c1d84ebe1fbe2a805a68d48dd7a6d577709bf951a7

...
        uses: renovatebot/github-action@dcfba84a42d1b5d5e49bf131b1bf53511851a123
 # v46.3.1
        with:
          renovate-version: ${{ env.RENOVATE_VERSION }}

The main thing I see that could make that even easier would be if the preset regex manager tolerated the sha256-part of the version specifier.

[jamietanna]

Aside: the GitHub Action doesn't even need you to use a Custom Manager: https://docs.renovatebot.com/modules/manager/github-actions/#updating-with-values-in-github-actions will automagically update it for you

So you can use renovate-image to pin the image itself (with digest pin), and Renovate will update it

[pjonsson-rise]

After reading your response, I first tried setting renovate-image to
ghcr.io/renovatebot/renovate:44.104.2@sha256:c87b1c55ab98286dad9df0c1d84ebe1fbe2a805a68d48dd7a6d577709bf951a7, but then the action does /usr/bin/docker run -t --rm ghcr.io/renovatebot/renovate:44.104.2@sha256:c87b1c55ab98286dad9df0c1d84ebe1fbe2a805a68d48dd7a6d577709bf951a7:44 --version and that fails because of the ending :44. My next guess was to drop the version and just use the sha256, so I set it to ghcr.io/renovatebot/renovate@sha256:c87b1c55ab98286dad9df0c1d84ebe1fbe2a805a68d48dd7a6d577709bf951a7, but that fails for the same reason.

My third guess was that you meant to inline the variable, so renovate-version should be 44.104.2@sha256:c87b1c55ab98286dad9df0c1d84ebe1fbe2a805a68d48dd7a6d577709bf951a7. That makes the action run, and after merging that change the dashboard updated, but the detected dependencies in the dashboard doesn't show the -> [Updates: ..] part for the Renovate image. Looking at the Renovate log, there's the usual 405 Method not allowed when trying to HEAD the image with a hash baked into the URL.

Details

DEBUG: HEAD https://ghcr.io/v2/renovatebot/renovate/manifests/44.104.2@sha256:c87b1c55ab98286dad9df0c1d84ebe1fbe2a805a68d48dd7a6d577709bf951a7 = (code=ERR_NON_2XX_3XX_RESPONSE, statusCode=405 retryCount=0, duration=5) (repository=DigitalEarthSweden/.github)
DEBUG: Unknown Error looking up docker manifest (repository=DigitalEarthSweden/.github)
       "err": {
         "name": "HTTPError",
         "code": "ERR_NON_2XX_3XX_RESPONSE",
         "timings": {
           "start": 1790329463662,
           "socket": 1790329463662,
           "lookup": 1790329463662,
           "connect": 1790329463662,
           "secureConnect": 1790329463662,
           "upload": 1790329463665,
           "response": 1790329463667,
           "end": 1790329463667,
           "phases": {
             "wait": 0,
             "dns": 2,
             "tcp": 3,
             "tls": 10,
             "request": 3,
             "firstByte": 2,
             "download": 0,
             "total": 5
           }
         },
         "options": {
           "headers": {
             "user-agent": "Renovate/44.104.2 (https://github.com/renovatebot/renovate)",
             "authorization": "***********",
             "accept": "application/vnd.docker.distribution.manifest.list.v2+json, application/vnd.docker.distribution.manifest.v2+json, application/vnd.oci.image.manifest.v1+json, application/vnd.oci.image.index.v1+json",
             "accept-encoding": "gzip, deflate, br, zstd"
           },
           "url": "https://ghcr.io/v2/renovatebot/renovate/manifests/44.104.2@sha256:c87b1c55ab98286dad9df0c1d84ebe1fbe2a805a68d48dd7a6d577709bf951a7",
           "hostType": "docker",
           "username": "",
           "password": "",
           "method": "HEAD",
           "http2": false
         },
         "message": "Request failed with status code 405 (Method Not Allowed): HEAD https://**redacted**@sha256:c87b1c55ab98286dad9df0c1d84ebe1fbe2a805a68d48dd7a6d577709bf951a7",
         "response": {
           "statusCode": 405,
           "statusMessage": "Method Not Allowed",
           "body": "",
           "headers": {
             "content-type": "application/json",
             "docker-distribution-api-version": "registry/2.0",
             "strict-transport-security": "max-age=63072000; includeSubDomains; preload",
             "date": "Fri, 25 Sep 2026 09:44:23 GMT",
             "content-length": "78",
             "x-github-request-id": "2040:2B3F28:4F81D1:5BA25F:6AB64277",
             "x-github-edge-region": "iad"
           },
           "httpVersion": "1.1",
           "retryCount": 0
         }
       },

I'm sure it's just me being dense, but could you please spell out the details for what exactly I'm supposed to put in the with: block for getting the Renovate image pinned by hash and having Renovate automatically update it?

[jamietanna]

Ooh good spot - not you being dense, but me not realising it isn't technically supported (until renovatebot/github-action#1082 is merged)