HomeReleases

Get started

You shipped it. Nowwrite it up once.

One editor publishes to a hosted changelog on your domain and an email announcement to your subscribers. Feature highlights, version numbers, and a REST API so a tagged deploy can publish the note itself.

Book a demo →

Two surfaces

Hosted changelog and email announcement — written once.

Six labels

Feature, improvement, bug fix, maintenance, performance, announcement.

Publish from CI

Create and publish over the REST API from a tagged deploy.

Author

Write it once, publish it twice.

A rich editor with images, video and code from your asset library. Label the entry, describe what changed in a sentence and have the note drafted for you, then publish it to the changelog and out as an announcement in the same action.

  • Rich text with images, code and media pulled from the Assets library
  • Label each one — new feature, improvement, bug fix, maintenance, performance, announcement
  • Publish from CI through the REST API, or keep it as a draft for review
  • Separate changelogs per project, each on its own domain
The release editor: a title and version, the labels a release can carry, a rich-text body with write and preview tabs, and an assistant open underneath asking you to describe the highlights so it can draft them.

Highlight

Not every release is a bullet list.

The ones worth reading lead with the two or three things that actually changed. Add a highlight per feature, each with its own heading, its own explanation and its own image, and they publish as cards under the note rather than as another line of prose.

  • Feature highlights with a heading, a description and an image each
  • A summary line for the list view, written by hand or auto-generated
  • A cover image uploaded or picked from Assets
  • Version numbers, so a customer can tell which build they are on
A published release: its title, summary and date above the note itself, and under it three feature cards — a home screen widget, push notifications and offline availability — each with its own heading and explanation.

Notify

Announce it to the people who subscribed.

Publishing sends the announcement to your changelog subscribers, and you can narrow it with tags so a mobile-only release does not go to everyone. Each release decides its own channels, and the whole thing can be turned off for a quiet patch.

  • Email announcement to changelog subscribers on publish
  • Narrow the send by subscriber tag
  • Channels set per release — or suppressed entirely
  • Publishing fires an automation trigger you can route anywhere
The changelog as a customer reads it, under the company’s own branding and beside its roadmap and feedback board: releases dated down the left, each with its heading, summary and a link through to the full note, above a button to subscribe to the next one.

Measure

Find out whether anyone actually read it.

Most changelogs are published into the void. Views are counted per release so you can see which notes earned attention and which landed flat, with a delivery log for what was sent and a subscriber list you own.

  • Page views counted per release
  • Compare views across releases over time
  • Delivery log for what was sent and to whom
  • Subscriber list with tags, exportable over the API
The releases console: twelve published and none in draft, page views counted beside them, filters for published and draft, a subscribers tab and a delivery log — with each release listed under its publication date.

Who uses it

What teams actually do with Releases.

For product marketing

Every ship becomes a touchpoint

Turn the release note into an email and an indexable page on your own domain without briefing anyone or opening a second tool.

For support

Deflect "what changed?"

A searchable, dated changelog on your domain answers version questions before they become tickets — and agents can link to the exact entry.

For customer success

A dated record of everything shipped

Pull the year of releases over the API, filtered by label, and drop the list straight into a renewal deck.

Connected

Releases plugs into everything else you run.

Every module writes to the same customer graph, so data captured here shows up wherever it is useful — no connectors to authorize, no sync to babysit.

See all integrations →

FAQ

What teams ask about Releases.

Can we render the changelog inside our product?

Yes. Releases are available over the REST API and the Swift SDK ships a releases view, so you can pull entries and render them in your own UI wherever it belongs.

Can we publish from CI?

Yes. Create and publish releases through the REST API, so a merged PR or a tagged deploy can push the note automatically. Drafts can also be queued for a human to review first.

Does everyone get emailed every release?

Only if you want that. Send to all changelog subscribers or narrow it by subscriber tag, and turn the announcement off entirely for a quiet patch. Channels are decided per release.

Is the changelog good for SEO?

Releases render as indexable pages on your own domain with a per-release SEO title, description, social image and noindex toggle. Sitemap entries are generated for published releases.

Get started

Stop paying for six tools. Run product ops from one.

Everything you were bolting together — feedback, roadmap, changelog, help, support, status, forms — in a single workspace with one API and one bill.

Cancel anytime. Yours to test on real customers.

Talk to sales

Tell us what you're running today and we'll map it onto AppGram.

A real human replies within one business day.