Auto-merge for dependency updates makes sense on paper. Your CI passes. The change is a patch bump. The CVE is fixed. Why require human review? The answer depends almost entirely on how precisely you've defined "this PR is safe to auto-merge." Imprecise definitions lead to production incidents. Precise definitions lead to PRs that resolve themselves without anyone's time.
Repohelm opens PRs automatically. Whether those PRs auto-merge is controlled by a separate eligibility check that runs at merge time, not at PR creation time. This post explains the model and the specific gates we evaluate.
Why auto-merge eligibility is evaluated at merge time, not PR creation
The conditions that make a PR safe to auto-merge can change between when the PR is opened and when it's ready to merge. CI might be running a suite that wasn't running when Repohelm first scanned the repo. Branch protection requirements might have changed. Another PR touching the same dependency might have been opened by a developer. A new CVE might have been published against the target version after Repohelm opened the PR.
If auto-merge eligibility is computed at PR creation time and baked into the PR as a label or flag, those conditions are frozen. The PR might auto-merge into a state that's no longer clean.
We evaluate auto-merge eligibility immediately before attempting to merge. The evaluation reads the live state of the PR, the repo's branch protection rules, and the current CVE advisory databases. If anything has changed that changes the eligibility decision, the PR holds for review instead of merging.
The eligibility checklist
These are the checks we run before allowing an auto-merge, in order of how often they fail:
All required CI checks pass. This sounds obvious, but there are failure modes. If a new required check was added to branch protection rules after the PR was opened, it may not have run yet. We check the actual required status checks list from the repo's branch protection configuration, not just whether any CI checks are green.
No merge conflicts. A dependency PR that was clean when opened can develop conflicts if another PR has already bumped the same dependency to a different version. We re-run the merge conflict check before auto-merging, not just at PR creation.
semver change is within the allowed range. Repohelm's policy configuration specifies what semver ranges are eligible for auto-merge. The strictest configuration allows only patch bumps (for example, 1.2.3 to 1.2.4) where the minor and major version don't change. Teams can expand this to include minor version bumps if they trust the package's changelog and test coverage. Major version bumps are never auto-merged by default because they may include breaking changes that CI doesn't catch.
No open PRs for the same package from another source. If a developer has manually opened a PR to update the same dependency to a different version, Repohelm holds its auto-merge until the conflict is resolved. Two PRs merging to different versions of the same package against the same branch is a recipe for a confusing history and possible lockfile corruption.
The target version is not itself flagged with a new CVE. This is the edge case that justifies evaluating CVE advisories at merge time rather than only at PR creation. A patch release that wasn't in the NVD or GitHub Advisory Database when Repohelm opened the PR might have had a CVE published against it since then. We check the advisory databases again immediately before merging. If the target version itself has a new high or critical CVE, we stop the auto-merge and flag the PR for review.
The repo hasn't been placed in a freeze state. Teams can configure a merge freeze window in their policy file: no auto-merges on Fridays, no auto-merges during a declared release freeze period, no auto-merges when a manually set freeze flag is present. This is a simple check but it prevents the class of incidents where a dependency bumps silently during a release candidate process.
What Renovate's auto-merge model does differently
Renovate supports auto-merge and has a mature configuration model for it. The differences from Repohelm's approach are worth understanding clearly. Renovate's auto-merge is triggered by CI status checks passing and can be extended with additional rules. It does not, by default, re-evaluate CVE advisory databases at merge time or check for conflicting open PRs from non-Renovate sources. These aren't criticisms, they reflect different primary design goals: Renovate is optimizing for version freshness, Repohelm is optimizing for security-aware remediation.
The practical implication: if you're using Renovate primarily to keep versions current and you have reasonable CI coverage, Renovate's auto-merge is appropriate. If you're using dependency automation specifically to remediate CVEs, the CVE re-check at merge time is the difference between automation you can trust and automation you have to audit.
The unintended breakage rate in practice
Since we started tracking this metric across repos using Repohelm's auto-merge, the rate of auto-merged PRs that required a follow-up revert or hotfix has been under 0.3%. Most of those were cases where CI passed but there was a runtime integration issue that the test suite didn't cover. None were CVE-related regressions, which is the specific failure mode the merge-time advisory check is designed to prevent.
We're not claiming 0.3% is a universally acceptable rate. For a team shipping to a safety-critical system, even a rare automated breakage is unacceptable, and they should probably disable auto-merge entirely. For a team managing 50 repos where most dependency PRs are patch security fixes, clearing 99.7% of that queue automatically and routing the remainder to human review is a significant improvement over the alternative, which is a backlog of hundreds of unreviewed PRs and a CVE remediation SLA that nobody is hitting.
Configuring auto-merge in your policy
The auto-merge configuration in .repohelm.yaml is intentionally narrow by default: patch-only, required CI checks must pass, no freeze windows violated. Teams that want to expand the scope can set the semver range, configure freeze windows, and specify which ecosystems are eligible. The configuration is per-org by default and can be overridden per-repo for special cases.
The one configuration we discourage: setting auto-merge to apply to all major version bumps. Not because major bumps are never safe, but because the probability of a breaking change that your test suite doesn't catch is high enough that requiring a human review for major bumps is worth the friction. The goal of auto-merge is to reduce the manual queue, not eliminate it entirely.