GitHub to Gmail, release notes delivered clean

Release notes are easy to ignore until they bite you. You hear “there’s a new version,” then you lose 20 minutes hunting the changelog, figuring out what changed, and wondering if your instance is behind.

This GitHub Gmail releases automation hits DevOps folks first, honestly. But agency owners running client automations and marketing ops teams living inside n8n feel the same chaos when upgrades sneak up. The outcome is simple: you get a clean email with the full release notes, plus the version you’re currently running, so you can decide fast.

Below, you’ll see how the workflow monitors “latest” and “beta,” deduplicates new versions, pulls GitHub notes, and emails everything to Gmail in a readable format.

How This Automation Works

The full n8n workflow, from trigger to final output:

n8n Workflow Template: GitHub to Gmail, release notes delivered clean

Click to explore

flowchart LR

    subgraph sg0["Scheduled Automation Start Flow"]
        direction LR
        n0@{ icon: "mdi:play-circle", form: "rounded", label: "Scheduled Automation Start", pos: "b", h: 48 }
        n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Define n8n URLs & Tags", pos: "b", h: 48 }
        n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Fetch Instance Version"]
        n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Retrieve Latest Release"]
        n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Retrieve Beta Release"]
        n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Combine Version Data"]
        n6@{ icon: "mdi:swap-vertical", form: "rounded", label: "Set Version Fields", pos: "b", h: 48 }
        n7@{ icon: "mdi:cog", form: "rounded", label: "Remove Duplicate Latest", pos: "b", h: 48 }
        n8@{ icon: "mdi:swap-vertical", form: "rounded", label: "Assign Latest Tag Data", pos: "b", h: 48 }
        n9@{ icon: "mdi:cog", form: "rounded", label: "Remove Duplicate Beta", pos: "b", h: 48 }
        n10@{ icon: "mdi:swap-vertical", form: "rounded", label: "Assign Beta Tag Data", pos: "b", h: 48 }
        n11["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Merge Release Streams"]
        n12["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Fetch GitHub Notes"]
        n13["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/markdown.dark.svg' width='40' height='40' /></div><br/>Render Notes as HTML"]
        n14@{ icon: "mdi:message-outline", form: "rounded", label: "Dispatch Email Alert", pos: "b", h: 48 }
        n11 --> n12
        n5 --> n6
        n0 --> n1
        n10 --> n11
        n6 --> n9
        n6 --> n7
        n8 --> n11
        n4 --> n5
        n2 --> n5
        n13 --> n14
        n3 --> n5
        n12 --> n13
        n9 --> n10
        n7 --> n8
        n1 --> n2
        n1 --> n3
        n1 --> n4
    end

    %% Styling
    classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
    classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
    classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef disabled stroke-dasharray: 5 5,opacity: 0.5
    class n0 trigger
    class n2,n3,n4,n12 api
    classDef customIcon fill:none,stroke:none
    class n2,n3,n4,n5,n11,n12,n13 customIcon

The Problem: Release updates get missed (or found too late)

Most teams don’t actually “monitor releases.” They stumble into them. Someone mentions a new n8n version in Slack, a bug shows up that was fixed last week, or you’re about to upgrade and realize you haven’t read release notes in months. Then comes the tab hopping: npm for version tags, GitHub for notes, your own instance to check what you’re running, and back to GitHub to see if anything breaking is buried in the text. It’s not hard work. It’s constant work, which makes it easy to postpone.

It adds up fast. And the friction compounds when you track both “latest” and “beta.”

Checking npm and GitHub manually turns into a weekly ritual that steals about an hour you never planned for.
Version comparisons are easy to get wrong when you’re juggling “latest,” “beta,” and your current instance version.
Release notes are long, so people skim, miss one line, and get surprised during upgrades.
Without a consistent alert, upgrades become reactive instead of planned, which increases downtime risk.

The Solution: GitHub → Gmail release notes, automatically

This workflow watches n8n releases on a schedule, detects what’s new, and sends you a Gmail message that’s actually readable. On each run, it pulls the current “latest” and “beta” version info from the npm registry, optionally checks your own n8n instance to see what version you’re running, and then filters out anything you’ve already been alerted about. If a new version is found, it grabs the matching GitHub release notes, converts the Markdown into clean HTML, and emails it to you as a styled notification. You’re no longer piecing together updates from three different places.

The workflow starts with a scheduled trigger. It collects version data for both channels, merges and standardizes it, then deduplicates so you only get alerted once per version. Finally, it fetches GitHub notes and sends a formatted Gmail email that includes the release name, version tag, your current version, and the full notes.

What You Get: Automation vs. Results

What This Workflow Automates

Results You’ll Get

