How to post GitHub releases to Discord

Discord channels can generate an incoming webhook, which is a unique URL that accepts a JSON payload and turns it into a message in that channel. There is no app to register, no OAuth flow, and no token to refresh. You create the webhook in the channel settings, copy the URL, store it as a secret, and POST to it. That is the entire auth story, which is why for Discord the honest recommendation is to start with the webhook rather than reach for a tool.

To create one, open your Discord server, go to the target channel's settings, choose Integrations, then Webhooks, and create a new webhook. You can name it and give it an avatar so messages look intentional, then copy its URL. Treat that URL like a password - anyone who has it can post to your channel - so store it as a repository secret, never in committed code. With the URL in hand, the rest is a single HTTP POST.

From there you have two equally valid ways to fire the POST when a release publishes: a GitHub Actions workflow that runs on the release event, or any script or service that calls the webhook with curl. The next two sections give you a correct, copy-ready version of each. Both are real and both work; pick based on whether you want it living in your CI or in your own backend.

This workflow triggers when a release is published, then sends a Discord message containing the release name, its notes, and a link back to the release on GitHub. It reads the values straight from the release event payload, so you do not have to hardcode anything per release. Store your webhook URL as a repository secret named DISCORD_WEBHOOK_URL and the workflow does the rest.

The payload uses Discord's embed format, which renders as a tidy card with a title, a description, and a clickable link rather than a wall of plain text. Embeds are the difference between a release post that looks deliberate and one that looks like log spam. The content field is left empty here on purpose, which matters for mention etiquette - we cover why in a moment - but the embed carries the actual announcement. The jq step safely turns the release body into a valid JSON string so newlines and quotes do not break the payload.

This recipe is correct and minimal. It has no approval step and no multi-channel routing, which is fine for a community or internal channel where an automatic, dependable release feed is exactly what people want. If you later need a human to review the post or want the same release to also reach LinkedIn or X with channel-appropriate copy, that is the point where a release-native tool starts to earn its place over the raw webhook.

You do not need GitHub Actions to use a webhook. Any environment that can make an HTTP request can post to Discord, which makes this trivial to test from your terminal or wire into an existing service that already hears about your releases. The minimal version is a single POST with a content field; the nicer version uses an embed exactly like the Action above.

Here is the smallest possible working example. Replace the URL with your real webhook and run it - a message appears in the channel immediately. This is also the fastest way to confirm your webhook URL is valid before you build anything around it. If this works, the GitHub Actions recipe above will work too, because it is the same POST with the values filled in from the release event.

Once you have confirmed the basic POST, upgrade to an embed for anything user-facing. A bare content string is fine for a quick internal ping, but a titled, linked embed reads as an intentional announcement and gives readers a one-click path to the full release notes. Keep the content field empty unless you actually intend to ping people, for the etiquette reasons in the next section.

A webhook is a one-way pipe: it posts messages and nothing more. That is perfect for a release feed, because posting a release into a channel is inherently one-way. It is simple, has no auth lifecycle, and cannot do anything beyond send messages, which is also a security benefit - a leaked webhook URL can spam one channel, not control your server. For the overwhelming majority of release announcements, a webhook is the correct tool and a bot is overkill.

A bot is a full Discord application with a token, permissions, and the ability to read messages, respond to commands, manage roles, and interact with users. You want a bot when the release post needs to do more than appear: reacting to user commands, posting into threads programmatically, gating announcements behind roles, or integrating releases into a richer community workflow. That power comes with real cost - registering an application, managing a bot token, hosting the bot process, and handling the gateway connection - so only take it on when the interaction justifies it.

The simple rule: if you only need releases to show up in a channel, use a webhook. If you need the release post to participate in conversations or respond to users, use a bot. Do not build and host a bot just to send a message a webhook could send. Choosing the heavier tool when the lighter one fits is a common way to create maintenance you did not need.

Discord mentions are powerful and easy to abuse. An everyone or here notification interrupts every member, and using it for every routine release trains your community to mute the channel - which defeats the purpose of posting there at all. The recipes above deliberately leave the content field empty and put the announcement in an embed precisely so the message lands without pinging anyone. A release showing up in a dedicated releases channel is enough; people who care will see it.

Reserve mentions for genuinely mention-worthy moments. A major release, a security fix that requires action, or a breaking change that affects everyone can justify a ping - and even then, a role mention like a self-assigned releases role is far better than an everyone ping, because only people who opted in get interrupted. The etiquette is the same as the broader cadence principle: protect attention as a finite budget, because if every post pings, people stop reading the one that matters.

A practical setup is a dedicated channel for your automated release feed with no pings, plus a sparing role mention for the rare release that truly needs immediate attention. This keeps the automatic firehose useful without making it annoying, and it respects the difference between here is what we shipped and you need to act on this now.

The DIY webhook is the right answer for an automatic, no-review release feed into a single Discord channel, and this guide recommends it for exactly that. Its limits show up when your needs grow past that one job. There is no approval step, so whatever the workflow builds posts instantly - fine for a community releases channel, riskier if the same content represents your brand. And a webhook only knows about Discord, so if you also want the release on LinkedIn, X, or Bluesky with copy that fits each, you are back to maintaining a separate path per channel.

This is where a release-native tool complements rather than replaces the webhook idea. S2P detects your GitHub release once and can draft channel-native posts for Discord and your other destinations together, then route them through approval before anything publishes. You get the same instant-from-release behavior, but with a human able to glance at the post first and with one release fanning out to every channel in the right voice, instead of a webhook per platform and no review anywhere.

The honest split mirrors the rest of our how-to guides. If you want a dependable release feed in one Discord channel and nothing more, the webhook recipe above is genuinely the best tool and you should use it. If you want approval, multiple channels from one release, and a record of what went where, that is the job a release-native tool is built for. Many teams do both: a raw webhook for an internal channel, and S2P for the public, multi-channel announcements that need review.