Feedback wanted: Renovate's monorepo support

[jamietanna]

We (the Renovate maintainers) are seeking community feedback on how Renovate makes updates to monorepos.

We're looking to understand:

• how you're using Renovate
• what package ecosystems you're using
• what difficulties you find with working on a large monorepo
• what workarounds you've put in place for these, if any
• what you find works well with Renovate's monorepo functionality?
• how long does Renovate take to run against the monorepo? (look for the Repository finished log message at the end of the run)

In-scope:

• Users of Git repos which are a monorepo (at whatever scale you're using them)
• Ideally multi-team monorepos
• Ideally multi-language/multi-tooling monorepos
  • Which is most likely, but it's worth being explicit!

Out-of-scope:

• How Renovate supports PR updates to external monorepos i.e. via group:monorepos

Template:

Our monorepo requires:

- [ ] Dependencies (i.e. `node`, `github.com/google/uuid`) <!-- delete as appropriate --> **must be**/**do not have to be** in-sync across all modules in the monorepo
- [ ] Human review for all dependency updates
- [ ] Specific monorepo tooling that Renovate <!-- delete as appropriate --> **does**/**does not** support

I am a (select multiple if appropriate):

- [ ] user
- [ ] person in a security-focussed role
- [ ] person in a legal-focussed role
- [ ] self-hosted administrator

<!-- Ideally, run `jq '.config | to_entries | map({manager: .key, total: ([.value[].deps | length] | add)})'` against the `packageFiles with updates` log line (Co-authored-by: Claude Sonnet 4.5 (GitHub Copilot)) -->
Package ecosystems we're using: <!-- does not need to be exhaustive, but it's good to have a rough idea of what you're using -->

Number of branches we manage: <!-- this will be 1, or the number of branches matched by https://docs.renovatebot.com/configuration-options/#basebranchpatterns -->

Positives of Renovate's monorepo support:

- <!-- add as appropriate -->

Negatives of Renovate's monorepo support:

- <!-- add as appropriate -->

Workarounds / config hacks we've found to work really well:

- <!-- add as appropriate -->

Length of last Renovate run: <!-- look for the `Repository finished` log message at the end of the run -->

Additional feedback:

[izorg]

Our monorepo requires:

• Dependencies (i.e. node, github.com/google/uuid) must be in-sync across all modules in the monorepo
• Human review for all dependency updates

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role
• self-hosted administrator

Package ecosystems we're using: npm , docker, github-actions

Number of branches we manage: 1

Positives of Renovate's monorepo support:

Works perfect

Length of last Renovate run: 58 s

Additional feedback:

Thank you very much for your effort

[Kakadus]

I have basically the same requirements / experience here. Renovate works okay-ish for us, but we run into #40474 with our npm monorepo.

Our monorepo requires:

• Dependencies (i.e. node, github.com/google/uuid) must be in-sync across all modules in the monorepo
• Human review for all dependency updates

I am a (select multiple if appropriate):

• user
• person in a security-focussed role
• person in a legal-focussed role

Package ecosystems we're using: npm, docker, github-actions

Number of branches we manage: 1

Positives of Renovate's monorepo support:

• works okay-ish. We get some updates

Negatives of Renovate's monorepo support:

• some packages aren't updated. Manual intervention needed.
• monorepo packages are not able to be looked up by renovate (Failed to look up npm package @workspace/package: no-result). We explicitly ignore those packages.

Length of last Renovate run: 1m 18s

Thanks a lot.

[lauraseidler]

Our monorepo requires:

• Dependencies must be in-sync across all modules in the monorepo
• Specific monorepo tooling that Renovate does not fully support out of the box (Go workspaces — see below)

I am a:

• user
• self-hosted administrator

Package ecosystems we're using: npm (60+ Yarn workspaces), Go (go.work with 60+ modules), PyPI (Poetry), Docker, GitHub Actions

Number of branches we manage: 1

---

Positives of Renovate's monorepo support:

• Caching: with the cache persisted to a long-term volume (PV in Kubernetes) keeps warm-cache run times manageable. Cold re-extraction of the full monorepo every run blows past our job deadline.

---

Negatives of Renovate's monorepo support:

• Go workspace: artifact update notices exceed GitHub's comment size limit. See Go workspace artifact update notices exceed GitHub's 65,536-char comment limit; 422 classified as external-host-error aborts entire run #45434

• Run times exceed GitHub App token lifetime. Even with a persistent repo cache, a full run takes well over an hour. Some individual Go dependency updates (particularly those affecting many workspace modules) take 20–30 minutes on their own. GitHub App installation tokens expire after 1 hour, causing authentication failures mid-run. The feature request for Renovate to refresh tokens natively was declined. We run a custom patch that reads a refreshed token from a Kubernetes Secret volume once per minute and updates host rules and the git remote URL.

• Package-rules evaluation performance. See perf(package-rules): avoid re-cloning invariant packageRules array on every rule match in applyPackageRules #44459

---

Workarounds / config hacks we've found to work really well:

• Custom postUpgradeTasks running a workspace-wide tidy script to keep all go.sum files in sync:

  {
    "matchManagers": ["gomod"],
    "postUpgradeTasks": {
      "commands": ["bash scripts/update-go-mods.sh"],
      "fileFilters": ["**/go.mod", "**/go.sum"],
      "executionMode": "branch"
    }
  }

• Persistent PVC for RENOVATE_BASE_DIR to avoid cold extraction on every run.
• Custom token-refresh patch that reads from a Kubernetes Secret volume once per minute to allow runs to go on past an hour
• Local backport of perf(package-rules): avoid re-cloning invariant packageRules array on every rule match #44781 (package-rules deep-clone fix) to reduce extraction CPU overhead.

Length of last Renovate run: ~3h+ (last run ended early due to the 422 abort described above; a full successful run would be significantly longer, as individual Go dependency updates affecting many workspace modules can each take 20–30 minutes)

[jamietanna]

@lauraseidler thanks for sharing!

Regarding the GitHub App token lifetime, we'd be interested in seeing how you ended up doing this, if you'd mind sharing?

(There's a number of reasons we've not done this in the past, and why we're hesitant to commit to doing it - it's an ongoing discussion I can get into more at a later point)

To confirm, are you using both Repo Cache (repositoryCache) and Package Cache (redisUrl)?

Also I thought your name was familiar, #38992 :)

[jamietanna]

If you're also able to take a look at the Open Telemetry instrumentation (and ideally share a report with me, privately), that'd be a good area to look at improvements.

Given the artifact updating (i.e. with Go modules) there may be some things there that could have some external toolchain improvements, too

[lauraseidler]

@jamietanna we are injecting a token refresh into findMatchingRule - I'm attaching the full patch, targeting the current renovate dist bundle. We run patch -p1 -d /usr/local/renovate < /tmp/renovate-token-refresh.patch as part of our docker build, based on the official renovate image. The token comes from a k8s secret mounted as a volume at the configured path that is externally refreshed every 15 minutes.

Yes, we are both using the repo cache and the package cache. I had forgotten about that issue, we kinda deprioritized getting this to work, but it came back up lately. We've made some optimizations since then, but still not really where we want to be.

I'm going to take a look at the otel instrumentation, should be doable, let me know how I can share a report with you privately :)

[jamietanna]

Nice! Drop me an email at jamie.tanna@mend.io - https://docs.renovatebot.com/opentelemetry/#file-exporter may be most useful for this :)