Roll out in rings. Start with one canary repository, move to a few volunteer teams, then expand to everyone, using one shared configuration. Pause the next ring when failures rise. Switching a bot on for hundreds of repositories at once buries teams in pull requests.
The problem with big bang rollouts
Turning on a bot everywhere creates a flood on day one. Each repository gets a backlog of stale updates, review queues overflow, CI load spikes and teams learn to ignore the bot. Early noise also teaches people the wrong lesson about the tool.
A ring model
| Ring | Scope | Goal |
|---|---|---|
| 0 | One internal repo you own | Test the config and the review path |
| 1 | Three to five volunteer repos | Find problems in different stacks |
| 2 | One business unit | Check support load and CI cost |
| 3 | Everyone else | Finish, with owners named |
Steps
- Write one shared configuration that repositories extend, so changes land in one place. Most bots support a shared preset or a template.
- Set conservative defaults: a low open pull request limit, a weekly schedule, grouped patch and minor updates, majors separate. The limit defaults documented by common tools are 5 and 10, so lower is a deliberate choice.
- Keep auto-merge off in the first rings. Measure first.
- In each ring, track: pull requests opened, merged unchanged, merged with edits, closed unmerged, and median days to merge.
- Move to the next ring when the merge rate is stable for two weeks and support questions have a written answer.
- Handle backlogs with a one time catch-up, not by raising limits.
- Name an owner per repository for dependency pull requests. Unowned repositories collect pull requests forever.
Signals to pause
- Failure rate on bot pull requests rises sharply.
- Median time to merge grows each week.
- CI queue times are noticeably longer.
- Teams ask to opt out. Find out why before you refuse.
Policy on top of the bot
Pair the rollout with a short policy: how fast security fixes must land, which update types need human review, and who may approve exceptions. An update program without these rules becomes an argument in every pull request.
Keep an inventory
You cannot manage what you cannot list. An up to date inventory of repositories, manifests and lockfiles shows which ones the bot has not reached yet.
Try it yourself
Click through it at your own pace, or open it full screen. See how a pull request gate checks a change before merge, the same control you can apply to bot pull requests in each ring.
Quick check
Which repo should be the canary?
One you own, with decent tests and a team that will give feedback. Not your most critical service.
When can we add auto-merge?
After the merge rate and failure rate are stable, and only for update types where your tests are trustworthy. Many teams never enable it for majors.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
