Yes, in the documentation of one widely used bot, which supports a merge queue on one code host and merge trains on another. When the queue is on, the bot adds passing pull requests to it instead of merging directly, and it rebases only on conflict. Your CI must also run on the queue's temporary branches.
What a queue changes
Without a queue, every merge makes other open bot pull requests stale, and each one needs a rebase and a fresh test run. A merge queue tests each pull request against the head of the base branch plus the ones ahead of it, then merges in order. That removes much of the rebase churn described in our post on why bot pull requests keep getting rebased.
The bot's documentation says that on a host with a merge queue, its automatic rebase setting resolves to conflict only, because the queue already tests against the base branch head. The same applies to merge trains on the other host.
Setup steps from the documentation
For the merge queue on the first host:
- Make CI run on the queue event. For one CI system, that means adding the merge group event to workflow files. For another CI provider, run tests on the temporary queue branches.
- Enable the repository setting that allows auto-merge.
- In branch protection for the base branch, require the merge queue.
- Confirm the required checks for the base branch are the ones you want.
- Enable automerge in the bot's configuration, for example for minor and patch updates.
With the bot's native automerge on, the host's auto-merge handles adding the pull request to the queue. With it off, the bot tries to merge directly, which works if it is on the bypass list, and otherwise adds the pull request to the queue itself once checks pass. The documentation also recommends enabling the setting that deletes head branches automatically.
For merge trains on the second host, the bot detects whether trains are enabled and asks the host to add the merge request to the train once its pipeline succeeds. The documentation says this needs version 17.11 or later of that host.
The branch automerge trap
The bot has a mode that pushes passing updates straight to the base branch and opens a pull request only on failure. The documentation warns that with a queue or trains this works only if the bot is allowed to push to the protected branch, for example by being on the bypass list. Otherwise it logs a warning and creates a pull request instead. In such repositories, use pull request automerge, or grant the bypass deliberately.
Think hard before granting a bypass. A bot that can push to the base branch without review is a powerful identity. Our post on what permissions a remediation bot should have argues for the least that works.
Checks that matter in a queue
| Check | Why |
|---|---|
| CI runs on queue branches | Otherwise the queue waits forever |
| Required checks are meaningful | A queue only protects you as far as the tests |
| Dependency policy runs in the queue | The combined result is what ships |
| Bot permissions reviewed | Bypass lists are easy to forget |
Add your dependency checks, such as a vulnerability scan and a license check, to the queue's required checks, so the merged result is scanned and not only each pull request on its own.
Try it yourself
Click through it at your own pace, or open it full screen.
Step through the gate and note which checks block a merge, then decide which of them belong in your queue's required list.
Quick check
Will the bot still rebase my pull requests with a queue on?
In the documented automatic mode, it rebases only when there is a conflict, because the queue tests against the base branch head.
Is branch automerge safe with a queue?
Only if the bot may push to the protected branch, which means a bypass. Prefer pull request automerge unless you have a strong reason.
Safeguard applies policies and gates to pull requests, builds an SBOM from manifests and lockfiles, and uses reachability analysis to show which flagged dependencies your code calls. Fix pull requests are off by default, with every category on Manual. A free scan is available.
Sources
- Update bot documentation: automerge, merge queue and merge trains
- Update bot documentation: configuration options, rebase setting
Last reviewed: 19 October 2026.
