Att kontrollera versioner är den typen av ”snabb uppgift” som i tysthet stjäl din vecka. Du loggar in på din server, öppnar GitHub-releaser, jämför strängar och bestämmer sedan om du ska deploya om. Och på något sätt får du ändå reda på att du låg efter först efter att något går sönder.
Admins som self-hostar känner det här mest. Men även byråägare som kör kundautomationer och driftansvariga med ansvar för upptid dras in i det. Den här Coolify GitHub-automationen håller din n8n-deployment uppdaterad utan att du behöver sitta och bevaka release-sidor.
Du får se hur workflowet kontrollerar din aktiva n8n-version, jämför den med den senaste stabila GitHub-releasen och bara triggar en Coolify-omdeploy när det faktiskt finns något nytt att installera.
Så fungerar den här automationen
Hela n8n-workflowet, från trigger till slutligt resultat:
n8n Workflow Template: Coolify + GitHub: kontroll av uppdateringar, omdriftsättning
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
Problemet: versionskontroller blir en driftskatt
Att hålla en self-hostad n8n-instans uppdaterad låter enkelt tills det är du som ansvarar för det. ”Rutinen” brukar se ut så här: någon kommer på att uppdateringar finns, kontrollerar aktuell version i n8n, öppnar GitHub-releaser och funderar sedan på om en omdeploy är värd risken just nu. Du tappar tid, du tappar fokus och ärligt talat tappar du förtroende eftersom det aldrig blir helt ”klart”. Missar du en release kan du fastna i felsökning av ett problem som redan har fixats uppströms. Gör du det för ofta bränner du timmar på omdeploys när inget har ändrats.
Friktionen växer, särskilt när det här blir en del av ditt driftflöde.
- Du gör samma jämförelsedans varannan eller var tredje dag, även när det inte finns någon uppdatering att applicera.
- Versionssträngar matchar inte alltid det du tror att du minns, så du dubbelkollar och sedan trippelkollar.
- Manuella omdeploys tenderar att ske vid sämsta möjliga tillfälle, eftersom det är då du till slut upptäcker att du ligger efter.
- När flera personer kan deploya om blir processen inkonsekvent och små misstag smyger sig in.
Lösningen: jämför GitHub-releaser och deploya bara om när det behövs
Det här workflowet automatiserar den tråkiga delen av att ”hålla sig uppdaterad” samtidigt som beslutslogiken hålls enkel. Det startar enligt ett schema (eller så kan du köra det manuellt) och hämtar två fakta från två ställen. Först frågar det din körande n8n-instans vilken version den använder genom att anropa endpointen /rest/settings och läsa värdet versionCli. Sedan kontrollerar det GitHub efter senaste stabila n8n-release och hämtar releasens namn. De två värdena normaliseras till jämförbara fält, och sedan avgör en IF-kontroll vad som händer härnäst. Om versionerna matchar avslutas workflowet utan att röra din deployment. Om de inte matchar anropar det Coolify API och triggar en tvingad omdeploy för din n8n-app.
Workflowet startar när schemat körs (eller när du trycker på Manuell körning). Det hämtar din nuvarande version och den senaste GitHub-releasen parallellt, slår ihop datan och jämför. Om du ligger efter gör Coolify en omdeploy. Om inte ändras ingenting.
Det du får: automation vs. resultat
| Vad det här workflowet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du kontrollerar uppdateringar två gånger i veckan. En ”snabb koll” blir ofta 20 minuter: logga in, bekräfta din versionCli, öppna GitHub-releaser, jämför och bestäm om du ska deploya om nu eller senare. Det är cirka 40 minuter i veckan, och det blir värre när du skjuter upp och kollar igen. Med det här workflowet tar den schemalagda körningen en minut eller två i bakgrunden, och omdeploy sker bara när det faktiskt finns en mismatch. De flesta veckor får du tillbaka din tid och slipper onödiga omstarter.
Det här behöver du
- n8n-instans (prova n8n Cloud gratis)
- Self-hosting-alternativ om du föredrar det (Hostinger fungerar bra)
- Coolify för att hantera och deploya om din app.
- GitHub för att läsa senaste n8n-release.
- Coolify API-token (skapa den i Coolify-inställningarna).
Kunskapsnivå: Mellan. Du klistrar in några URL:er, lägger till en Bearer-token-inloggning och bekräftar att din n8n-endpoint går att nå.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
Ett schema (eller manuell körning) drar igång. Använd den inbyggda schematriggern för hands-off-kontroller och behåll den manuella triggern när du vill testa ändringar på ett säkert sätt.
Din körande n8n-instans rapporterar sin aktuella version. En HTTP Request anropar https://your-n8n-domain/rest/settings och läser fältet versionCli, vilket är värdet du normalt skulle jämföra för hand.
GitHub ger namnet på senaste stabila release. En annan HTTP Request anropar GitHub-endpointen för n8n-releaser, sedan slår workflowet ihop de två värdena och normaliserar dem till enkla jämförelsefält.
Coolify deployar om bara när det ska. En IF-kontroll jämför ”nuvarande” vs ”senaste”. Om de skiljer sig anropar en sista HTTP Request Coolifys API för en tvingad omdeploy av appens UUID; om de matchar avslutas workflowet som ett no-op.
Du kan enkelt justera matchningslogiken för att ignorera patchversioner utifrån dina behov. Se hela implementationsguiden nedan för alternativ för anpassning.
Steg-för-steg-implementeringsguide
Steg 1: Konfigurera schematriggern
Konfigurera de automatiska och manuella triggers som startar arbetsflödet för versionskontroll.
- Lägg till och öppna Scheduled Update Check och definiera sedan ert schema under Rule så att det matchar er uppdateringstakt.
- Lägg till Manual Run Start för att möjliggöra tester vid behov och manuella kontroller.
- Koppla triggers så att Scheduled Update Check skickar utdata till både Fetch Instance Version och Retrieve Latest Release parallellt.
- Koppla Manual Run Start så att den skickar utdata till både Retrieve Latest Release och Fetch Instance Version parallellt.
Steg 2: Koppla datakällor för version
Konfigurera HTTP-förfrågningarna som hämtar er instansversion och den senaste publika releasen.
- Öppna Fetch Instance Version och ställ in URL till
https://[YOUR_ID]/rest/settings. - Öppna Retrieve Latest Release och ställ in URL till
https://api.github.com/repos/n8n-io/n8n/releases/latest. - Verifiera att båda noderna går in i Combine Version Data (input 1 för Fetch Instance Version, input 2 för Retrieve Latest Release).
[YOUR_ID] med era faktiska instans- och tjänsteidentifierare, annars misslyckas förfrågningen.Steg 3: Ställ in versionsnormalisering och jämförelse
Slå ihop de två versionkällorna, normalisera fälten och jämför versioner för att avgöra om en uppdatering behövs.
- Öppna Combine Version Data och ställ in Mode till
combineBySql. - Ställ in Query till
SELECT\n input1.data->versionCli AS versionCli,\n input2.name AS name\nFROM input1\nLEFT JOIN input2 ON 1=1;. - I Normalize Version Fields lägger ni till tilldelningar för actualn8nversion med
={{ $json.versionCli }}och newn8nversion med={{ $json.name.split("@")[1] }}. - I Compare Version Strings konfigurerar ni villkoret för att jämföra leftValue
={{ $json.actualn8nversion }}med rightValue={{ $json.newn8nversion }}med operatorn notEquals.
Steg 4: Konfigurera uppdateringsåtgärder
Trigga en omstart när versionerna skiljer sig åt, eller hoppa över om instansen är uppdaterad.
- Koppla true-utdata från Compare Version Strings till Trigger Deployment Restart.
- Koppla false-utdata från Compare Version Strings till Skip Update Action för en no-op-sökväg.
- I Trigger Deployment Restart ställer ni in URL till
https://[YOUR_ID]/api/v1/services/[YOUR_ID]/restart?latest=true. - Inloggningsuppgifter krävs: Koppla era httpBearerAuth-inloggningsuppgifter i Trigger Deployment Restart.
Steg 5: Testa och aktivera ert arbetsflöde
Validera arbetsflödet manuellt och aktivera det sedan för schemalagda körningar.
- Klicka på Execute Workflow med Manual Run Start för att verifiera att versionsdata hämtas och slås ihop.
- Bekräfta att Compare Version Strings endast routar till Trigger Deployment Restart när versionerna skiljer sig åt och till Skip Update Action när de matchar.
- Kontrollera HTTP-svaren i Fetch Instance Version och Retrieve Latest Release för giltiga JSON-payloads.
- Slå på arbetsflödet med Active-växeln så att Scheduled Update Check körs automatiskt.
Vanliga fallgropar
- Coolify-inloggningar kan löpa ut eller kräva specifika behörigheter. Om något slutar fungera, kontrollera först din Coolify API-token och Bearer-inloggningen i n8n.
- Om du använder Wait-noder eller extern rendering varierar processtider. Öka väntetiden om efterföljande noder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att sitta och redigera output för alltid.
Vanliga frågor
Cirka 30 minuter när du har din Coolify-token och URL:er redo.
Nej. Du klistrar främst in endpoints, kopplar inloggningar och testar en manuell körning. ”Logiken” finns redan inbyggd i workflowets jämförelsesteg.
Ja. n8n har ett gratis self-hostat alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in API-kostnader, som vanligtvis är 0 USD här eftersom GitHub- och Coolify-anropen är enkla.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och klarar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serverhantering.
Ja, men gör det med avsikt. Du kan justera normaliseringssteget (Set-noden ”Normalize Version Fields”) för att kapa versioner som 1.23.4 till 1.23 och sedan behålla samma IF-jämförelse. En annan vanlig justering är att ändra vad du betraktar som ”senaste” genom att hämta ett annat GitHub-fält om din organisation använder taggar på ett annat sätt. Vissa team lägger också till en Send Email-nod efter jämförelsen så att en omdeploy aldrig sker utan att någon märker det.
Oftast är det en utgången eller felaktig API-token som ligger i din n8n Bearer-inloggning. Det kan också vara fel Coolify API-URL (domän eller app-UUID), eller en nätverksregel som blockerar n8n från att nå Coolify. Om anropet fungerar i Postman/curl men inte i n8n, kontrollera headers och bekräfta att inloggningen är kopplad till rätt HTTP Request-nod.
Många, eftersom den bara deployar om när versioner ändras.
För det här användningsfallet är n8n vanligtvis ett bättre val eftersom det hanterar flerstegslogik (slå ihop, normalisera, jämföra, villkorlig deploy) utan att det känns som att du måste kämpa mot plattformen. Self-hosting spelar också roll här; du kan köra kontroller så ofta du vill utan att oroa dig för task-prissättning. Zapier eller Make kan fortfarande göra det, men du hamnar ofta med extra steg för att formatera data och jämföra versionssträngar på ett korrekt sätt. Om du vill ha godkännanden, retries och fallback-notifieringar förblir n8n läsbart även när workflowet växer. Prata med en automationsexpert om du vill ha hjälp att välja enklaste väg för din setup.
När detta väl är igång slutar ”är vi uppdaterade?” att vara en fråga du behöver hålla i huvudet. Workflowet sköter de repetitiva kontrollerna och drar bara i omdeploy-spaken när det faktiskt spelar roll.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.