To turn on automated fix pull requests safely, check that tests and review rules are in place, start with one category and a few repositories, pick the most cautious strategy, review every pull request by hand for several weeks, and widen the scope only when the results are good.
TL;DR: Treat the switch like a launch, not a setting. Prepare the repositories, start small, watch closely, write down your stop rules, and grow in steps. In Safeguard, Autonomous Remediation ships off and every category is Manual, so you decide when each step happens.
Definition: A rollout plan is a short written plan that says what you will turn on, for whom, for how long, how you will judge it, and what makes you pause.
What should be true before you flip the switch?
A fix pull request is only as safe as the checks around it. Before turning anything on, confirm the basics on the repositories you plan to include.
| Readiness check | Why it matters | How to check quickly |
|---|---|---|
| Automatic tests run on every pull request | Tests catch changes that break behavior | Open a recent pull request and look for check results |
| Required reviews on the main branch | A person must approve before merge | Look at the branch protection settings |
| Code owners named for important files | The right people are asked to review | Look for a CODEOWNERS file |
| A known way to undo a release | You can recover fast if something slips through | Ask who last rolled back a release, and how long it took |
| Locked dependency versions | Builds are repeatable and fixes are visible | Look for a lockfile in the repository |
GitHub documents that administrators can require a number of approving reviews and passing status checks before merging into a protected branch, and that a CODEOWNERS file names people who are asked to review changes to certain files. If these are new to you, read how to configure GitHub branch protection rules first.
A lockfile is a file that records the exact version of every dependency, so every build uses the same ones. If that term is new, see what is a lockfile.
How do you choose a pilot?
Pick repositories that are boring on purpose. A good pilot repository has strong tests, an active team, a low blast radius, and an owner who will actually read pull requests. A bad pilot is the oldest, most fragile system you own, because a failure there teaches you nothing about the tool and a lot about the system.
Aim for one or two repositories, or a small handful if your setup makes that easy. If the people who own them are enthusiastic, even better. Their feedback will shape the wider rollout.
What are the steps, in order?
- Write the goal in one sentence. For example: "Prove that fix pull requests save review time without causing incidents." A clear goal tells you later whether you succeeded.
- Run the readiness checks above. Fix gaps in the pilot repositories, or choose different ones.
- Pick one category. Safeguard has separate Manual or Auto settings for each category. Dependencies is a common first choice because the fixes are small and easy to inspect.
- Choose the most cautious strategy. For vulnerability and dependency fixes, Safeguard's Safest strategy applies backward compatible fixes that should not break existing functionality. Balanced allows minor version updates and patches with minimal breaking changes. Aggressive allows all available fixes, including major version updates. Smart lets AI choose per item based on context, risk, and impact. Start with Safest.
- Turn on the master switch and set the category to Auto. Until the master switch is on, strategy choices are saved but not applied. Do this on a weekday morning when people are around.
- Review every pull request by hand. Do not skim. Check what changed, what the checks say, and whether the explanation makes sense.
- Keep notes. Write down how many pull requests arrived, how many merged, how many you closed, and why.
- Hold a short review at the end of week two and week four. Decide to continue, pause, or widen.
- Widen in steps. Add the next group of repositories, or move the next category from Manual to Auto.
For how a reviewer should read each pull request, see how to review a fix pull request.
What stop rules should you write down?
A stop rule is a promise you make to yourself before emotions get involved. Here are examples that many teams find sensible:
- If any merged fix causes a customer facing problem, pause and review before continuing.
- If more than a small share of pull requests are closed for being wrong or unclear, go back to Manual and find out why.
- If reviewers stop reading the pull requests and begin approving without looking, shrink the volume.
- If the build gets slow or the queue of open pull requests grows past what the team can review in a week, reduce the scope.
Write the exact numbers that fit your team. The point is to decide in advance, calmly.
What does a four week rollout look like?
This is an invented example with invented numbers, shown only to make the plan concrete.
Worked example (invented numbers): A company has 20 repositories. It picks 2 for the pilot and writes a goal: review each fix in under 15 minutes with no incidents.
| Week | What is on | Pull requests in the week | What the team does |
|---|---|---|---|
| 1 | Dependencies set to Auto with Safest, 2 repositories | 5 | Review every pull request by hand and note time spent |
| 2 | Same | 4 | Hold a 20 minute check in, adjust the explanation template |
| 3 | Add 3 repositories | 9 | Keep reviewing by hand, track closed pull requests |
| 4 | Same | 7 | Compare results with the stop rules, decide whether to add the next group |
By the end of the month, in this made up story, the team has seen 25 pull requests, merged 22, closed 3, and has no incidents. The average review time is 11 minutes. The team meets its goal and plans the next group. If instead two merged fixes had broken a release, the stop rule would have paused the plan, and that would also have been a useful result.
What if a fix breaks something anyway?
Sometimes it will. That is why the plan includes undo steps. GitHub documents that reverting a merged pull request creates a new pull request that reverses the original change, and that you need write permission to do it. Practice this once on a test repository so nobody is learning it during an incident. The companion post what to do when an automated fix breaks your build walks through it.
How does Safeguard support this kind of rollout?
Safeguard provides autonomous remediation with fix pull requests as a generally available capability. It is off by default, and every category is set to Manual. That default gives you the quiet starting point this plan needs.
When you are ready, you turn on the master toggle, choose Manual or Auto for each category, and pick a strategy. Fixes arrive as pull requests, so your review rules still apply. Safeguard also offers policies, gates, and guardrails to set rules around what can ship, plus SBOM and dependency scanning to show what you have. An SBOM, or software bill of materials, is a list of every part inside your software.
To see what a scan finds in your own project before you begin, try the free scan at gold.safeguard.sh/scan. For background on why the default is Manual, read why are automated vulnerability fixes off by default.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a finding with a fix available is separated from one without, since only the first can become a fix pull request.
Quick check
How many repositories should I start with?
Start with one or two that have strong tests and an owner who will read every pull request. Add more only after a few weeks of clean results.
Should I turn on every category at once?
No. Each category has its own Manual or Auto setting. Start with one, such as dependencies, and move the others only when you are comfortable.
Do I still review pull requests once automation is on?
Yes. Auto means the fix is prepared for you, not that it merges without anyone looking. Your normal review rules apply.
How do I go back to Manual?
Set the category back to Manual or turn off the master switch. Review any pull requests that are already open and merge or close them on purpose.
Sources
- About protected branches, GitHub Docs, on required reviews and status checks.
- About code owners, GitHub Docs, on CODEOWNERS files.
- Reverting a pull request, GitHub Docs, on undoing a merged change.
Last reviewed: 19 October 2026.
