A merge queue for GitHub Team
Keep main green on GitHub Team, without Enterprise.
Label a pull request queue. We test it on top of the latest main, and merge it when your required checks pass. One PR at a time.
$49/month per GitHub organization, for up to 25 developers. 14-day trial.
Not open yet: install opens once the GitHub App is registered on GitHub.
Why this exists
Two pull requests can each pass CI against an older main, get merged one after the other, and break main together. A merge queue prevents that by testing each PR against the latest base before it merges (GitHub docs, “Managing a merge queue”).
GitHub’s own merge queue works on private repositories only on Enterprise Cloud (GitHub docs, gated features, read 2026-10-20). The hosted alternatives we found charge per developer. Queue to Main is one price per organization.
What it is not
It is deliberately small. Read this before you install:
- Single lane. One PR is tested at a time per repository and base branch. No batching, no parallel or speculative testing, no priority lanes.
- GitHub only. No GitLab or Bitbucket.
- No uptime guarantee. If we are down, the queue pauses; your normal GitHub merging keeps working.
- Up to 25 active contributors per organization. Past that, a single lane gets slow; use a tool with batching.
How it works
Queue
Add the label
queueor comment/queueon an approved PR whose checks are green.Test
We create
fmq/<base>/<pr>: the latest base branch with the PR merged in. Your CI runs on it.Merge
Required checks green and the base hasn’t moved: we merge the PR. If the base moved, we rebuild the test branch.
Or drop
Red checks, or CI not started within 30 minutes: we remove the label, comment with the reason, and move on.
The PR shows a check run with its position in the queue. Full details: setup doc.
Exact permissions
These are the permissions the GitHub App requests. Nothing else. You choose which repositories it can see when you install.
| Permission | Access | Why |
|---|---|---|
| Contents | read & write | Create and delete the fmq/… test branches and merge the tested PR. We read branch refs and commit SHAs, never file contents. |
| Pull requests | read & write | Read approval state, add and remove the queue label, comment when a PR leaves the queue, merge. |
| Checks | read & write | Read your CI results and write our own “position in queue” check run. |
| Commit statuses | read | Read results from CI systems that report statuses instead of check runs. |
| Metadata | read | Required by GitHub for every App (repository names, default branch). |
Webhook events: pull_request, pull_request_review, check_suite, check_run, status, issue_comment (for /queue), plus installation events GitHub always sends. The App does not change your branch protection rules.
When we’re down, it fails open
- Queue to Main does not add required checks or change branch protection. If the App is down, PRs simply aren’t merged by it. You can still merge any PR by hand, as today.
- To take a PR out of the queue, remove the
queuelabel or comment/unqueue. - There is no uptime guarantee. This is a small service run by one developer, not 24/7 infrastructure.
- After the trial, an unpaid organization’s PRs are no longer queued (we comment why). Normal merging is never blocked.
It runs your CI once more
Every queued PR runs your CI one more time, on the fmq/… test branch. That run is on your CI bill (GitHub Actions minutes or your own runners), not ours. Rebuilds after the base branch moves run it again.
That extra run is the point of a merge queue: it is the test of “this PR on today’s main”.
Pricing
Per GitHub organization, up to 25 active contributors. Every repository in the installation.
- 14-day free trial from install. Billing starts only if you subscribe.
- Monthly, renews each month until you cancel. No annual plan.
- Cancel in two clicks in the Stripe customer portal.
- Your CI minutes for the extra run per PR are on your CI bill.
Not open yet: install opens once the GitHub App is registered on GitHub.
What other merge queues cost
List prices from each vendor’s pricing page, read 2026-10-20. The 10- and 25-developer columns are list price × seats, our arithmetic. Check the linked pages for current prices.
| Tool | Unit | 10 devs | 25 devs |
|---|---|---|---|
| Queue to Main | $49 / org | $49 | $49 |
| Mergify | $21 / seat (free up to 5) | $210 | $525 |
| Aviator | $20 / developer, Team | $200 | $500 |
| Graphite | $40 / user, Team, billed annually | $400 | $1,000 |
| Trunk | Per committer (free up to 5); paid price not shown on its page | unconfirmed | unconfirmed |
| GitHub merge queue | Private repos: Enterprise Cloud only | – | – |
Those tools do more (batching, parallel queues, other features). If you need those, they are worth their price. Free option: the open-source gh-actions-merge-queue Action, if you are happy to set it up yourself.
FAQ
Does it read our source code?
No. The App reads branch refs, commit SHAs, PR metadata and check results. It creates the test branch through GitHub’s merges API, so GitHub does the merge; we never download file contents. We store no source code.
What counts as an active contributor?
Someone who opened or pushed to a pull request in the organization in the last 30 days. Up to 25 are covered by the $49 price. We don’t sell a larger plan; over 25, a single lane is the wrong tool.
Which merge method does it use?
A merge commit when the repository allows it, because the test branch is “base plus a merge of the PR”, so that lands exactly what was tested. If merge commits are disabled, it uses squash, then rebase.
Does a PR need approval and green checks first?
Yes. A PR is queued only if it is approved and its checks are green, per your branch protection. If an approval is withdrawn or changes are requested while it waits, it leaves the queue.
What if our CI doesn’t run on the test branch?
If CI hasn’t started on fmq/<base>/<pr> within 30 minutes, the PR is dropped with a comment telling you to add fmq/** to your workflow triggers. See the setup doc.
What happens when the trial ends?
If you haven’t subscribed, new PRs are no longer queued and we comment why. Nothing else changes; you merge as you did before.
Can’t we just use GitHub’s own merge queue?
On private repos, only on GitHub Enterprise Cloud. We wrote up the options on GitHub Team, with sourced prices.
Who runs this?
One independent developer. Questions go to [email protected].