Coolify + GitHub: updates checked, redeploys handled
Checking versions is the kind of “quick task” that quietly steals your week. You log into your server, open GitHub releases, compare strings, then decide if you should redeploy. And somehow you still find out you were behind after something breaks.
Self-hosted admins feel this the most. But agency owners running client automations and ops leads responsible for uptime get dragged into it too. This Coolify GitHub automation keeps your n8n deployment current without you babysitting release pages.
You’ll see how the workflow checks your live n8n version, compares it to the latest stable GitHub release, and only triggers a Coolify redeploy when there’s actually something new to install.
How This Automation Works
The full n8n workflow, from trigger to final output:
n8n Workflow Template: Coolify + GitHub: updates checked, redeploys handled
flowchart LR
subgraph sg0["Schedule every time you want start the update check Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule every time you want..", pos: "b", h: 48 }
n1@{ icon: "mdi:cog", form: "rounded", label: "No Operation, do nothing", pos: "b", h: 48 }
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If the 2 versions is not the..", pos: "b", h: 48 }
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/>CALL COOLIFY OR SIMILAR SERV.."]
n4@{ icon: "mdi:swap-vertical", form: "rounded", label: "Rename variable and unify fo..", pos: "b", h: 48 }
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/>Merge bot data and pass just.."]
n6@{ icon: "mdi:play-circle", form: "rounded", label: "When clicking ‘Execute workf..", pos: "b", h: 48 }
n7["<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/>CALL YOUR N8N INSTANCE and r.."]
n8["<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/>CALL GITHUB and retrieve the.."]
n4 --> n2
n6 --> n8
n6 --> n7
n5 --> n4
n7 --> n5
n0 --> n7
n0 --> n8
n2 --> n3
n2 --> n1
n8 --> n5
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,n6 trigger
class n2 decision
class n3,n7,n8 api
classDef customIcon fill:none,stroke:none
class n3,n5,n7,n8 customIcon
The Problem: Version checks turn into a reliability tax
Keeping a self-hosted n8n instance updated sounds simple until you’re the one responsible for it. The “routine” usually looks like this: someone remembers updates exist, checks the current version inside n8n, opens GitHub releases, then debates whether a redeploy is worth the risk right now. You lose time, you lose focus, and frankly you lose confidence because it’s never truly done. Miss a release and you can end up stuck debugging an issue that was already fixed upstream. Do it too often and you burn hours redeploying when nothing changed.
The friction compounds, especially once this becomes part of your ops rhythm.
- You end up doing the same comparison dance every few days, even when there’s no update to apply.
- Version strings don’t always match your memory, so you double-check, then triple-check.
- Manual redeploys tend to happen at the worst time, because that’s when you finally notice you’re behind.
- When multiple people can redeploy, the process gets inconsistent and small mistakes creep in.
The Solution: Compare GitHub releases, then redeploy only when needed
This workflow automates the boring part of “staying updated” while keeping the decision logic straightforward. It starts on a schedule (or you can kick it off manually) and pulls two facts from two places. First, it asks your running n8n instance what version it is using by calling the /rest/settings endpoint and reading the versionCli value. Then it checks GitHub for the latest n8n stable release and grabs the release name. Those two values are normalized into comparable fields, then an IF check decides what happens next. If the versions match, the workflow ends without touching your deployment. If they don’t match, it calls the Coolify API and triggers a forced redeploy for your n8n app.
The workflow starts when the schedule runs (or you hit Manual Run). It fetches your current version and the newest GitHub release in parallel, merges the data, and compares it. If it’s behind, Coolify redeploys. If not, nothing changes.
What You Get: Automation vs. Results
| What This Workflow Automates | Results You’ll Get |
|---|---|
|
|
Example: What This Looks Like
Say you check for updates twice a week. A “quick look” often turns into 20 minutes: log in, confirm your versionCli, open GitHub releases, compare, then decide if you’ll redeploy now or later. That’s about 40 minutes weekly, and it gets worse when you postpone and re-check. With this workflow, the scheduled run takes a minute or two in the background, and redeploy only happens when there’s a real mismatch. Most weeks, you get your time back and avoid unnecessary restarts.
What You’ll Need
- n8n instance (try n8n Cloud free)
- Self-hosting option if you prefer (Hostinger works well)
- Coolify to manage and redeploy your app.
- GitHub to read the latest n8n release.
- Coolify API token (create it in Coolify settings).
Skill level: Intermediate. You’ll paste a few URLs, add a Bearer token credential, and confirm your n8n endpoint is reachable.
Don’t want to set this up yourself? Talk to an automation expert (free 15-minute consultation).
How It Works
A schedule (or manual run) kicks things off. Use the built-in schedule trigger for hands-off checks, then keep the manual trigger available when you want to test changes safely.
Your running n8n instance reports its current version. An HTTP Request calls https://your-n8n-domain/rest/settings and reads the versionCli field, which is the value you’d normally compare by hand.
GitHub provides the newest stable release name. Another HTTP Request hits the GitHub releases endpoint for n8n, then the workflow merges the two values and normalizes them into simple comparison fields.
Coolify redeploys only when it should. An IF check compares “current” vs “latest”. If they differ, a final HTTP Request calls Coolify’s API for a forced redeploy of the app UUID; if they match, the workflow ends as a no-op.
You can easily modify the matching logic to ignore patch versions 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 up the automated and manual triggers that start the version check workflow.
- Add and open Scheduled Update Check, then define your schedule under Rule to match your update cadence.
- Add Manual Run Start to allow on-demand testing and manual checks.
- Connect triggers so that Scheduled Update Check outputs to both Fetch Instance Version and Retrieve Latest Release in parallel.
- Connect Manual Run Start so it outputs to both Retrieve Latest Release and Fetch Instance Version in parallel.
Step 2: Connect Version Data Sources
Configure the HTTP requests that pull your instance version and the latest public release.
- Open Fetch Instance Version and set URL to
https://[YOUR_ID]/rest/settings. - Open Retrieve Latest Release and set URL to
https://api.github.com/repos/n8n-io/n8n/releases/latest. - Verify that both nodes connect into Combine Version Data (input 1 for Fetch Instance Version, input 2 for Retrieve Latest Release).
[YOUR_ID] with your actual instance and service identifiers, or the request will fail.Step 3: Set Up Version Normalization and Comparison
Merge the two version sources, normalize fields, and compare versions to decide if an update is needed.
- Open Combine Version Data and set Mode to
combineBySql. - Set the Query to
SELECT\n input1.data->versionCli AS versionCli,\n input2.name AS name\nFROM input1\nLEFT JOIN input2 ON 1=1;. - In Normalize Version Fields, add assignments for actualn8nversion with
={{ $json.versionCli }}and newn8nversion with={{ $json.name.split("@")[1] }}. - In Compare Version Strings, configure the condition to compare leftValue
={{ $json.actualn8nversion }}with rightValue={{ $json.newn8nversion }}using the notEquals operator.
Step 4: Configure Update Actions
Trigger a restart when versions differ, or skip if the instance is up-to-date.
- Connect the true output of Compare Version Strings to Trigger Deployment Restart.
- Connect the false output of Compare Version Strings to Skip Update Action for a no-op path.
- In Trigger Deployment Restart, set URL to
https://[YOUR_ID]/api/v1/services/[YOUR_ID]/restart?latest=true. - Credential Required: Connect your httpBearerAuth credentials in Trigger Deployment Restart.
Step 5: Test and Activate Your Workflow
Validate the workflow manually, then activate it for scheduled runs.
- Click Execute Workflow with Manual Run Start to verify that version data is fetched and merged.
- Confirm that Compare Version Strings routes to Trigger Deployment Restart only when versions differ and to Skip Update Action when they match.
- Check the HTTP responses in Fetch Instance Version and Retrieve Latest Release for valid JSON payloads.
- Turn on the workflow using the Active toggle so Scheduled Update Check runs automatically.
Common Gotchas
- Coolify credentials can expire or need specific permissions. If things break, check your Coolify API token and the Bearer credential in n8n 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 once you have your Coolify token and URLs ready.
No. You’ll mainly paste endpoints, connect credentials, and test a manual run. The “logic” is already built into the workflow’s compare step.
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 API costs, which are usually $0 here because GitHub and Coolify calls are simple.
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 do it intentionally. You can adjust the normalization step (the “Normalize Version Fields” Set node) to trim versions like 1.23.4 down to 1.23, then keep the IF comparison the same. Another common tweak is changing what you treat as “latest” by pulling a different GitHub field if your org uses tags differently. Some teams also add a Send Email node after the compare so a redeploy never happens silently.
Usually it’s an expired or incorrect API token stored in your n8n Bearer credential. It can also be the wrong Coolify API URL (domain or app UUID), or a network rule blocking n8n from reaching Coolify. If the call works in Postman/curl but not in n8n, check headers and confirm the credential is attached to the right HTTP Request node.
A lot, since it only redeploys when versions change.
For this use case, n8n is typically a better fit because it handles multi-step logic (merge, normalize, compare, conditional deploy) without feeling like you’re fighting the platform. Self-hosting also matters here; you can run checks as often as you want without worrying about task pricing. Zapier or Make can still do it, but you’ll often end up with extra steps to format data and compare version strings cleanly. If you want approvals, retries, and fallback notifications, n8n stays readable as the workflow grows. Talk to an automation expert if you want help choosing the simplest path for your setup.
Once this is running, “are we up to date?” stops being a question you have to hold in your head. The workflow handles the repetitive checking and only pulls the redeploy lever when it matters.
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.
