Du ser en ny release, intalar dig att du ska deploya den ”senare”, och plötsligt har två veckor gått. Nu ligger du efter, ändringsloggen är ett mysterium och uppdatering känns riskabelt eftersom du inte minns vad som ändrats sedan din senaste deploy.
DevOps-leads känner igen det här under underhållsfönster. En solo-grundare som kör produktion på en liten VPS känner det kl. 23. Och byråteam som hanterar kunders infrastruktur? Samma huvudvärk, högre insats. Den här automatiseringen för GitHub Coolify-deploy håller din Coolify-app på rätt n8n-version utan manuell taggkopiering.
Nedan ser du vad workflowet gör, vad du behöver och hur du använder det säkert så att uppdateringar sker korrekt och förutsägbart.
Så fungerar automatiseringen
Hela n8n-workflowet, från trigger till slutresultat:
n8n Workflow Template: GitHub till Coolify: driftsätt utan tagg-jakt
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
Problemet: att deploya uppdateringar blir en ritual av tagg-jakt
Att hålla en app uppdaterad låter enkelt tills du gör det om och om igen. Du kollar GitHub-releaser, jämför versioner, kopierar en tagg in i Coolify och hoppas att du inte tog fel (beta vs stabil, eller en prerelease med ett liknande namn). Sedan triggar du en deploy, väntar och inser att du deployade samma version som du redan hade eftersom du glömde vad som körde förra veckan. Multiplicera det med flera miljöer eller flera kundappar så blir den mentala overheaden större än själva deployen. Ärligt talat är det här rutinjobbet som skapar backloggen av ”vi uppdaterar senare”.
Friktionen ökar. Här är var det faller isär i verkligheten.
- Release-bevakning blir en manuell vana, så den glider under stressiga veckor.
- Att kopiera versionstaggar till miljövariabler bjuder in små misstag som orsakar stora driftstopp.
- Att deploya två gånger för samma release händer oftare än någon vill erkänna, särskilt när flera personer rör stacken.
- Beta-testning är svår att göra säkert eftersom prereleaser kommer ofta och du kan inte sitta och vaka över varje uppdatering.
Lösningen: GitHub-releasebevakning som uppdaterar Coolify och deployar automatiskt
Det här workflowet bevakar GitHub efter nya n8n-releaser, väljer den kanal du vill ha (beta-prereleaser eller stabila releaser) och tar sedan hand om ”sista milen” i Coolify åt dig. När en ny release dyker upp tolkar det versionen från releasenamnet, uppdaterar din Coolify-applikations miljövariabel (specifikt N8N_VERSION) och triggar en deployment via Coolifys API. Det deduplikerar också releaser så att du inte redeployar samma version två gånger, vilket är en tyst men stor förbättring i vardagen. Slutresultatet är enkelt: din deployade n8n hålls uppdaterad, med mindre övervakning och färre möjligheter för mänskliga fel.
Workflowet startar enligt schema (varje minut för betas, och varje timme för stabilt om du aktiverar det). Det hämtar release-data från GitHub, filtrerar ner till det du bryr dig om och uppdaterar först därefter Coolify och triggar en deploy.
Vad du får: automatisering vs. resultat
| Vad detta workflow automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du kör n8n på Coolify och vill ligga nära beta-releaser för test. Manuell hantering kan ta ungefär 10 minuter per release: kolla GitHub, kopiera versionen in i Coolify och trigga deployen (och sedan göra en snabb rimlighetskontroll). Om betas släpps några gånger i veckan blir det ungefär en timme av små avbrott. Med det här workflowet är ditt ”arbete” i princip noll efter uppsättning: GitHub kontrolleras varje minut, versionen uppdateras automatiskt och Coolify deployar utan att du jagar taggar.
Det här behöver du
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- GitHub för att läsa n8n:s release-data.
- Coolify för att uppdatera env-variabler och deploya.
- Coolify API-token (skapa den i Coolifys API-/inställningsområde).
Kunskapsnivå: Mellan. Du klistrar in en API-token, ersätter en applikations-UUID och gör en snabb testkörning.
Vill du inte sätta upp det här själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
Schema-triggers drar igång det. Beta-spåret söker efter prereleaser varje minut. Stable-spåret söker varje timme, men är avstängt som standard så att du kan välja när du är redo.
GitHub-releaser hämtas och struktureras. Workflowet hämtar en releaselista (beta) eller den senaste releasen (stable), filtrerar till rätt release-typ, begränsar hur många objekt som ska beaktas och tar sedan bort dubbletter så att bara genuint nya versioner går vidare.
Versionen extraheras och appliceras i Coolify. När workflowet har en ”ny” release tolkar det den semantiska versionen (som 1.34.0) och uppdaterar din Coolify-applikations miljövariabler så att N8N_VERSION matchar den releasen.
En deployment triggas automatiskt. Efter uppdateringen av miljövariabeln anropar workflowet Coolifys API för att initiera en deploy, så att den nya versionen faktiskt körs i stället för att bara ligga i konfigurationen.
Du kan enkelt justera schemafrekvensen för att matcha din tolerans för förändring, så att uppdateringar sker när du vill. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera schematriggrarna
Sätt upp de två schemabaserade startpunkterna som kontrollerar senaste releaser och betareleaser.
- Öppna Latest Schedule Trigger och ställ in intervallregeln så att den körs varje timme i Rule → Interval → Field
hours. - Öppna Beta Schedule Trigger och definiera den intervallregel ni vill ha under Rule → Interval.
- Säkerställ att båda triggrarna är anslutna till sina efterföljande noder: Latest Schedule Trigger → Fetch Latest Release och Beta Schedule Trigger → Fetch Release List.
Steg 2: Anslut GitHub-datakällor för releaser
Konfigurera HTTP-anropen som hämtar release-data från GitHub.
- I Fetch Latest Release, ställ in URL till
https://api.github.com/repos/n8n-io/n8n/releases/latest. - Aktivera Send Query Parameters och lägg till per_page med värdet
10. - I Fetch Release List, ställ in URL till
https://api.github.com/repos/n8n-io/n8n/releasesoch sätt per_page till10.
Steg 3: Sätt upp release-filtrering och deduplicering
Filtrera betareleaser, begränsa batchstorleken och förhindra dubbla driftsättningar.
- I Apply Release Filter, lägg till ett booleskt villkor där Left Value är
={{ $json.prerelease }}och operatorn är true. - Behåll Cap Records efter filtret för att begränsa bearbetningen till ett begränsat antal objekt.
- I Eliminate Repeats, ställ in Operation till
removeItemsSeenInPreviousExecutionsoch Dedupe Value till={{ $json.name }}.
Steg 4: Konfigurera driftsättningsåtgärder
Uppdatera miljövariabler och trigga driftsättningen i er driftsättningskonsol.
- Öppna Modify Environment Vars och ställ in URL till
=https://console.buatan.id/api/v1/applications/{{ '[YOUR_ID]' }}/envs. - Sätt Method till PATCH och aktivera Send Body.
- Lägg till body-parametrar: key
N8N_VERSION, value={{ $json.name.split('@').last() }}, is_preview={{ false }}, is_build_time={{ true }}, och is_literal={{ false }}. - Credential Required: Anslut era httpBearerAuth- eller httpHeaderAuth-uppgifter i Modify Environment Vars.
- Öppna Initiate Deployment och ställ in URL till
=https://console.buatan.id/api/v1/deploy?uuid={{ '[YOUR_ID]' }}&force=false. - Credential Required: Anslut era httpBearerAuth- eller httpHeaderAuth-uppgifter i Initiate Deployment.
[YOUR_ID] i båda URL:erna med er faktiska applikations-UUID innan ni testar.Steg 5: Testa och aktivera ert arbetsflöde
Verifiera att varje väg fungerar innan ni aktiverar produktionsscheman.
- Klicka på Execute Workflow och trigga Latest Schedule Trigger manuellt för att testa vägen för senaste release.
- Bekräfta att Fetch Latest Release returnerar data, att Eliminate Repeats släpper igenom nya objekt och att Modify Environment Vars tar emot det nya versionsvärdet.
- Kör ett andra test med Beta Schedule Trigger för att validera flödet Fetch Release List → Apply Release Filter → Cap Records.
- Kontrollera att Initiate Deployment svarar utan fel, vilket indikerar att en driftsättningsbegäran skickades.
- Aktivera scheman för produktion genom att aktivera arbetsflödet och säkerställa att triggrarna inte är inaktiverade.
Vanliga fallgropar
- Coolify-inloggning kan löpa ut eller kräva specifika behörigheter. Om något slutar fungera, börja med att kontrollera din Coolify API-token och header-auth-konfigurationen i n8n-credentials.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du att sitta och redigera output för alltid.
Vanliga frågor
Cirka 30 minuter om du redan har din Coolify API-token och applikations-UUID.
Nej. Du klistrar främst in credentials och ersätter Coolify-applikationens UUID i två noder.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på $20/månad för högre volym. Du behöver också räkna in Coolify-hostingkostnader (din VPS) eftersom workflowet anropar Coolify API.
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärt och hanterar n8n bra. Self-hosting ger dig obegränsade exekveringar men kräver grundläggande serverhantering.
Ja, men du behöver aktivera stable-schematriggern och hålla beta-triggern avstängd. I praktiken slår du på noden som kontrollerar den senaste stabila releasen varje timme och bekräftar sedan att filterlogiken inte släpper igenom prereleaser. Vanliga anpassningar är att ändra kontrollfrekvensen, uppdatera en annan miljövariabel än N8N_VERSION, eller peka samma flöde mot en andra Coolify-applikations-UUID för staging.
För det mesta är det ett API-token-problem. Skapa en ny Coolify-token, säkerställ att den skickas i header auth-credentials och bekräfta sedan att Coolify-bas-URL:en i dina HTTP Request-noder är korrekt. Om UUID:en är fel kan Coolify returnera ett ”not found”-liknande svar som ser ut som ett auth-problem. Rate limiting är ovanligt här, men det kan hända om du kontrollerar för aggressivt över många appar.
Betydligt fler än du realistiskt kommer att behöva. På n8n Cloud Starter begränsas du av månatliga exekveringar, så att kontrollera varje minut kan dra iväg om du kör det 24/7. Om du self-hostar finns ingen exekveringsgräns och den praktiska begränsningen blir serverresurser och hur många separata appar du övervakar. Workflowet begränsar och deduplikerar också releaser, vilket håller körningarna lätta även om GitHub returnerar en längre release-lista.
Ofta, ja. Zapier och Make kan bevaka GitHub, men det här workflowet drar nytta av n8n:s mer flexibla filtrering och hantering av dubbletter, vilket betyder färre oavsiktliga redeployar. Coolify API-anrop är också ofta enklare att modellera i n8n eftersom du kan forma requests och responses utan att slåss med mallar. Self-hosting-alternativet spelar också roll om du vill kontrollera ofta utan att betala per körning. Om du vill ha hjälp att välja den renaste setupen för din stack, prata med en automationsexpert.
När detta väl rullar blir ”att hålla sig uppdaterad” bakgrundsbrus i stället för en återkommande uppgift. Sätt upp det, testa det och lägg sedan din uppmärksamhet på arbete som faktiskt tar saker framåt.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.