Changelog

Every app has a Changelog tab: write or generate release notes, publish the ones worth showing, and Relayer hosts a public page for them at https://www.relayercli.com/changelog/your-app (pick the slug in app settings; the immutable ref always works too).

Connect GitHub

Install the Relayer GitHub App from Integrations and grant the repositories you want. Then, on the app's Source tab, attach one or more repos. Source shows their live pull requests, commits, releases and tags - the raw material for everything below. Tokens are short-lived installation tokens; Relayer never stores your code.

Generate with AI

On the Changelog tab, Generate from GitHub turns real activity into a draft entry:

• Latest changes covers everything since your last published entry. Publishing advances a per-repo checkpoint, so the next draft starts where the last one ended.
• A specific release covers exactly one tagged release (the diff against the previous tag, plus PRs merged in that window). If you wrote release notes on GitHub, they are treated as the source of truth and enriched from commits.
• Include PR links is off by default so public changelogs stay free of internal references; turn it on for internal-facing notes.

Generation always produces a draft. Nothing is published without you. AI usage is metered per organization (see Organization → Usage); only successful generations count.

Import your history

A brand-new changelog with one entry looks abandoned. Import from GitHub brings past releases in as drafts: pick the ones worth showing (a tag filter like v* hides staging noise), choose their notes verbatim or AI-polished, and each import keeps its original GitHub publish date - so your public timeline reads genuinely historical from day one. You publish the keepers; nothing is imported as published.

Write and publish

Entries are edited in a rich text editor (formatting toolbar, no markdown syntax required; content is stored as markdown). Each entry has a category (Update, Feature, Improvement, Fix, Security, Breaking change), free-form tags, an optional featured image (compressed automatically on upload), and an editable publish date.

Publishing mints a stable, human-readable slug from the title - /changelog/your-app/faster-sync-engine - which never changes afterwards, so published URLs survive title edits. Every published entry gets its own detail page with proper SEO metadata (canonical URL, description, social card from the featured image). Make private hides an entry from the public page without deleting it; Unpublish returns it to draft.

The public page

https://www.relayercli.com/changelog/your-app is the hosted timeline: newest first, category and date rail, tags, featured images, and per-entry detail pages. Link it from your site, docs or support macros. Only published entries appear; drafts and private entries never leak. Machine-readable release feeds (RSS/JSON) remain separate, per channel, under /feed/....

Changelog entries vs releases

These are deliberately different things:

• A release is operational: a version offered to devices on a channel with a rollout percentage. Releases are never created automatically from GitHub - you promote a GitHub release from the Releases tab, choosing the channel and starting rollout yourself.
• A changelog entry is communication: the human-readable story of what changed, published to your public page.

Generate and import work from the same GitHub data either way; what they produce is words, not deployments.