How do you merge dependency update bot configs after two teams combine?

To merge update bot configurations, compare schedules, grouping, labels, and automerge rules from both teams, agree on one shared base configuration, publish it in a central repository, and have each repository extend it with only small local overrides. Roll the change out gradually and watch pull request volume.

Compare what each setup does

Open a sample of configuration files from each side and write down the differences in:

• How often the bot runs
• Which updates it groups and which it opens separately
• Which updates may merge automatically, if any
• Labels, reviewers, and commit message styles
• How it treats major, minor, and patch versions
• Which packages are ignored or pinned, and why

Pinned or ignored packages deserve special attention. They are often leftovers from an old incident, and the reason is not always written down.

Agree on a shared base

Choose defaults that fit both teams. A sensible base usually includes a sane schedule to avoid constant noise, grouping of related minor and patch updates, security updates handled on a faster path, and a clear rule for what may auto merge.

Make automerge conservative at the start. Before allowing it, read should I turn on Dependabot auto merge for dependency updates and reduce dependency update PR noise: grouping, schedules, automerge.

Publish it once, extend it everywhere

Some update tools support shared presets. Renovate's documentation, for instance, describes an extends array in a repository config and notes that presets can be nested and are usually hosted in repositories on the same platform as Renovate is running against. It also warns that npm hosted presets are deprecated. Check your own tool's current documentation before relying on a feature.

The pattern is the same for any tool that supports it:

1. Create a central repository for the shared base.
2. Version it, for example with tags, so repositories can pin to a release.
3. In each repository, extend the shared base and add only local overrides.
4. Review overrides regularly, since each one is a place where the policy differs.

Keep policy and bot in step

The bot's behavior should match the merged dependency policy. If the policy says critical fixes must land within a stated time, the security update path should open pull requests promptly. If the policy forbids a version range, the bot should not propose it. After you publish the shared base, run the policy dry run and confirm that bot pull requests pass the gate.

Roll out gradually

Start with one repository from each team. Watch for a spike in open pull requests, since merging two schedules can double the volume for a week. Adjust grouping before you widen the rollout.

Name an owner for the preset

Changes to the shared base affect every repository. Use review and a changelog, as you would for the policy itself. See who owns scanner config, central team or each repo.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how an available fix is surfaced as an update, the starting point for any bot rule.

Safeguard can propose fix pull requests for vulnerable dependencies. They are off by default, and every category starts on Manual, so a team chooses what, if anything, to automate.

Quick check

Sources

• Renovate documentation, Shareable config presets

Last reviewed: 19 October 2026.