Five steps, and none of them is a credential
This is the whole flow. There is no sixth step hiding behind a support article.
- 01Install Mergelay on GitHub
You start from Mergelay and finish on GitHub’s own installation screen — the one you have already seen for other Apps, showing exactly what is being asked for.
- 02Choose the account or organisation
Your personal account or any organisation where you can install an App. Nothing about Mergelay assumes an organisation.
- 03Grant repository access
All repositories, or the specific ones you pick. GitHub remembers the choice and you can narrow it later from the same screen.
- 04Return to Mergelay
The installation is bound to your workspace through a short-lived, single-use state, so an installation cannot be attached to somebody else’s workspace by replaying a link.
- 05Confirm the watched repositories
Granting access to a repository on GitHub does not silently start watching it. You confirm the list inside Mergelay, and you can change it from Settings.
The hosted path has no manifest to create, no personal access token to paste and no webhook to configure by hand. You never receive a platform bearer token, never edit an environment file and never run a Mergelay process.
Exactly what it can see
Stated as permissions rather than as adjectives, because “secure” is not a permission and “read-only” is.
- Contents — read
Enough to read the repository description, the README and the changed files behind a merge. No write permission exists to be misused.
- Pull requests — read
The title, description, labels, commits and changed files of a merged pull request.
- Metadata — read
The mandatory baseline permission every GitHub App holds.
- Events — pull request, release, installation lifecycle
Three subscriptions and no more. Every webhook is routed by verified installation ID plus repository before anything acts on it.
- Installation tokens stay on the server
They are minted and cached server-side against platform-managed App credentials and a platform-managed webhook secret. None of that ever reaches your browser.
- Uninstall, suspension and access changes are handled
Removing the App or narrowing its repositories on GitHub is a first-class event here, not a state Mergelay discovers when a call starts failing.
What it does with what it reads
Two things happen the first time. Mergelay reads the repository context and lists the recent real merges so you can pick the one to announce, rather than opening on an empty page and asking you to describe your own product from memory. And it pre-fills the product name and the one-line description from the repository description and the README, which you then correct — a wrong guess you can fix in five seconds beats a blank field.
After that it is the merges. The bounded, sanitised evidence that leaves the repository for analysis, and the parts that never leave under any configuration, are set out on the release notes generator page rather than summarised twice here.
Driving the workspace from Claude Code or Codex
The workspace exposes seven MCP tools, all bound to the token’s workspace: mergelay_list_updates, mergelay_get_update, mergelay_draft_from_latest_merge, mergelay_revise_draft, mergelay_review_update, mergelay_publish_draft and mergelay_retry_publication. A tool call cannot name a workspace — the workspace comes only from the token, which is the property that makes one token structurally incapable of reaching another tenant.
They map to three scopes issued from Settings, Developer tools, by owners and admins only: read, write and decide. Reading and drafting stop short of the decision on purpose; only a token issued at the highest level can approve, and the screen that issues it says so in those words.
It is beta and it is gated, and the two things still missing before this could be a public offer are worth naming: OAuth in place of a static personal access token, and one audit entry per tool call rather than a single generic actor. Until then it is a surface for people who already work this way, not a way to onboard.
Scope and boundaries
- Developer watches 1 repository. Team lifts that cap for every repository in the workspace, under fair use rather than as a metered quota.
- Mergelay never writes to your repository, and never creates or edits a GitHub release. Keep tagging exactly as you do now.
- GitLab and Bitbucket are not supported, and will not be before GitHub activation and retention are proven. A roadmap is not an integration.
- There is no public root API. The MCP surface is workspace-scoped, token-governed and explicitly beta.
Questions
Can Mergelay push to my repository?
No, and not because of a policy that could be relaxed: the App holds read permissions on contents, pull requests and metadata and holds nothing else. It creates no branch, no commit, no comment and no GitHub release.
How do I remove it?
Uninstall the App from GitHub, or narrow the repositories it can reach — both are handled here as events rather than discovered later. Repository access is also manageable from Settings, though the authoritative revocation is always the one you make on GitHub’s side.
Do I need an organisation account?
No. You install on the account or organisation you choose and grant only the repositories you want watched. What you cannot do is install once and have it follow you to a second organisation automatically.
Is there an API?
Not a public one, and that is a deliberate omission rather than a gap we are hiding. What exists is the workspace-scoped MCP surface in beta, issued from Settings and governed by scopes and expiry; a public root API is out of scope for now.
Where to read next
- GitHub release notes generatorThe full pipeline, and the table of what leaves your repository.
- Slack integrationThe four setup steps, and what the webhook can and cannot do.
- SecurityHow to report a vulnerability, and what we owe you back.
- PricingBoth plans, and what the plan actually changes.
Install it read-only and watch one repository.
Your first Update is free. No card required.