A merge queue for GitHub Team.
Private repo. Busy main branch. No Enterprise upgrade? Here are your options, and what to check before choosing one.
The short answer
GitHub Team does not include GitHub’s native merge queue for private repositories. You can use a third-party queue, maintain your own workflow, or move to Enterprise Cloud for the native feature.
What GitHub Team includes
GitHub’s native merge queue is available for organization-owned public repositories, and for organization-owned private repositories on Enterprise Cloud. The public-repository exception matters: you do not need Enterprise just because you want a queue for an open-source project. Check GitHub’s current availability.
Auto-merge is available for private repositories on GitHub Team. It completes a PR when required reviews and status checks are satisfied. It does not, by itself, manage an ordered line of PRs. Read GitHub’s auto-merge documentation.
If your team rarely has more than one PR ready to merge, auto-merge with appropriate branch protection may be enough. A queue becomes useful when developers repeatedly update branches and wait for CI as other changes land.
Two green PRs. One broken main.
Imagine two pull requests start from the same version of main. PR A removes an old API field and updates its existing callers. PR B adds a new caller that still uses that field. Each passes tests on its own. Together, they can break.
- 01A passes and merges.
The API field is gone. Main has moved.
- 02B updates against the new main.
Its tests now run with A’s change included.
- 03B’s required test fails.
B stays out of main until its caller is fixed.
A queue coordinates the order and validation. It still needs tests that detect the incompatibility; a queue cannot catch a bug your required checks miss.
Strict up-to-date branch protection also prevents merging against an outdated base. Without a queue, someone or something still has to update the next branch. Loose status checks allow merges without that update. See GitHub’s explanation of strict and loose checks.
Choose who owns the queue.
Start with your required merge throughput, the workflow your developers want, and who will maintain it. Evaluate total cost, including CI runs and engineering time.
| Approach | A good fit when | Check before choosing |
|---|---|---|
| Hosted third-party queue | You want to keep Team and have a vendor operate the queue. | App permissions, CI support, pricing, failure recovery, and serial versus parallel testing. |
| Your own workflow or bot | You have specific requirements and can own ongoing maintenance. | Concurrent runs, stale check results, retries, missed events, and token permissions. Updating every PR is not an ordered queue. |
| Enterprise Cloud + native queue | You want GitHub’s built-in queue and the wider plan fits your team. | The plan cost for your organization and the CI changes needed for merge-group validation. |
For a quiet repository, keeping auto-merge and manually updating branches can also be a reasonable starting point. Measure the interruption before adding another service.
Where MergeRamp fits
MergeRamp is being built for teams that want a simple serial queue on GitHub Team. The planned workflow uses GitHub’s existing auto-merge button: enabling it joins the queue, one active PR updates against main, and GitHub performs the merge after the required checks pass.
A required check from the MergeRamp App is intended to control which PR can proceed. Simply updating one branch at a time is not enough if other waiting PRs can still merge independently.
The design is serial, without batching or parallel lanes. As a rough ceiling, a ten-minute CI run means about six merges an hour per branch before branch-update and queue overhead. If you need more, evaluate a queue with parallel validation.
Our published pricing starts free for up to 5 active committers on private repositories. See the pricing page for how committers are counted and the other bands.
Before you enable a queue
Use a sandbox repository first. Whatever approach you choose, walk through these checks before moving a production branch over.
- Define the rules. Decide which reviews and CI jobs must pass. For a serial branch-update queue, require branches to be up to date and follow the provider’s gate configuration.
- Check the CI triggers. Confirm tests run when the queue updates a PR. GitHub’s native queue needs CI configured for
merge_group; third-party queues may use a different mechanism. Native queue CI requirements. - Verify queue ownership. Make sure a second bot cannot advance waiting PRs outside the chosen queue. Understand and limit bypass permissions.
- Test failures and recovery. Queue two PRs, fail a required check, introduce a conflict, and disable auto-merge. Check that later PRs advance only when allowed.
- Measure a short pilot. Track time to merge, CI runs per merge, stuck PRs, and manual interventions. Keep a documented rollback path.
Common questions
Can I enable GitHub’s native queue on a private Team repository?
No. That combination requires Enterprise Cloud. For a private repository staying on Team, evaluate an external queue or your own automation. GitHub’s availability rules.
Is auto-merge enough?
It may be for a low-traffic branch. Auto-merge handles completion after requirements pass; it does not supply queue ordering or coordinate updates across waiting PRs.
Will a merge queue save CI minutes?
It depends on the implementation and workload. A serial queue can avoid updating every waiting PR after each merge, but still reruns checks for the active PR. Measure before claiming savings.
Do I have to use GitHub Actions?
Not necessarily. Verify that your CI provider can report the checks your queue requires, on the commits it validates. Ask any third-party provider to confirm your exact CI setup.
Can I install MergeRamp today?
Installation is not available yet. You can try the illustrative queue demo and review the planned pricing while the integration is being built.