Din ”backupplan” för n8n-workflows är förmodligen en mix av hopp, manuella exporter och den där enda JSON-filen som du svär att du ska organisera senare. Sen händer något: något går sönder, en serverflytt blir av, eller ett workflow skrivs över – och plötsligt jagar du den senaste fungerande versionen.
Den här GitHub-backupautomationen träffar opsansvariga först, men byråägare som underhåller flera kundautomatiseringar känner av den lika mycket. Och om du är personen som ”bara underhåller n8n” vet du redan hur stressiga återställningar kan bli. Utfallet är enkelt: varje workflow-export hamnar i GitHub med ändringsspårning, så att du kan rulla tillbaka snabbt.
Du får se exakt hur workflowet hämtar exporter från din n8n-instans, kontrollerar GitHub efter befintliga filer och skapar eller uppdaterar bara det som har ändrats (organiserat i taggbaserade mappar).
Så fungerar automationen
Här är hela workflowet som du kommer att sätta upp:
n8n Workflow Template: GitHub-backuper som spårar varje ändring, utan stress
flowchart LR
subgraph sg0["Execute Workflow Flow"]
direction LR
n2@{ icon: "mdi:swap-vertical", form: "rounded", label: "Return", 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/>Get File"]
n4@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If file too large", 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 Items"]
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/code.svg' width='40' height='40' /></div><br/>isDiffOrNew"]
n7@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Check Status", pos: "b", h: 48 }
n8@{ icon: "mdi:cog", form: "rounded", label: "Same file - Do nothing", pos: "b", h: 48 }
n9@{ icon: "mdi:cog", form: "rounded", label: "File is different", pos: "b", h: 48 }
n10@{ icon: "mdi:cog", form: "rounded", label: "File is new", 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/github.dark.svg' width='40' height='40' /></div><br/>Create new file"]
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/github.dark.svg' width='40' height='40' /></div><br/>Edit existing file"]
n15["<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/github.dark.svg' width='40' height='40' /></div><br/>Get file data"]
n16@{ icon: "mdi:swap-vertical", form: "rounded", label: "Globals", pos: "b", h: 48 }
n17@{ icon: "mdi:play-circle", form: "rounded", label: "Execute Workflow Trigger", pos: "b", h: 48 }
n19@{ icon: "mdi:swap-vertical", form: "rounded", label: "/", pos: "b", h: 48 }
n20@{ icon: "mdi:swap-horizontal", form: "rounded", label: "tag?", pos: "b", h: 48 }
n19 --> n16
n20 --> n19
n20 --> n16
n16 --> n15
n3 --> n5
n10 --> n11
n5 --> n6
n6 --> n7
n7 --> n8
n7 --> n9
n7 --> n10
n15 --> n4
n11 --> n2
n9 --> n12
n4 --> n3
n4 --> n5
n12 --> n2
n8 --> n2
n17 --> n5
n17 --> n20
end
subgraph sg1["On clicking 'execute' Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "On clicking 'execute'", pos: "b", h: 48 }
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/n8n.svg' width='40' height='40' /></div><br/>n8n"]
n13@{ icon: "mdi:swap-vertical", form: "rounded", label: "Loop Over Items", pos: "b", h: 48 }
n14@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule Trigger", pos: "b", h: 48 }
n18@{ icon: "mdi:cog", form: "rounded", label: "Execute Workflow", pos: "b", h: 48 }
n1 --> n13
n13 --> n18
n18 --> n13
n14 --> n1
n0 --> n1
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 n17,n0,n14 trigger
class n4,n7,n20 decision
class n3 api
class n6 code
classDef customIcon fill:none,stroke:none
class n3,n5,n6,n11,n12,n15,n1 customIcon
Varför det här spelar roll: backuper som inte sviker när du behöver dem
Manuell export av workflows ser okej ut – tills det inte gör det. Du exporterar ”lite då och då”, slänger filerna i en mapp och antar att du kommer ihåg vad som ändrats. Men workflow-JSON:er är inte gjorda för att läsas med blotta ögat, och när en produktionsautomation börjar bete sig konstigt blir ”Vilken export är rätt?” en väldigt konkret fråga. Lägg till teamändringar, snabba fixar och servermigreringar, så slutar du med backuper som finns – men som inte går att använda i praktiken. Ärligt talat är det den värsta sorten.
Friktionen växer snabbt. Här är var det brukar fallera i verkligheten.
- Exporter sker inkonsekvent, så den du behöver saknas ofta.
- Filer staplas på hög med otydliga namn, vilket gör återställning långsam och felkänslig.
- Två personer kan ändra ett workflow under en vecka, men du har ingen korrekt historik över vad som ändrades och när.
- Vid en migrering kan du inte bygga upp biblioteket med säkerhet eftersom du inte vet vilka versioner som är ”slutgiltiga”.
Vad du bygger: automatiserade n8n-workflowbackuper till GitHub
Det här workflowet skapar en pålitlig backup-loop mellan din n8n-instans och ett GitHub-repo. Det börjar med att hämta din workflowlista via n8n-API:t, itererar sedan genom varje workflow-export och kontrollerar GitHub för att se om en matchande fil redan finns. Om filen redan finns jämför den det som ligger i GitHub med det som n8n exporterar nu, så att du inte spammar commits med identiskt innehåll. När det finns en faktisk ändring uppdateras filen i GitHub; när den är ny skapas en ny fil. Och om inget har ändrats gör den ingenting och går vidare.
Det finns också ett praktiskt lager för struktur: workflows styrs in i undermappar baserat på taggar, så att repot förblir läsbart när det växer. Workflowet kan köras enligt schema, manuellt eller som ett sub-workflow om du vill koppla in det i en större opsrutin.
Det här bygger du
| Vad som automatiseras | Vad du uppnår |
|---|---|
|
|
Förväntade resultat
Säg att du underhåller 40 workflows och att du ”exporterar varje vecka”. Manuellt kan även en snabb export, namngivning av filer och uppladdning till lagring ta cirka 2 minuter per workflow, så du landar på runt 80 minuter per vecka (och det är lätt att hoppa över). Med det här workflowet slår du på en schematrigger och backupen kör i bakgrunden; din tid går i princip bara åt till att titta i GitHub-repot när du behöver det. När något går sönder blir återställning ”välj senaste fungerande commit”, inte ”leta i mappar”.
Innan du börjar
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- GitHub för att lagra versionshanterade workflow-exporter
- n8n API-åtkomst för att exportera workflows från din instans
- GitHub-token (hämta den i GitHub Developer settings)
Svårighetsnivå: Medel. Du kopplar credentials, sätter en repo-sökväg och bekräftar att din n8n API-åtkomst fungerar.
Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).
Steg för steg
Ett schema (eller manuell körning) startar allt. Du kan köra det vid begäran med Manual Execution Start, eller ställa in det att köra dagligen/veckovis med Scheduled Automation Trigger så att backuper tas även när du har fullt upp.
n8n exporterar dina workflows via sitt API. Workflowet använder en n8n-nod för att hämta workflowlistan från din instans, och sedan itererar ”Split in Batches” igenom varje workflow så att du kan behandla dem säkert utan att överbelasta något.
Varje workflow kontrolleras och jämförs mot GitHub. Först hämtas GitHub-metadata, därefter laddar en HTTP Request ner den aktuella workflow-exporten. Ett litet logikblock utvärderar status: ny fil, uppdaterad fil eller ingen ändring.
GitHub blir backupdestinationen. Nya workflows skapas som filer i repot, befintliga uppdateras och oförändrade ignoreras. Taggroutning och ett Set-steg hjälper till att bygga korrekta mappsökvägar, så att backuper för ”Finance/” och ”Client-A/” inte blandas ihop.
Du kan enkelt justera mappreglerna så att de matchar er interna namngivning, eller byta ut GitHub-lagring mot något annat senare. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera den manuella triggern
Ställ in hur backup-processen ska starta, antingen manuellt eller enligt ett schema.
- Öppna Manual Execution Start för att aktivera körningar på begäran för testning och ad hoc-backuper.
- Öppna Scheduled Automation Trigger och ställ in schemaregeln så att den dagliga körningen triggas vid
triggerAtHour: 7. - Verifiera att båda triggrarna är kopplade till Instance API Fetch så att båda vägarna kan initiera workflow-backupflödet.
Steg 2: Koppla ihop n8n och GitHub
Autentisera mot er n8n-instans och ert GitHub-repo så att workflowet kan läsa och lagra backuper.
- I Instance API Fetch, lägg till autentiseringsuppgifter: Credential Required: Anslut era n8nApi-credentials.
- I Retrieve File Metadata, lägg till autentiseringsuppgifter: Credential Required: Anslut era githubApi-credentials.
- I Create Repository File, lägg till autentiseringsuppgifter: Credential Required: Anslut era githubApi-credentials.
- I Update Repository File, lägg till autentiseringsuppgifter: Credential Required: Anslut era githubApi-credentials.
Steg 3: Ställ in tagg-routing och repo-globala variabler
Definiera hur taggar används för att bygga filsökvägar och ange repo-inställningar som används i hela workflowet.
- Öppna Tag Presence Router och bekräfta att den kontrollerar om taggen finns med hjälp av uttrycken
{{$json.tags[0]}}för både utgångarna tag och none. - I Add Tag Suffix, ställ in tags[0].name till
{{ $('Subworkflow Entry Trigger').item.json.tags[0].name }}/för att lägga till ett avslutande snedstreck. - I Set Repository Globals, ställ in repo.owner till
[YOUR_ID]och repo.name till[YOUR_ID]. - I Set Repository Globals, ställ in repo.path till
=workflows/{{ $json.tags[0].name }}för att bygga mappsökvägen baserat på taggar.
Steg 4: Konfigurera iteration av sub-workflows
Loopa igenom workflows och skicka varje workflow till backup-subflödet.
- I Iterate Workflow List, behåll standardinställningarna för batch om ni inte vill styra batchstorleken för större instanser.
- Öppna Run Sub-Workflow (Configure Required) och ställ in Mode till
each. - I Run Sub-Workflow (Configure Required), välj mål-workflowet i Workflow ID (är för närvarande tomt).
- I Subworkflow Entry Trigger, bekräfta att Input Source är inställt på
passthrough. - Subworkflow Entry Trigger skickar utdata parallellt till både Combine Records och Tag Presence Router.
Steg 5: Ställ in filhämtning och ändringsdetektering
Hämta befintliga GitHub-filer, jämför innehåll med aktuellt workflow och routa efter status.
- I Retrieve File Metadata, ställ in File Path till
{{ $json.repo.path }}{{ $('Subworkflow Entry Trigger').item.json.id }}.json. - I Check File Size, bekräfta att villkoren använder
{{$json.content}}(tomt) och{{$json.error}}(finns inte) för att upptäcka saknade filer. - I Download Workflow File, ställ in URL till
{{ $json.download_url }}för att ladda ner GitHub-filens innehåll. - Säkerställ att Combine Records slår ihop GitHub-fildata med aktuellt workflow-JSON för jämförelse.
- I Detect Changes Logic, behåll den medföljande JavaScript-koden för att jämföra den ordnade JSON:en och sätta
github_statustillsame,differentellernew. - I Route by Status, ställ in Value 1 till
{{$json.github_status}}och bekräfta att reglerna mappar tillsame,differentochnew.
Steg 6: Konfigurera repo-uppdateringar och slutligt svar
Skriv nya eller uppdaterade workflow-filer till GitHub och slutför utdata.
- I Create Repository File, ställ in File Path till
{{ $('Set Repository Globals').item.json.repo.path }}{{ $('Subworkflow Entry Trigger').first().json.id }}.json. - I Create Repository File, ställ in File Content till
{{ $('Detect Changes Logic').item.json["n8n_data_stringy"] }}och Commit Message till{{ $('Subworkflow Entry Trigger').first().json.name }} ({{ $json.github_status }}). - I Update Repository File, ställ in Operation till
editoch använd samma uttryck för File Path, File Content och Commit Message som ovan. - Lämna No Change Action, Updated File Path och New File Path som NoOp-platshållare för routing och framtida utbyggnad.
- I Finalize Response, bekräfta att tilldelningen sätter Done till
true.
Steg 7: Testa och aktivera ert workflow
Kör ett fullständigt test för att validera GitHub-backuper och aktivera sedan schemalagda körningar.
- Klicka på Execute Workflow från Manual Execution Start för att köra ett manuellt test.
- Verifiera att Finalize Response returnerar Done som
trueoch att GitHub-filer skapas eller uppdateras baserat på den upptäckta statusen. - Kontrollera GitHub-repot för nya eller uppdaterade JSON-filer som skapats av Create Repository File eller Update Repository File.
- Växla workflowet till Active så att Scheduled Automation Trigger körs dagligen vid den konfigurerade tiden.
Tips för felsökning
- GitHub-credentials kan gå ut eller sakna repo-scope. Om något slutar fungera, kontrollera först tokenbehörigheter och repots åtkomstinställningar.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om noder längre fram fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du att redigera outputs i all evighet.
Snabba svar
Cirka 30 minuter om ditt repo och din API-åtkomst är klara.
Nej. Du kopplar credentials och justerar några inställningar för repo/sökväg i n8n.
Ja. n8n har ett gratis self-hosted-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 med GitHub-kostnader (oftast gratis för privata repos på de flesta planer) samt eventuell VPS-hostingkostnad om du kör self-hosted.
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 hanterar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det handlar mest om att byta routningsregler. Du kan till exempel ändra den taggbaserade mapplogiken genom att redigera stegen ”Tag Presence Router” och ”Add Tag Suffix”, eller sätta en annan bassökväg i ”Set Repository Globals”. Vanliga justeringar är att bara backa upp utvalda taggar (som ”Production”), använda separata repos per kund eller lägga till ett notifieringssteg efter ”Finalize Response”.
Oftast är det en access token-fråga. Skapa en ny GitHub-token, säkerställ att den har behörighet att skriva till målrepot och uppdatera sedan credential i n8n. Om repot ägs av en organisation, verifiera att SSO eller orgens app-restriktioner inte blockerar token. Kontrollera också att workflowet pekar på rätt owner/repo och branch, eftersom en minimal avvikelse i praktiken ser ut som ”auth failure”.
För de flesta små team är dussintals till några hundra workflows per körning helt okej.
Ofta, ja, eftersom det här inte är en enkel tvåstegs-automation av typen ”skicka data”. Du behöver loopar, kontroller av om filer finns och logik för att upptäcka ändringar så att du inte skriver över bra historik eller skapar en hög med duplicerade commits. n8n hanterar branching och batchbearbetning snyggt, och du kan köra self-hosted för obegränsade körningar om du tar backuper ofta. Zapier och Make kan fungera, men du kan bli tvungen att betala mer när antalet workflows växer, och komplex filhantering blir snabbt klumpig. Om du vill ha en second opinion för din setup, Prata med en automationsexpert.
Backuper är bara ”bra att ha” fram till den dag du faktiskt behöver en. Sätt upp detta en gång, så ser GitHub tyst till att din workflowhistorik är redo för nästa återställning, revision eller migrering.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.