How to post GitHub releases to X (Twitter)

The first path is manual: when you cut a release, you open X, rewrite the release notes into a human post or a short thread, and publish. The second is DIY automation: a GitHub Action fires on the release event, calls the X API, and posts. The third is a release-native tool that connects your GitHub repository and your X account, drafts the post for you, and routes it for approval before anything goes live. All three are legitimate; they just trade off effort up front against effort per release.

The wrinkle that trips people up in 2026 is that X is no longer the free-to-automate channel it was. Unlike a Discord or Slack webhook, there is no simple no-auth URL you POST to, and unlike a few years ago there is no free write tier on the API. Posting to X means an X developer app, OAuth credentials, and a paid API plan - a detail most older tutorials never mention because they were written when the free tier still existed. We will be explicit about that cost, because it changes which path is actually the cheap one.

So the framing for the rest of this guide is practical and honest. We will cover what a good release post looks like on X, walk the manual path because it is genuinely fine at low volume, sketch a real DIY GitHub Action so you can see exactly what you would maintain, spell out the current X API pricing, and then explain where a release-native tool earns its keep. No path is universally right - the goal is to help you pick the one that matches how often you ship.

A release on X is not your release notes. The changelog is a list of what changed; an X post is one sentence about why the most important change matters, plus a link. The winning pattern is benefit first, proof second, link last: lead with the outcome a user gets, back it with the concrete thing you shipped, and end with the release or docs URL so the click is obvious. Version numbers and repo detail can stay when they build credibility with a developer audience, but they are seasoning, not the headline.

The second decision is single post versus thread. Most releases are one post: a patch, a fix, a small feature. A meaningful launch - a new capability, a rewrite, a milestone - reads better as a short thread: the headline post, one or two posts on the why and the how, and a closing post with the link and a call to try it. Threads are where X beats every other channel for build-in-public momentum, because each post is a fresh chance to be seen and the thread tells a story a single post cannot. Whatever you automate has to be able to produce both shapes, or it will flatten every launch into the same generic line.

This is also why X is the natural home for building in public. Developers live there, releases are inherently timely, and a steady drumbeat of shipped-this posts compounds into an audience that watches your roadmap. If that is the game you are playing, the release is your best recurring content, and the whole point is to make posting it cheap enough that you never skip one. We go deeper on the practice itself in the build-in-public guide; here we are focused on the mechanics of getting the post out.

The manual path is straightforward. When you publish a release, you read the release notes, translate the changes into user value, write the post or thread in your own voice, and publish. Because you are the one writing, each post gets full attention, the tone is unmistakably human, and you decide in the moment whether this release deserves a single line or a thread. For a team that ships an X-worthy release every week or two, this is completely reasonable and often better than automation.

The reason manual posting breaks down is cadence, not difficulty. If you ship several times a week, the context switch starts to bite: you have to remember to do it, open the composer, re-read the release, rewrite it, and decide on the format, every single time. That friction is precisely what makes build-in-public quietly stop happening on busy sprints. The post that never gets written is the most common failure mode, and it is invisible because nothing breaks - the work just silently does not ship to your audience.

So treat the manual path as the honest starting point and watch for the signal that it is time to automate: you keep skipping posts you meant to write, or the rewriting is eating time you would rather spend building. When that signal arrives you have two automation options, and the next sections cover both with their real trade-offs, including the one cost every old tutorial forgets to mention.

A DIY automation runs in GitHub Actions and triggers on the release event. The workflow reads the release from the event payload and posts it to X. In practice most people do not hand-sign the OAuth 1.0a request themselves - they reach for a community action such as ethomson/send-tweet-action - because signing X API requests by hand is fiddly. The YAML below is a realistic version: it fires when a release is published and posts the tag plus the release URL.

The sketch is deliberately honest about the setup behind those four secrets. To fill them you create an X developer app, apply for the right access level, generate an API key and secret plus an access token and secret, and - this is the new part in 2026 - attach the app to a paid API plan, because there is no free write tier anymore. The workflow is twenty lines; getting to the point where those twenty lines can run is the actual project, and it now involves a billing decision, not just a token.

It is also worth being clear about what this workflow does not do. It posts a single line, so every launch looks the same and there is no threading. It publishes the moment the release fires, with no human reading the post first. There is no retry if X returns an error, no record tying the post back to the release, and no way for a non-engineer to change the copy without editing CI. For an internal experiment that is fine. For your public brand account, those gaps are exactly the things that make people nervous.

Here is the part that quietly broke the classic DIY recipe. X retired the old free posting tier, and in early 2026 it moved new developers to pay-per-use pricing by default: there is no free write tier to sign up for, and posting is billed per request. A plain post costs a small per-request fee, and - critically for release announcements - a post that contains a link costs meaningfully more per request than one without. Read that twice, because your release post almost always contains a link: the release URL is the entire point.

