Connect GitHub. Post to LinkedIn.
Point the platform at a GitHub repository and it reads the commits you push, drafts a LinkedIn post about what you actually shipped, and hands it to you ready to publish. You write nothing, and it invents nothing.
Private beta. Tell us what you are building; invites go out in batches.
How it works.
Add the webhook
A push webhook in your repository settings, pointed at the platform. You choose what it sends.
Keep pushing
Work exactly as you do now. It reads the commits you push to the branch you pointed it at.
Get the post
A draft lands grounded in those commits. Approve it in seconds, edit it first, or skip it - nothing publishes until you say so.
What comes out.
What you pushed
- 9f2c1afeat: add CSV export to dashboards
- 3b7d84fix: logout now ends the session
- c41e07feat: magic-link sign-in
Draft · LinkedIn
- - You can now export any dashboard to CSV.
- - Logging out actually ends your session.
- - Magic-link sign-in is live, no password needed.
Every line traces to a commit. Nothing else gets written.
What it reads.
Commit history, nothing else: messages, hashes, and the timing around them. That is why every line of a post traces back to something you actually pushed.
The webhook is yours - you choose what it sends, and the platform holds no credential to your repository. Delete it and it goes blind. Prefer pull? A read-only fine-grained token is the second option.
No conventional commits, no changelog, no discipline required. Messy commit messages are the normal case - it reads for what you shipped, not your prose.
It will not make things up.
A quiet stretch has nothing to ground a post on, so the platform writes nothing. No invented features, no fake milestones, no filler to keep a schedule alive.
Questions.
Does PeerPost need write access to my GitHub repository?
No - it has no access at all. The webhook you add only sends the events you chose. If you prefer the token option instead, a fine-grained personal access token with Contents set to read-only cannot push, open pull requests, comment, or change anything either.
Why a webhook instead of an access token?
Trust. A token, even a scoped one, asks you to hand a young product access to your repository. A webhook flips that: you stay in control, you decide what gets sent, and you can read every payload. The read-only token remains available as a second option if you prefer it.
Does it work with private repositories?
Yes. Private and public repositories work the same way. Nothing about your code is published; the only thing that ever becomes public is the LinkedIn post you approve.
Does PeerPost read my source code?
It sees your commit history: the messages you wrote and the metadata around them. It writes posts about what you shipped, not about how you implemented it.
Do I have to write conventional commits?
No. There is no format to adopt and no discipline to maintain. It is built to read ordinary commit messages written by someone who was not thinking about marketing at the time, because that is what commit messages actually look like.
What happens in a week where I did not ship anything?
Nothing gets posted. There is nothing to ground a post on, so it stays quiet rather than fabricating a milestone to fill a schedule. That is deliberate.
Can I review posts before they go out?
Yes, always. Drafts arrive for you to approve and you can edit them first. There is no auto-publish mode to enable: approval before publishing is built into the product rather than offered as a setting, so nothing can go out in your name without you seeing it.
Want to do it by hand first? How to turn GitHub commits into LinkedIn posts.
Shipping somewhere else? See every integration.