GitHub to Coolify, deploy updates without chasing tags
You spot a new release, tell yourself you’ll deploy it “later,” and then two weeks pass. Now you’re behind, the change log is a mystery, and updating feels risky because you can’t remember what changed since your last deploy.
DevOps leads feel this during maintenance windows. A solo founder running production on a small VPS feels it at 11pm. And agency teams managing client infrastructure? Same headache, more stakes. This GitHub Coolify deployment automation keeps your Coolify app on the right n8n version without manual tag copying.
Below you’ll see what the workflow does, what you need, and how to use it safely so updates happen cleanly and predictably.
How This Automation Works
The full n8n workflow, from trigger to final output:
n8n Workflow Template: GitHub to Coolify, deploy updates without chasing tags
flowchart LR
subgraph sg0["Auto Update Latest Release Flow"]
direction LR
n0["<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/>Get Release"]
n1["<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/>Update ENV"]
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/>Deploy"]
n3@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Filter", pos: "b", h: 48 }
n4@{ icon: "mdi:cog", form: "rounded", label: "Limit", pos: "b", h: 48 }
n5@{ icon: "mdi:cog", form: "rounded", label: "Remove Duplicates", pos: "b", h: 48 }
n6["<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/>Get Releases"]
n7@{ icon: "mdi:play-circle", form: "rounded", label: "Auto Update Latest Release", pos: "b", h: 48 }
n8@{ icon: "mdi:play-circle", form: "rounded", label: "Auto Update Beta Release", pos: "b", h: 48 }
n4 --> n5
n3 --> n4
n1 --> n2
n0 --> n5
n6 --> n3
n5 --> n1
n8 --> n6
n7 --> n0
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 n7,n8 trigger
class n3 decision
class n0,n1,n2,n6 api
class n7 disabled
classDef customIcon fill:none,stroke:none
class n0,n1,n2,n6 customIcon
The Problem: Deploying updates turns into a tag-chasing ritual
Keeping an app current sounds simple until you do it repeatedly. You check GitHub releases, compare versions, copy a tag into Coolify, and hope you didn’t grab the wrong one (beta vs stable, or a prerelease with a similar name). Then you trigger a deploy, wait, and realize you deployed the same version you already had because you forgot what ran last week. Multiply that by multiple environments or multiple client apps, and the mental overhead gets bigger than the deploy itself. Honestly, the busywork is what causes the “we’ll update later” backlog.
The friction compounds. Here’s where it breaks down in real life.
- Release monitoring becomes a manual habit, so it slips during busy weeks.
- Copying version tags into environment variables invites small mistakes that cause big downtime.
- Deploying twice for the same release happens more than anyone admits, especially when several people touch the stack.
- Beta testing is hard to do safely because prereleases arrive often and you can’t babysit every update.
The Solution: GitHub release monitoring that updates Coolify and deploys automatically
This workflow watches GitHub for new n8n releases, picks the track you want (beta prereleases or stable releases), and then handles the “last mile” inside Coolify for you. When a new release appears, it parses the version from the release name, updates your Coolify application’s environment variable (specifically N8N_VERSION), and triggers a deployment via Coolify’s API. It also deduplicates releases so you don’t redeploy the same version twice, which is a quiet but huge quality-of-life improvement. The end result is simple: your deployed n8n stays current, with less oversight and fewer opportunities for human error.
The workflow starts on a schedule (every minute for betas, and hourly for stable if you enable it). It pulls release data from GitHub, filters it down to what you care about, and only then updates Coolify and triggers a deploy.
What You Get: Automation vs. Results
| What This Workflow Automates | Results You’ll Get |
|---|---|
|
|
Example: What This Looks Like
Say you run n8n on Coolify and you like staying current on beta releases for testing. Manually, you might spend about 10 minutes per release checking GitHub, copying the version into Coolify, and triggering the deploy (and then doing a quick sanity check). If betas drop a few times a week, that’s roughly an hour of tiny interruptions. With this workflow, your “work” is basically zero after setup: GitHub gets checked every minute, the version updates automatically, and Coolify deploys without you chasing tags.
What You’ll Need
- n8n instance (try n8n Cloud free)
- Self-hosting option if you prefer (Hostinger works well)
- GitHub to read n8n release data.
- Coolify to update env vars and deploy.
- Coolify API token (generate it in Coolify’s API/settings area).
Skill level: Intermediate. You’ll paste an API token, replace an application UUID, and do a quick test run.
Don’t want to set this up yourself? Talk to an automation expert (free 15-minute consultation).
How It Works
Schedules kick things off. The beta track checks for prereleases every minute. The stable track checks hourly, but it’s disabled by default so you can decide when you’re ready.
GitHub releases are fetched and cleaned up. The workflow pulls a release list (beta) or the latest release (stable), filters to the right release type, caps how many items to consider, then removes duplicates so only genuinely new versions move forward.
The version is extracted and applied in Coolify. Once the workflow has a “new” release, it parses the semantic version (like 1.34.0) and updates your Coolify application’s environment variables so N8N_VERSION matches that release.
A deployment is triggered automatically. After the environment variable update, the workflow calls Coolify’s API to initiate a deploy, so the new version is actually running rather than just sitting in configuration.
You can easily modify the schedule frequency to match your tolerance for change, so updates happen when you want them. See the full implementation guide below for customization options.
Step-by-Step Implementation Guide
Step 1: Configure the Schedule Triggers
Set up the two schedule-based entry points that check for latest releases and beta releases.
- Open Latest Schedule Trigger and set the interval rule to run every hour in Rule → Interval → Field
hours. - Open Beta Schedule Trigger and define the interval rule you want under Rule → Interval.
- Ensure both triggers are connected to their downstream nodes: Latest Schedule Trigger → Fetch Latest Release and Beta Schedule Trigger → Fetch Release List.
Step 2: Connect GitHub Release Data Sources
Configure the HTTP requests that pull release data from GitHub.
- In Fetch Latest Release, set URL to
https://api.github.com/repos/n8n-io/n8n/releases/latest. - Enable Send Query Parameters and add per_page with value
10. - In Fetch Release List, set URL to
https://api.github.com/repos/n8n-io/n8n/releasesand set per_page to10.
Step 3: Set Up Release Filtering and De-duplication
Filter beta releases, limit the batch size, and prevent duplicate deployments.
- In Apply Release Filter, add a boolean condition where Left Value is
={{ $json.prerelease }}and the operator is true. - Keep Cap Records after the filter to constrain processing to a limited number of items.
- In Eliminate Repeats, set Operation to
removeItemsSeenInPreviousExecutionsand Dedupe Value to={{ $json.name }}.
Step 4: Configure Deployment Actions
Update environment variables and trigger the deployment in your deployment console.
- Open Modify Environment Vars and set URL to
=https://console.buatan.id/api/v1/applications/{{ '[YOUR_ID]' }}/envs. - Set Method to PATCH and enable Send Body.
- Add body parameters: key
N8N_VERSION, value={{ $json.name.split('@').last() }}, is_preview={{ false }}, is_build_time={{ true }}, and is_literal={{ false }}. - Credential Required: Connect your httpBearerAuth or httpHeaderAuth credentials in Modify Environment Vars.
- Open Initiate Deployment and set URL to
=https://console.buatan.id/api/v1/deploy?uuid={{ '[YOUR_ID]' }}&force=false. - Credential Required: Connect your httpBearerAuth or httpHeaderAuth credentials in Initiate Deployment.
[YOUR_ID] in both URLs with your actual application UUID before testing.Step 5: Test and Activate Your Workflow
Verify each path works before enabling production schedules.
- Click Execute Workflow and manually trigger Latest Schedule Trigger to test the latest-release path.
- Confirm that Fetch Latest Release returns data, Eliminate Repeats allows new items, and Modify Environment Vars receives the new version value.
- Run a second test with Beta Schedule Trigger to validate Fetch Release List → Apply Release Filter → Cap Records flow.
- Check that Initiate Deployment responds successfully, indicating a deployment request was sent.
- Enable the schedules for production by activating the workflow and ensuring the triggers are not disabled.
Common Gotchas
- Coolify credentials can expire or need specific permissions. If things break, check your Coolify API token and header auth configuration in n8n credentials first.
- If you’re using Wait nodes or external rendering, processing times vary. Bump up the wait duration if downstream nodes fail on empty responses.
- Default prompts in AI nodes are generic. Add your brand voice early or you’ll be editing outputs forever.
Frequently Asked Questions
About 30 minutes if you already have your Coolify API token and application UUID.
No. You’ll mainly paste credentials and replace the Coolify application UUID in two nodes.
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 Coolify hosting costs (your VPS) since this workflow calls the Coolify API.
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.
Yes, but you’ll need to enable the stable schedule trigger and keep the beta trigger disabled. In practice, you toggle the node that checks the latest stable release hourly, then confirm the filter logic isn’t allowing prereleases through. Common customizations include changing the check frequency, updating a different environment variable than N8N_VERSION, or pointing the same flow at a second Coolify application UUID for staging.
Most of the time it’s an API token problem. Regenerate your Coolify token, make sure it’s being sent in the header auth credentials, then confirm the Coolify base URL in your HTTP Request nodes is correct. If the UUID is wrong, Coolify may return a “not found” style response that looks like an auth issue. Rate limiting is rare here, but it can happen if you’re checking too aggressively across many apps.
A lot more than you’ll realistically need. On n8n Cloud Starter, you’re limited by monthly executions, so checking every minute can add up if you run it 24/7. If you self-host, there’s no execution cap and the practical limit becomes your server resources and how many separate apps you monitor. This workflow also caps and deduplicates releases, which keeps runs lightweight even if GitHub returns a longer release list.
Often, yes. Zapier and Make can monitor GitHub, but this workflow benefits from n8n’s more flexible filtering and duplicate handling, which means fewer accidental redeploys. Coolify API calls also tend to be easier to model in n8n because you can shape requests and responses without fighting templates. The self-hosting option matters too if you want frequent checks without paying per task. If you want help choosing the cleanest setup for your stack, Talk to an automation expert.
Once this is running, “keeping current” becomes background noise instead of a recurring task. Set it up, test it, then spend your attention on work that actually moves things forward.
Need Help Setting This Up?
Our automation experts can build and customize this workflow for your specific needs. Free 15-minute consultation—no commitment required.
