Create content from any GitHub repository

Paste any link to a GitHub repository and turn your changelog into a distributed content feed that your customers can subscribe to.

Trusted by teams at

  • Coinbase
  • Farcaster
  • Stable
  • Base
  • Nodle

A week of commits, in language your customers use

Paragraph reads what merged, leaves out what doesn't matter, and groups the rest by what actually changed for the person using your product.

main this week
  • a91c4e2 feat(webhooks): retry delivery with backoff
  • 7f30bd1 wip left out
  • 4c8e0aa fix(auth): drop stale session on refresh
  • 1d92f77 chore(deps): bump zod to 4.1.2 left out
  • b6ac310 perf(search): rebuild index on write
  • e40f1c9 fix typo left out
Changelog v2.14

Webhooks retry on their own now

  • Webhook deliveries now retry with backoff, so a short blip on your side no longer drops the event. #412

  • You stay signed in when a session refreshes mid-request. #418

  • Search comes back about twice as fast on large workspaces. #421

Published Emailed subscribers Posted to X and LinkedIn

What happens after you merge

Not a prettier commit log. Paragraph writes the update in your customers' language, links every line to the work, and takes it to X, LinkedIn, and email.

Get started

Reads the merged work

Pull requests, issues, and releases, not just the one-line commit messages you wrote at midnight.

Groups by outcome

Six commits behind one fix become one line a customer can read and understand.

Leaves out the noise

Dependency bumps, lint passes, reverts, and merge commits stay out of the entry unless they changed something real.

Keeps the receipts

Every item links back to the pull request, so an engineer can check the claim in one click.

Sounds right in both places

Paragraph learns your voice from what you've published, and keeps a separate one for social, because nobody writes a release note the way they write a thread.

Runs on a schedule

A weekly automation drafts Friday's entry while you're still shipping, and waits for you to look at it.

Keeps your feeds moving

Every release becomes a thread and a LinkedIn post, written for each feed rather than pasted into both. Shipping is what fills your content calendar.

Emails the people who asked

Customers who subscribed to your releases get the entry in their inbox, from your domain.

Four steps, then it runs itself

Set it up once on a Friday afternoon. After that the draft is waiting for you.

  1. 1

    Connect the repository. Access follows the GitHub account you connect, so Paragraph reads what that account can read, and nothing else.

  2. 2

    Pick a rhythm. Weekly, every release, or only when you ask. Paragraph gathers the work merged since your last entry.

  3. 3

    Read the draft. Changes are grouped by what they do for the person using your product, with the pull requests linked underneath.

  4. 4

    Approve it. The entry publishes to your changelog, emails your subscribers, and posts to X and LinkedIn.

One entry, everywhere your customers already are

Publish the changelog, email the people who subscribed, and post to X and LinkedIn. Each version is written for where it lands, not pasted into it.

See distribution

X

@acme

Shipped this week: webhooks retry on their own, sessions survive a mid-request refresh, and search is about twice as fast on large workspaces. Full notes:

acme.com/changelog

LinkedIn

Acme · Company page

Three things shipped this week, and all three started as something a customer told us was slow or annoying. Webhook deliveries now retry with backoff, sessions hold through a refresh, and rebuilding our search index roughly halved query time on large workspaces. Notes and pull requests here:

acme.com/changelog

Why teams keep it running

Proof that you're shipping

Customers, investors, and candidates can all see the pace without you stopping to write an update.

Written for customers, not for Git

Each entry leads with what changed for the person using your product, and keeps the technical detail one click away.

It stays yours

Your changelog lives on your domain with your subscribers and your RSS feed. Export it or move it whenever you want.

Paragraph writes the first draft. You decide what your customers read.

See how approvals work

Frequently asked questions

What developers ask before they point Paragraph at a repository.

Read the docs

No. Paragraph reads the pull requests, issues, and releases around the commits, so "wip" and "fix typo" never reach your customers. Better commit messages help, but nothing depends on them.

Yes. Repository access follows the permissions of the GitHub account you connect, so Paragraph sees exactly what that account sees. You can scope the connection to a single repository.

Tell the automation which packages, paths, or labels to watch and it stays inside them, so a backend change doesn't land in the mobile app's changelog. You can run more than one changelog from the same repository.

No. Every entry waits for your approval before it publishes, emails anyone, or posts to a social account. Reading your repository runs on its own; anything that writes somewhere needs your say-so first.

Yes. Entries open in the normal Paragraph editor. Rewrite a line, cut an item, change the summary, then approve. Your edits teach it what you want next time.

On a page of your own, at something like yourcompany.com/changelog. Readers can subscribe by email or RSS, and every entry is built to be found in search and by AI assistants.

Start free. Connecting GitHub, X, and LinkedIn is part of the paid plans, and connecting X or LinkedIn for the first time adds bonus credits to your cycle. See pricing for the details.

Point it at the repo you shipped from this week

Paragraph reads what merged and shows you the first entry. Nothing publishes until you approve it.

Get started See pricing