Automerge with multiple Atlantis instances causes premature PR merge

[guyscher]

Bug Description

When running multiple Atlantis instances watching the same repository with automerge enabled, each instance independently decides to merge the PR once its own plans are all applied — without checking whether other instances still have unapplied plans. This causes premature merges, leaving plans from other instances unapplied.

Reproduction Steps

1. Configure 2+ Atlantis instances watching the same repo (e.g., Instance A manages infra/networking/, Instance B manages infra/compute/)
2. Enable automerge: true on all instances
3. Create a PR that modifies root modules managed by both instances
4. Selectively apply plans one instance at a time — e.g., apply all Instance A plans first
5. Observe: Instance A merges the PR immediately after its plans are applied, even though Instance B still has unapplied plans

Expected Behavior

The PR should only be merged when all plans across all Atlantis instances have been successfully applied. Automerge should be aware of (or defer to) the state of other instances.

Actual Behavior

The first instance to complete all of its own applies triggers the merge, ignoring unapplied plans from other instances. This can lead to:

• Unapplied infrastructure changes that were planned but never applied
• Drift between the planned state and actual infrastructure
• Silent failures where team members assume all changes were applied

Environment

• Atlantis version: affects current versions with automerge enabled
• Multiple Atlantis instances watching the same repository
• Automerge enabled on all instances

Possible Solutions

1. Cross-instance awareness: Atlantis could check GitHub commit statuses/checks from all instances before triggering automerge
2. Documentation update: At minimum, warn users that automerge is not safe with multi-instance setups (update automerge docs)
3. Post-workflow hook pattern: Provide guidance on using a post-apply webhook that checks all commit statuses before triggering merge via API

Related

• Discussion: Automerge and multiple Atlantis instances #4547
• Tangentially related: Race condition between post-workflow hooks and automerge pull cleanup #3336 (race condition between post-workflow hooks and automerge)
• Tangentially related: Automerge should only merge if there is a plan #715 (automerge should only merge if there is a plan)

[dosubot]

Hi @guyscher! I'm Dosu and I’m helping the atlantis team.

This is a known issue. You're correct that Atlantis has no cross-instance awareness for automerge — each instance only checks its own local database (pullStatus.Projects) and has no mechanism to query the state of other instances (automerger.go#L19-L49).

This exact scenario was also reported in #5773.

Recommended workaround: Use VCS branch protection rules to require all Atlantis status checks to pass before merge. For GitHub, this would look like:

• Enable branch protection on your main branch
• Require status checks from all instances (e.g., atlantis-instance-a/apply, atlantis-instance-b/apply)

This delegates coordination to the VCS, preventing any merge until all instances report success. It's the commonly recommended approach for multi-instance setups.

For your proposed solutions:

1. Cross-instance awareness — This would likely require extending the existing Redis-backed locking infrastructure to include shared automerge state. There's been recent work on distributed locking, but nothing specifically targeting automerge coordination.
2. Documentation update — Agreed, this limitation should be documented more prominently.
3. Post-workflow hooks — Be aware of #3336, which documents a race condition between automerge and post-workflow hooks that can leave locks intact after merge.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[guyscher]

I tried the branch protection rules, but you can't apply because I set that the PR must be mergeable before applying.

[dosubot]

That's the classic chicken-and-egg problem. For GitHub, there's the --gh-allow-mergeable-bypass-apply flag (or ATLANTIS_GH_ALLOW_MERGEABLE_BYPASS_APPLY=true) that was designed for this exact scenario.

When enabled, the mergeability check excludes status checks matching {vcsstatusname}/apply — so apply can run even though the apply status itself would block the merge.

For multi-instance setups specifically, you may also want --ignore-vcs-status-names to ignore status checks from your other Atlantis instances when evaluating mergeability.

That said, this combination doesn't fully solve the original automerge coordination problem — it just allows apply to run. The premature merge issue would still occur since each instance only tracks its own projects.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}