Turn your GitLab commits into LinkedIn posts.
Point the platform at a GitLab project, whether it lives on gitlab.com or on the instance you host yourself. It reads the commits you push, drafts a LinkedIn post about what you actually shipped, and hands it to you ready to publish.
Private beta. Tell us what you are building; invites go out in batches.
How it works.
Add the webhook
A push webhook in your project 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
- a71f39feat: bulk import from CSV
- 5e0c22fix: stop double-charging annual plans
- d38b16feat: audit log for admin actions
Draft · LinkedIn
- - Bulk import from CSV is live.
- - Annual plans no longer get double-charged.
- - Every admin action is now written to an audit log.
Every line traces to a commit. Nothing else gets written.
What it reads.
Commit history, nothing else: the messages, hashes, and timing around what you push. Every line of a post traces back to a commit that exists.
The webhook is yours, on gitlab.com or your own instance - you choose what it sends, and The platform holds no credential to your project. Remove the hook and it goes deaf. Prefer pull? A token with read_api and read_repository is the second option, read-only by construction.
Self-managed means your code stays on your infrastructure. The only thing that leaves is what your webhook sends, and the only thing that goes public is the post you approve.
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 this work with self-managed GitLab?
Yes, and the webhook model suits it especially well: your instance sends events out, so nothing needs to reach in, and your code never leaves your infrastructure. If you prefer the token route instead, the platform needs to be able to reach your instance.
Why a webhook instead of an access token?
Trust, and control. A token asks you to hand a young product access to your project; a webhook keeps the sending on your side - you decide what goes out, and you can inspect every payload. The read-only token stays available as the second choice.
Which token scopes would PeerPost need?
None, by default - the webhook setup involves no token at all. If you choose the token route, read_api and read_repository are enough. Both are read-only: it cannot push, open a merge request, or comment anywhere.
Can I use a project access token instead of a personal one?
Yes, if you go the token route. A project access token scoped to the single project you want posted about is the tighter option, and it means the connection does not depend on any one person's account.
Does it work with private projects?
Yes. Private and public projects work identically. Your code is never published. The only thing that ever goes public is the LinkedIn post you approve.
Do my commit messages need to follow a convention?
No. There is no format to adopt. It reads ordinary commit messages written by someone who was not thinking about marketing when they wrote them, which is what commit messages actually look like.
What happens in a week where I did not ship anything?
Nothing gets posted. With no commits to ground a post on, it stays quiet rather than inventing a milestone to fill a schedule. That is deliberate, not a limitation.
Shipping somewhere else? See every integration.