What happens between the merge and the draft
Five steps run without you. None of them publishes anything; the last one hands you something to edit.
- 01The GitHub App receives the merge
Mergelay is notified on the repositories you granted, then fetches the real pull request metadata from GitHub rather than trusting the webhook payload alone.
- 02The evidence is assembled and bounded
The title, the description, the labels, the commits and — depending on the privacy mode of the deployment — sanitised patches or metadata alone are collected into one bounded package.
- 03Your product context goes first
The stable context of the repository, which you confirm once and can edit at any time, is placed before the variable pull request content, so the wording of one merge cannot redefine what your product is called.
- 04The model returns a structured object
Not a paragraph: a change type, an impact, an audience, the evidence behind it, the assumptions it made, what it remains uncertain about, and a recommendation about whether this is worth communicating at all.
- 05That becomes a Change, and the Change becomes an Update
A Change is what happened in the code and why it matters. An Update is the communication package prepared from it, holding one editable channel draft per destination you have connected.
What is sent to the model, and what never is
A release-note generator is only as safe as the payload behind it, so here is the payload. These ceilings are enforced in code, not by prompt instructions.
| Evidence | Sent to the model | Never sent |
|---|---|---|
| Pull request title and description | Both, with the description truncated at 12 000 characters | Anything past that ceiling |
| Labels and commits | Every label, and up to 50 commits | Commit 51 and everything after it |
| Changed files | Up to 60 files per analysis | The files past the sixtieth |
| Patch bodies, default mode | Up to 6 000 characters per file, 90 000 cumulative | Nothing at all when the deployment runs in metadata-only mode |
| Credential files, key files, infrastructure state | The path and the fact that it changed | The patch body, in every mode |
| Dumps, backups and fixtures | Metadata alone | The patch body, in every mode |
| A patch where redaction finds something | The file is still counted as changed | The whole patch, dropped on a key, an email address or a high-entropy opaque value |
| The repository as a whole | Only the bounded evidence above | A full clone, under any configuration |
Repository content is treated as untrusted evidence and never as an instruction. A README cannot tell Mergelay what to announce.
Several merges, one release
A generator that emits one note per pull request produces a feed, not a release. What a reader wants is the story: the migration, the three merges that made it work, and the one sentence about what they now have to do.
An Update therefore keeps an ordered list of the product events it speaks for, primary source first. Three paths write that list. The composer takes between one and ten unique sources and applies them against the exact version you are looking at, which regenerates every draft and invalidates any review already pending on the old wording. The watcher appends a newly merged pull request to an Update that is still open and compatible, preferring one that already covers the same repository, rather than opening a second Update behind your back. And creation records the merge that started it as the primary source.
The ceiling is ten sources, said out loud because it matters: an Update that already carries ten, or that has already been through a publication attempt, is never aggregated into. Past that you are telling a second story, and Mergelay makes you decide that rather than deciding it for you.
What you get out
One approved Update produces every format below at once, each written for its own reader rather than pasted between them.
- A private release-note record
Markdown you copy where you want it, or push to your CMS through an automation webhook — n8n, Make, Zapier or an endpoint you wrote yourself.
- An internal brief
The version for the people who ship: what changed, what it affects, what they should do next.
- A Slack or Microsoft Teams message
Posted through a webhook URL you create in your own workspace and paste into Mergelay.
- A customer email
Sent from your workspace sender identity, with the brand kit applied if you turned it on.
- A post per connected social network
Written to each network’s real budget for X, LinkedIn, Bluesky and Mastodon, and published only after the same approval.
The honest counterpart, in the same breath: Mergelay does not host a public release-note page. The record is yours, and it is private until you put it somewhere.
What it will not do
Four things a release-note generator could plausibly do, and does not.
- It never writes to your repository. The App holds read permissions on contents, pull requests and metadata, and creates no branch, no commit and no GitHub release.
- It never publishes customer-facing communication without an explicit human approval bound to the exact revision you read, and any content edit creates a new revision and asks you again. Internal communication is the one category a workspace can choose to auto-publish, and that switch starts off.
- It watches 1 repository on Developer. Team removes that cap for every repository in the workspace, under fair use rather than as a metered quota.
- It does not support GitLab or Bitbucket. That stays true until GitHub activation and retention are proven, and saying otherwise now would be selling a roadmap.
Questions
Does it work on a private repository?
Yes. The App is installed on the account or organisation you choose and reads only the repositories you grant it. One thing changes: on a private repository the link back to the change is deliberately left out of social posts, because the page behind it would not be readable anyway.
What if my pull request titles are bad?
That is the reason for reading the diff instead. The description, the labels, the commits and the bounded patches go with the title, and the analysis comes back carrying its evidence and its assumptions — so a thin title is visible as a thin title rather than quietly becoming a thin release note.
Does every merge produce a release note?
No, and a generator that says yes is describing a noise machine. A Change exists even when Mergelay recommends communicating nothing, so you can see the repository is watched without being asked to announce a dependency bump. Merges that look like upkeep — bot authors, dependency labels, chore titles — are flagged with the reason and skipped by the default selection, and stay choosable if you disagree.
What does it cost?
Your first Update is free and needs no card: one real Update, on your own repository, once per workspace and never again. After that the Developer plan is $11 a month for 1 repository and Team is $46 for any number, both under fair use. There is no permanent free plan and no trial. USD, excluding VAT and sales tax — calculated and charged at checkout by Polar Software, Inc., our merchant of record.
Where to read next
- AI release notes generatorWhat happens when the model writes something it cannot support.
- GitHub integrationThe exact permissions the App holds, and how to remove it.
- Mergelay vs GitHub release notesWhen GitHub’s own generated notes are the better answer.
- PricingBoth plans, and what the plan actually changes.
See what your last merge would have said.
Your first Update is free. No card required.