How to post GitHub releases to Bluesky

Bluesky matters for release announcements for a simple reason: a large, technical, early-adopter audience moved there and kept the build-in-public habit. Open-source maintainers, indie hackers, and platform engineers who would have seen your release on X a few years ago now see it - or miss it - on Bluesky. The feed is chronological by default, which is friendly to timely posts like release announcements, and the culture rewards concrete, technical updates over marketing copy.

There is also a practical reason it is worth automating early: unlike X, the Bluesky API is free. The AT Protocol exposes a straightforward endpoint for creating posts, authentication works with an app password you generate in settings, and there is no developer-app application or paid write tier. That makes Bluesky the cheapest channel on the board to automate yourself - and it is exactly why so many GitHub Actions for it exist.

The constraint that shapes everything is length. A Bluesky post is capped at 300 characters, counted as user-perceived characters, so a release announcement has to be one sharp idea: the benefit, one proof point, and the link. That is a feature, not a limitation - it forces the discipline that makes release posts readable - but it means whatever path you choose has to be good at compressing release notes, not just forwarding them.

The manual path needs no explanation: cut the release, open Bluesky, compress the release notes into 300 characters, paste the release link, publish. Because you write it yourself, the tone is human, the link card renders (the app handles that for you), and you decide in the moment whether this release is worth announcing at all.

It breaks down the same way it breaks on every channel: cadence. Ship several times a week and the context switch starts to bite - you have to remember, re-read the release, compress it, and post, every time, on every channel you care about. Bluesky is rarely anyone's only channel, so the manual cost multiplies by however many destinations your releases deserve. The post that never gets written is the failure mode, and it is invisible.

Treat manual posting as the correct default until you notice yourself skipping announcements you meant to write. When that happens, Bluesky's free API means you have a genuinely cheap DIY option - with two gotchas the next section is honest about.

A DIY automation triggers on the GitHub release event and calls the AT Protocol's create-record endpoint to publish a post. In practice nobody hand-rolls the API call: community actions on the GitHub Marketplace - zentered/bluesky-post-action and cbrgm/bluesky-github-action are the established ones - wrap authentication and posting. Setup is two secrets: your handle and an app password generated in Bluesky's settings, so your real password never touches CI. No developer application, no billing.

The workflow below is a realistic version using cbrgm/bluesky-github-action, which matters for one specific reason: it can convert the URLs in your post into rich link embeds. On the AT Protocol, a URL in the post text is just text - it is not clickable and shows no preview card unless the client that created the post attached facets (the metadata that marks a range of text as a link) or an external embed. This is the classic DIY gotcha: the naive script posts fine, and every link in it is dead text.

Be equally honest about what the workflow does not do. It posts the same fixed template for every release, so a major launch and a typo-fix patch look identical. It publishes the instant the release fires, with no human reading it first. There is no retry when the API hiccups, no record tying the post back to the release, and a 300-character budget that a raw tag-plus-URL template spends badly. For a personal project, none of that matters. For a brand account, all of it does.

This deserves its own section because it is the thing that quietly ruins DIY Bluesky automations. In Bluesky's data model, a post is a text record, and anything interactive - links, mentions, hashtags - is described by facets: byte-range annotations attached alongside the text. The official apps compute facets for you when you type, which is why manual posts always work. A script that just sets the text field gets exactly what it asked for: the URL rendered as inert characters.

A release announcement without a clickable release link is close to worthless, so whatever you build has to detect the URL, compute the byte range, and attach the facet - or attach an external embed for the preview card. The better community actions handle this for you, which is why choosing one that supports link embeds matters more than any other feature. If you write your own client code, budget real time for facet handling, because byte ranges over UTF-8 text are exactly the kind of detail that works in the demo and breaks on the first release note with an emoji.

This is also a fair preview of what tool-versus-DIY means on Bluesky. The API being free removes the billing argument that dominates the X decision, so the remaining difference is entirely in the details: correct facets, compression into 300 characters that reads like a human wrote it, approval before it goes public, and a record of what was posted for which release.

S2P connects your GitHub repository and your Bluesky account through a managed connection, so there is no app password sitting in CI secrets. When you cut a release, it drafts a Bluesky-native post from the release notes: one sharp idea compressed into the 300-character budget in your brand voice, with the release link attached correctly so it is clickable and carries a preview. Rules decide which releases qualify - semver, branch, path, label - so a dependency-bump patch never spams your followers.

The draft then goes into a review queue. A human reads it, edits if needed, and approves - or, once you trust the loop, you flip that channel to autonomous mode and let qualifying releases publish on their own. Either way every published post stays tied to the release that created it, retries are handled when the API blips, and the same release fans out to the rest of your channels - X, LinkedIn, Discord, Reddit, Mastodon - without another rewrite.

The honest comparison: if you ship rarely, post by hand. If you enjoy owning the workflow and one channel is enough, the DIY Action is genuinely cheap here - Bluesky is the best DIY channel on the board. If your releases should reach Bluesky and several other channels with drafting, approval, and an audit trail included, the release-native path is the one that stays cheap in time rather than money. Want to feel the drafting before connecting anything? The free changelog-to-social generator has a Bluesky mode: paste release notes, get a 300-character post, no login.

Map it to cadence, like every channel. Announce a release every week or two: post by hand and spend nothing. Ship often with an engineer happy to own a workflow: the DIY Action is legitimately the strongest DIY case of any social channel, because auth is an app password and the API costs nothing - just pick an action with link-embed support and accept that every release gets the same template and no review. Ship often to multiple channels with a brand to protect: use a release-native tool and keep a human in the loop.

If you are weighing the DIY route more broadly - Actions versus webhooks versus scripts across all your channels - the GitHub Actions versus webhooks comparison lays out the full decision matrix; the short version is that the workflow around the post, not the API call, is where the real cost lives. Bluesky just happens to be the channel where the API call itself is free.

Whatever you pick, the goal is unchanged: make announcing a release so cheap you never skip one. Bluesky's audience rewards teams that ship visibly and speak plainly. A steady stream of honest, 300-character release posts is exactly the kind of presence that compounds there.