The merge queue

A merge queue that lands pull requests for you.

Flag a pull request keep-mergeable and Talyn watches it. The moment it falls behind, conflicts, or goes red, an agent fixes it. Then the queue lands it in order, the second it is green. No organisation, no admin, no Enterprise plan.

  • Lands ready pull requests in order, the moment they go green
  • Rebases and clears conflicts on the way in — no manual "update branch"
  • Independent pull requests merge in parallel; one slow build cannot stall the queue
  • Auto-fixes anything that falls behind or breaks before it merges

Free plan: three pull requests in the queue at once. The workspace default that keeps every new pull request green automatically is part of Unlimited.

Talyn — Merge queue
sundial/web → main
#1Merging
chore: bump dependenciesChecks
#2Waiting
feat: dark mode toggleReady
#3Fixing
fix: retry the flaky checkout webhookChecks

The gap between approved and merged

A pull request is approved on Tuesday. On Thursday the base branch has moved, the branch is behind, a test that passes on main fails on this diff, and the thing you already agreed to ship needs another afternoon. Nothing went wrong; time passed.

A merge queue is the standard answer, and GitHub's is good. The catch is eligibility — it wants an organisation and, historically, a plan most people reading this do not have — and its behaviour when something fails is to eject the pull request back to you. That is correct for a queue whose job is to protect the base branch. It is not much help to the person now holding a broken branch.

Talyn
sundial/web → main
#1Merging
chore: bump dependenciesChecks
#2Waiting
feat: dark mode toggleReady
#3Fixing
fix: retry the flaky checkout webhookChecks

Fix first, then merge

Talyn's queue does the fixing. When an entry falls behind its base it takes GitHub's free server-side 'Update branch' where that will work, and only spends an agent run when there is an actual conflict to resolve. When a check fails it dispatches a fix run, which pushes to the existing branch — no new pull request to reconcile.

Entries that do not depend on one another drain concurrently, so one slow test suite does not hold up four unrelated changes. Stacked pull requests are handled bottom-up, and a native GitHub stack is handed over at the top rung rather than fought with.

  • Behind the base with no conflict → GitHub's own Update branch, free and instant
  • An actual conflict → an agent resolves it and pushes
  • A failing check → a fix run, on the same branch
  • Green and approved → merged, in order

It gives up on evidence, not on a timer

The hard part of an automated queue is knowing when to stop. Retrying forever burns your agent subscription on a problem no agent can solve. Stopping after N attempts stops on work that was making progress.

So the queue records a signature of what is currently blocking an entry. If it tries a fix and the same blocker comes back unchanged, that attempt achieved nothing and the entry parks. If a different blocker appears, that is progress — the first thing got fixed — and it keeps going. The unit is 'did anything change', not 'how many goes have we had'.

It also parks, rather than retries, when an agent explicitly stands down: some gates need a person, and a run that says so is recorded as needing a human rather than as a crash.

Keep-mergeable: the part that runs overnight

Flagging a pull request keep-mergeable puts a watcher on it. It does not wait for you to notice that main moved — the moment the branch falls behind, hits a conflict, or a check goes red, the fix dispatches. When it is green again the queue lands it.

This is the feature behind 'wake up to green PRs', and it is the one to try first. Flagging pull requests one at a time is free. Having every new pull request you open flagged automatically is part of Unlimited.

What it does not do

No speculative batch testing — it does not build hypothetical merge combinations ahead of time the way a large-scale queue does. No file-overlap analysis to decide which pull requests can be batched. And it cannot bypass your branch protection: if a required check or a required reviewer is missing, the queue waits, exactly as you configured GitHub to make it.

If you already run GitHub's merge queue on a repository, Talyn detects the external gate and arms GitHub auto-merge instead of trying to merge around it.

Questions, answered.

No. Talyn merges through the ordinary GitHub pull request merge API as a GitHub App you install, so it works on a personal private repository with no organisation and no admin rights.

Flag a pull request and Talyn watches it. The moment it goes out of date, clashes with someone else's work, or a test starts failing, Talyn sends an agent to fix it. Once it is green again, the merge queue lands it in order. Flagging pull requests one at a time is free; having every new one flagged automatically is an Unlimited feature.

Only if your branch protection allows it. The queue presses merge through the normal API, so every required check and required review still applies. It cannot override rules you have set.

The entry parks with the reason recorded, and it re-arms on its own if what is blocking it changes — a new commit, a different failure, a resolved conflict. It does not sit there retrying the same failed fix.