Checks the npm registry for both “latest” and “beta” n8n releases on a schedule.
Optionally reads your running n8n instance version from your own URL.
Deduplicates releases so you are not spammed with repeat emails.
Pulls GitHub release notes and converts Markdown into an email-friendly layout.

Save about 1 hour a week of “did we miss a release?” checking.
Make upgrade calls faster because the notes arrive with context, not just a version number.
Catch breaking changes earlier, which means fewer surprise fixes during deploy windows.
Keep “beta” experiments separate from production decisions without extra tracking.
Build a simple audit trail in Gmail search (“n8n release”) when you need to review history.

Example: What This Looks Like

Say you check releases twice a week. Manually, you’ll usually open npm for “latest” and “beta” (about 10 minutes), open GitHub for notes (another 10 minutes), then log into your n8n instance or hit an endpoint to confirm your current version (about 10 minutes). That’s roughly 30 minutes per check, so about 1 hour a week. With this workflow, the “work” is basically zero: it runs on a schedule, and you skim a single email for a minute or two when something new ships.

What You’ll Need

n8n instance (try n8n Cloud free)
Self-hosting option if you prefer (Hostinger works well)
Gmail for sending the release alert email
GitHub as the source of release notes
Your n8n instance URL (set it in the “my_n8n_url” field)

Skill level: Beginner. You’ll connect Gmail, paste a URL (optional), and edit one recipient field.

Don’t want to set this up yourself? Talk to an automation expert (free 15-minute consultation).

How It Works

A schedule checks for updates. The workflow starts with a schedule trigger, so it can run hourly, daily, or whatever cadence you trust. If hourly feels noisy, change it.

Version info is pulled from the sources that matter. It fetches “latest” and “beta” version tags from the npm registry via HTTP Request, and it can also query your own n8n instance URL to capture your current running version.

Only genuinely new releases continue. The workflow merges the streams, normalizes fields, then removes duplicates so you don’t get the same alert every run. If there’s nothing new, it stops.

Release notes are fetched and emailed in a readable format. For each new version, it requests the GitHub release notes, renders the Markdown into HTML, then uses Gmail to send a styled notification with the version tag, release name, your current version, and the full notes.

You can easily modify the release channel tags to watch a different package or to ignore beta entirely based on your needs. See the full implementation guide below for customization options.

Step-by-Step Implementation Guide

Step 1: Configure the Schedule Trigger

Set the automation cadence so the workflow checks for new n8n releases on a regular interval.

Add or open Scheduled Automation Start.
Set the Rule interval field to hours (the workflow is configured to run hourly).
Save the node to ensure the schedule is active.

Step 2: Connect n8n Instance and Release Tags

Define your instance URL and which release channels to monitor.

Open Define n8n URLs & Tags.
Set my_n8n_url to your instance URL, for example https://YOUR_n8n_INSTANCE_LINK.
Set n8n_tag_1 to latest and n8n_tag_2 to beta.
Confirm the output of Define n8n URLs & Tags is connected to the version fetch nodes.

Define n8n URLs & Tags outputs to Fetch Instance Version, Retrieve Latest Release, and Retrieve Beta Release in parallel.

⚠️ Common Pitfall: Leaving https://YOUR_n8n_INSTANCE_LINK unchanged will cause Fetch Instance Version to fail with a 404 or unauthorized error.

Step 3: Fetch and Combine Version Data

Collect your current instance version and compare it with the latest and beta tags from npm.

In Fetch Instance Version, set URL to ={{ $json.my_n8n_url }}/rest/settings.
In Retrieve Latest Release, set URL to =https://registry.npmjs.org/n8n/{{ $json.n8n_tag_1 }}.
In Retrieve Beta Release, set URL to =https://registry.npmjs.org/n8n/{{ $json.n8n_tag_2 }}.
Configure Combine Version Data with Mode combine, Combine By combineByPosition, and Number Inputs 3.
In Set Version Fields, map versions using expressions: my_n8n_version = ={{ $json.body_1.data.versionCli }}, n8n_tag1_version = ={{ $json.body_2.version }}, and n8n_tag2_version = ={{ $json.body_3.version }}.

Tip: If your n8n instance requires authentication for /rest/settings, add the needed auth options inside Fetch Instance Version.

Step 4: Set Up Release Stream Routing and De-duplication

Prevent repeat notifications and package data for both release channels.

Open Remove Duplicate Latest and set Operation to removeItemsSeenInPreviousExecutions and Dedupe Value to ={{ $json.n8n_tag1_version }}.
Open Remove Duplicate Beta and set Operation to removeItemsSeenInPreviousExecutions and Dedupe Value to ={{ $json.n8n_tag2_version }}.
In Assign Latest Tag Data, map my_n8n_version = ={{ $json.my_n8n_version }}, n8n_tag = ={{ $('Define n8n URLs & Tags').item.json.n8n_tag_1 }}, and n8n_version = ={{ $json.n8n_tag1_version }}.
In Assign Beta Tag Data, map my_n8n_version = ={{ $json.my_n8n_version }}, n8n_tag = ={{ $('Define n8n URLs & Tags').item.json.n8n_tag_2 }}, and n8n_version = ={{ $json.n8n_tag2_version }}.
Verify Merge Release Streams receives input from both tag assignment nodes.

