Dependency fixes can be automated safely if you keep three things in place: tests you trust, a rollback you have practised, and a named human owner. Start with every category on manual approval. Below are ten short answers, each linked to a longer post.
1. Should the bot merge on its own?
Not at first. Let it open PRs, review them, and promote a category to auto-merge only after a trial. GitHub says auto-merge merges a PR after all required reviews and status checks pass, so the safety lives in what you require. See shadow mode for automated remediation: run report only first.
2. Is grouping a good idea?
Often, for low risk updates. Groups reduce the number of PRs but make failures harder to trace. Keep security fixes in their own group. See keep security fix PRs in their own group.
3. Which tests must pass?
The ones you would trust to fail if the package misbehaved, as required checks. Also know what tests miss. See what a test gate on a fix PR cannot catch.
4. Do I need a canary?
For services with real traffic, a gradual rollout with a watcher is cheap insurance. Google's SRE Workbook describes canarying as a way to find defects with minimal impact on the service. See what to watch after merging a dependency fix.
5. How do I roll back?
Redeploy the previous build, then revert the change in the repository. Check the preconditions first. See is your rollback ready before auto-merge.
6. Which merge method is easiest to revert?
Squash and merge gives one commit to revert. See squash or merge commit for a dependency fix PR.
7. Who owns the outcome?
The service owner, never the bot. See who is on call when an auto-merged fix breaks production.
8. How fast should humans approve?
Set targets by urgency lane. See how quickly should a person approve a dependency fix PR.
9. What should always wait for a person?
Major versions, critical paths, thin tests, data layers and unowned services. See when should a dependency fix wait for a human.
10. Where do I begin?
Pick one internal repository, run the bot with all PRs manual, and measure. See staged rollout of dependency updates across many repos.
A starting checklist
- Every category on manual approval.
- Required checks set and understood.
- Owners named per repository.
- A rollback practised once.
- A pause switch known to the team.
- A written note to developers.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Is full automation ever appropriate?
For some low risk categories, with good tests, an owner and a practised rollback, after a trial. Treat it as a decision you review, not a default.
What is the first thing to do this week?
Choose one low risk repository, turn on PRs with manual approval, and start the log of what happens.
Sources
Last reviewed: 19 October 2026.