So the DIY math is not what the old tutorials imply. You are not automating for free; you are standing up a paid X developer app and paying per release you announce, at the higher link-bearing rate, for the rest of the automation's life. For a hobby repo that ships occasionally the cost is small in absolute terms, but it is no longer zero, and it comes with the developer-app application, the paid plan, and the token upkeep on top. Legacy fixed-price tiers still exist for developers who were already on them, but as a new build you are starting on metered pricing.

None of this means do not automate. It means price it honestly before you build, and compare like for like. The relevant comparison is not free DIY versus a paid tool - it is a paid X developer app plus the workflow you maintain, versus a tool that already carries a managed X connection and folds the posting into a plan. When you frame it that way, the DIY cost advantage that made the old recipe attractive is largely gone, and what is left is a question of who owns the plumbing.

The first gap is auth and billing lifecycle. X access tokens can be rotated or revoked, and the paid plan behind the app is now something to monitor - if the plan lapses or the token breaks, your release automation stops silently and you usually find out because someone notices the posts stopped, not because anything alerted you. Maintaining an authenticated, metered connection to a third-party API is a small but real ongoing responsibility, not a one-time setup.

The second gap is everything around the post that makes it safe and good on X. There is no approval step, so a premature or badly worded release note goes public instantly on your brand account. There is no threading, so every launch is flattened into one generic line and you lose the format that actually performs on X. There is no channel-native drafting, so you either post the raw tag or build and maintain your own templating. There is no retry on failure, no audit trail tying a post to its release, and no way for a marketer to tweak the copy without touching CI. Each of these is buildable; together they are a product, not a script.

This is not an argument against DIY. If you have one repo, one X account, an engineer who enjoys this, a tolerance for occasional silent breakage, and a paid API plan you are happy to run, a custom workflow is a legitimate choice. It is an argument for honesty about the cost. The deeper build-versus-buy trade-off - and where GitHub Actions is genuinely the right tool - is laid out in the GitHub Actions versus webhooks comparison; the short version is that Actions is excellent for CI and awkward as a brand-safe publishing pipeline.

A release-native tool inverts the trade-off. Instead of standing up a paid developer app and paying per release plus ongoing maintenance, you do a one-time connection and the per-release cost drops toward a quick approval click. S2P connects to your GitHub repository and to X through a managed connection, so the credential lifecycle and the API access sit behind the product rather than in your CI secrets and your billing dashboard. When you cut a release, it drafts an X post from the release notes in your brand voice - a single post for a routine ship, or a thread for a real launch - and routes it for approval before anything publishes.

That approval step is the substantive difference, not a nicety. A public account needs a human to confirm the post is accurate, on-message, and free of internal phrasing before it goes live, and the DIY path has nowhere for that human to stand. With a tool, the release fires the draft, a person reads and edits it in seconds, and only then does it publish - with the final post URL tied back to the release that created it. You also get the format X actually rewards: rules decide which releases are worth posting, and a big launch becomes a thread instead of a flattened one-liner. You keep editorial control; you lose the blank composer, the OAuth dance, and the metered-API babysitting.

The honest comparison is the same one this whole guide makes. If you ship rarely, post by hand. If you want full control and are happy to run a paid X app and own the workflow forever, build the DIY Action. If posting releases to X is a recurring part of how you grow and you would rather not maintain an X developer app and its bill, a release-native tool is the path that stays cheap as your cadence increases. If you are weighing S2P against an X-first scheduler, the Typefully versus S2P comparison lays out where a release trigger beats a content calendar.

Map it to your cadence and your appetite for plumbing. If you announce an X-worthy release every week or two, post by hand: it is free, fully controlled, and the rewrite is manageable. If you ship often, want automation, have an engineer who will own it, and are fine running a paid X developer app, the DIY GitHub Action is a legitimate build - just price the per-post API cost and the token upkeep honestly first. If release posting is central to how you grow and you would rather not run an X app or flatten your launches into one-liners, a release-native tool is the path that scales without adding maintenance.

The X-specific twist is the one this guide keeps returning to. On most channels the DIY route is at least free; on X in 2026 it is not, because there is no free write tier and link-bearing release posts sit at the higher per-request rate. That does not kill DIY, but it collapses the gap between rolling your own and using a tool: both now have a real cost, so the deciding factor is who maintains the plumbing and whether you want approval, threads, and an audit trail included. When posting releases to X is something you want to keep doing for years, the release-native path is usually the one that stays cheap in the way that matters - your time.

Whatever you choose, the goal is the same: make announcing a release cheap enough that you never skip one. That is the whole game with building in public on X. If you want the managed version of this exact workflow, the GitHub-to-X use case and the X integration show how S2P drafts, threads, and publishes, and pricing starts free so you can wire up one repo and one account before paying anything.