Set Version Fields outputs to both Remove Duplicate Beta and Remove Duplicate Latest in parallel.

Step 5: Fetch Release Notes and Format the Email

Pull release notes from GitHub and convert them to HTML for the email body.

In Fetch GitHub Notes, set URL to =https://api.github.com/repos/n8n-io/n8n/releases/tags/n8n@{{ $json.n8n_version }}.
In Render Notes as HTML, set Mode to markdownToHtml and Markdown to ={{ $json.body }}.
Confirm Render Notes as HTML connects to Dispatch Email Alert.

Tip: If GitHub API rate limits you, consider adding an authenticated GitHub request to Fetch GitHub Notes.

Step 6: Configure the Email Output

Send the formatted release notification to your inbox.

Open Dispatch Email Alert.
Credential Required: Connect your gmailOAuth2 credentials.
Set Send To to your email address (replace [YOUR_EMAIL]).
Keep the HTML Message template as provided to include release notes, tags, and version details.
Set the Subject to =⚡ n8n New ({{ $('Merge Release Streams').item.json.n8n_tag }}) Version Released! [{{ $json.name }}].

⚠️ Common Pitfall: If [YOUR_EMAIL] is not replaced, the email will fail to send or go to an invalid recipient.

Step 7: Test and Activate Your Workflow

Validate the full flow and then enable it for ongoing monitoring.

Click Execute Workflow to run the automation manually.
Confirm the parallel branches run: Define n8n URLs & Tags should trigger Fetch Instance Version, Retrieve Latest Release, and Retrieve Beta Release simultaneously.
Check that Dispatch Email Alert sends an email containing the release version, tag, and HTML-rendered notes.
If the output is correct, toggle the workflow to Active to enable scheduled execution.

🔒

Unlock Full Step-by-Step Guide

Get the complete implementation guide + downloadable template

Common Gotchas

Gmail credentials can expire or require the right Google permissions. If emails stop sending, check the Gmail node’s connected account in n8n first.
If you add Wait nodes later (or GitHub is slow), processing times vary. Bump up the wait duration if downstream nodes fail on empty responses.
Markdown-to-HTML output can look “off” if a release note uses unusual formatting. Adjust the email template in the Gmail node so your headings and code blocks render cleanly.

Frequently Asked Questions

How long does it take to set up this GitHub Gmail releases automation?

About 20 minutes if Gmail is ready to connect.

Do I need coding skills to automate GitHub release notifications to Gmail?

No. You’ll connect Gmail and edit a couple of fields in n8n. The logic is already built.

Is n8n free to use for this GitHub Gmail releases workflow?

Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in normal email sending limits on your Gmail account.

Where can I host n8n to run this GitHub Gmail releases automation?

Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.

Can I customize this GitHub Gmail releases workflow for a different repo or package?

Yes, but you’ll want to change it in two places. Update the “Define n8n URLs & Tags” Set node to point at the package/tag you want, then adjust the GitHub notes HTTP Request node to fetch release notes from the right repository. Common tweaks include monitoring only “latest,” changing the schedule to daily, and adding a second notification destination like Telegram alongside Gmail.

Why is my Gmail connection failing in this workflow?

Usually it’s expired or revoked Google permissions. Reconnect the Gmail credential in n8n, then confirm the Gmail node is using the correct account. If you’re in a company Google Workspace, an admin policy can also block access. Finally, check Gmail sending limits if you’re testing with lots of runs in a short time.

How many releases can this GitHub Gmail releases automation handle?

A lot for typical use, because releases are low volume and deduped.

Is this GitHub Gmail releases automation better than using Zapier or Make?

Often, yes, because this workflow benefits from multi-step branching, deduplication, and formatting that’s easier to control in n8n. Zapier or Make can do “new release → email,” but you may end up bolting on extra steps for parsing, HTML formatting, and handling both latest and beta cleanly. n8n also gives you a self-hosted option, which matters if you run lots of automations and don’t want per-task pricing. If you already live in Zapier and only need a basic ping, it might be enough. If you want the cleaner end-to-end setup, Talk to an automation expert and we’ll point you the right way.

Once this is running, release awareness becomes automatic. You get clean notes in Gmail, make the call, and get back to real work.

GitHub to Gmail, release notes delivered clean

How This Automation Works

n8n Workflow Template: GitHub to Gmail, release notes delivered clean

The Problem: Release updates get missed (or found too late)