Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

GitHub + Ollama: prompter som aldrig skapar fel

Rickard Andersson Partner, Nodenordic.se

Din ”perfekta” prompt funkar i test, och går sedan sönder så fort någon uppdaterar mallen, byter namn på en variabel eller glömmer att lägga till launch_date. Plötsligt är du tillbaka i Slack-trådar, kör jobb igen och försöker förstå varför modellens output plötsligt ser fel ut.

Den här GitHub Ollama-automationen träffar AI-ingenjörer först, helt ärligt, men även automationsspecialister och content-team som underhåller många promptvarianter märker av den. Resultatet är enkelt: prompts hämtas från GitHub, varje platshållare valideras, och sedan kör Ollama bara när alla indata är kompletta.

Nedan ser du hur workflowet fungerar end-to-end, vad det förhindrar och vad du kan anpassa om du vill hämta variabler från Sheets, ett CRM eller en annan databas.

Så fungerar den här automationen

Hela n8n-workflowet, från trigger till slutligt resultat:

n8n Workflow Template: GitHub + Ollama: prompter som aldrig skapar fel

Problemet: promptmallar glider och går sönder i det tysta

Att hantera prompts låter enkelt tills du har fler än en handfull, flera personer som redigerar dem och olika projekt som delar samma variabler. Någon justerar en promptfil i GitHub för att lägga till {{ $json.features }}, men ingen uppdaterar variablerna som skickas in. Eller så ändrar de launch_date till launchDate, och prompten ”kör” men levererar skräp. Det värsta är hur det fallerar: du får inte alltid ett tydligt fel. Du får bara inkonsekvent output, extra omkörningar och en långsam urholkning av förtroendet för systemet.

Det bygger upp snabbt. Här är var det vanligtvis faller i verkliga workflows.

  • Promptuppdateringar i GitHub kommer inte automatiskt med matchande indata-variabler, så ändringar går ut utan säkerhetskontroll.
  • Du tappar ungefär en timme per incident på att jaga ”varför gjorde modellen så här?” när det egentliga problemet är en saknad platshållare.
  • Team börjar kopiera prompts till dokument ”för säkerhets skull”, vilket skapar dubbla källor till sanning och ännu mer drift.
  • Manuell ihopbyggnad av prompts leder till små formateringsmissar som inte syns förrän efter att du redan har genererat output.

Lösningen: GitHub-prompts + variabelvalidering + Ollama-körning

Det här workflowet gör ditt promptbibliotek till ett pålitligt, repeterbart system. Det börjar med att hämta en textbaserad prompt direkt från ett GitHub-repo (så Git förblir källan till sanning). Sedan skannar det prompten efter platshållare skrivna i n8n-uttrycksformat, som {{ $json.company }}. Innan något ens når AI-modellen kontrollerar workflowet dina angivna variabler (från ett dedikerat steg ”set variables”) och bekräftar att varje platshållare som krävs finns. Om något saknas stoppar det direkt och returnerar ett tydligt fel som listar saknade fält. Om allt finns på plats ersätter det platshållarna, sparar den färdigställda prompten och skickar den till en Ollama chat-modell för bearbetning.

Workflowet startar med en manuell eller extern trigger och hämtar sedan promptfilen från GitHub. Därefter validerar och ersätter code-noder platshållare med dina definierade variabler. Till sist kör Ollama-agenten den kompletta prompten och returnerar svaret som strukturerad output som du kan skicka vidare i flödet.

Det du får: automation vs. resultat

Exempel: så här ser det ut

Säg att du underhåller 20 prompts i GitHub och uppdaterar några varje vecka. Manuell hantering innebär att en enda uppdatering ofta betyder att du öppnar automationsflödet, kontrollerar vilka variabler den förväntar sig, kör ett test och sedan fixar det som gick sönder. Det tar lätt runt 30 minuter när något strular. Med det här workflowet ser ”efter” mer ut så här: trigga körningen, GitHub-prompten hämtas på sekunder, variablerna kontrolleras direkt, och antingen (a) kör Ollama med en komplett prompt, eller (b) får du omedelbart en lista över vad som saknas. Inget gissande. Inga omkörningar för samma misstag.

Det du behöver

  • n8n-instans (testa n8n Cloud gratis)
  • Möjlighet till self-hosting om du föredrar det (Hostinger fungerar bra)
  • GitHub för att lagra och versionshantera promptfiler
  • Ollama för att köra prompts med en lokal/chat-modell
  • GitHub-token (om privat repo) (skapa den i GitHub Developer Settings)

Svårighetsnivå: Medel. Du konfigurerar främst noder och credentials, men du bör vara bekväm med att redigera några variabler och läsa enkel valideringslogik.

Vill du inte sätta upp detta själv? Prata med en automationskonsult (gratis 15-minuters konsultation).

Så fungerar det

En körning triggas. I workflowet som ingår kan den startas manuellt, och det är också förberett för extern triggring via webhook. Det betyder att du kan testa snabbt och senare anropa det från ett annat system.

Variabler initieras. Ett dedikerat steg ”set variables” definierar de fält du vill göra tillgängliga för prompten (som company, features och launch_date). Du kan hålla detta manuellt, eller byta till att hämta från Google Sheets, en databas eller ett annat verktyg.

Den senaste prompten hämtas från GitHub och tolkas. n8n hämtar filen, extraherar ren text och sparar den så att senare steg kan validera och ersätta utan strul. GitHub gör det GitHub är bäst på här: versionshantering, samarbete och en enda källa till sanning.

Platshållare valideras och ersätts. Code-noder skannar efter n8n-uttrycksplatshållare, jämför dem mot dina angivna variabler och väljer väg. Om något saknas stoppas workflowet med ett läsbart fel. Om allt matchar ersätter det värden och färdigställer den kompletta prompten.

Ollama kör och returnerar output. Den färdigställda prompten skickas till en Ollama chat-modell via AI agent-noden, och svaret sparas som output som du kan logga, skicka till ett ark eller returnera via webhook.

Du kan enkelt ändra var variabler kommer ifrån så att det matchar dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-implementeringsguide

Steg 1: konfigurera den manuella triggern

Det här arbetsflödet startar manuellt så att ni kan testa hämtning och ersättning av promptar vid behov.

  1. Lägg till noden Manual Launch Trigger som arbetsflödets startpunkt.
  2. Lämna alla standardinställningar, eftersom den här noden inte har några parametrar konfigurerade.
  3. Koppla Manual Launch Trigger till Initialize Variables.

Steg 2: anslut GitHub och ladda promptfilen

Ange repository-detaljerna och hämta promptfilen från GitHub innan ni tolkar dess text.

  1. Öppna Initialize Variables och ställ in fälten exakt som konfigurerat: Account till TPGLLC-US, repo till PeresPrompts, path till SEO/, prompt till keyword_research.md, company till South Nassau Physical Therapy, product till Manual Therapy, features till pain relief och sector till physical therapy.
  2. Öppna Fetch GitHub File och ställ in Owner till ={{ $json.Account }}, Repository till ={{ $json.repo }}, File Path till ={{ $json.path }}{{ $json.prompt }}, Resource till file och Operation till get.
  3. Inloggningsuppgifter krävs: Anslut era githubApi-inloggningsuppgifter i Fetch GitHub File.
  4. Öppna Parse File Text och ställ in Operation till text.
  5. Koppla Initialize VariablesFetch GitHub FileParse File TextStore Prompt Text.

Steg 3: validera promptvariabler och förgrena

Det här steget kontrollerar om alla obligatoriska platshållare i prompten finns i era variabler innan ersättning.

  1. I Store Prompt Text behåller ni tilldelningen för data inställd på ={{ $json.data }}.
  2. I Validate Prompt Variables behåller ni JavaScript-koden som den är för att extrahera {{ }}-platshållare och jämföra dem med värdena i Initialize Variables.
  3. I Branch on Validation behåller ni villkoret inställt på Left Value ={{ $json.success }} och Right Value ={{ $('Validate Prompt Variables').item.json.keys()}} med den booleska operatorn.
  4. Koppla Store Prompt TextValidate Prompt VariablesBranch on Validation.

⚠️ Vanlig fallgrop: Om er promptfil innehåller variabler som inte finns i Initialize Variables, kommer arbetsflödet att routas till Halt with Error och stoppa körningen.

Steg 4: konfigurera promptersättning och AI-bearbetning

Ersätt platshållare i prompten och kör sedan prompten genom AI-agenten med Ollama som språkmodell.

  1. I Substitute Placeholders behåller ni JavaScript-koden som hämtar prompttext från Store Prompt Text och ersätter platshållare med hjälp av Initialize Variables.
  2. I Finalize Prompt behåller ni Prompt inställd på ={{ $json.prompt }}.
  3. I AI Task Runner ställer ni in Text till ={{ $json.Prompt }} och Prompt Type till define.
  4. Öppna Ollama Chat Engine och anslut den som språkmodell för AI Task Runner.
  5. Inloggningsuppgifter krävs: Anslut era ollamaApi-inloggningsuppgifter i Ollama Chat Engine.
  6. Koppla Branch on ValidationSubstitute PlaceholdersFinalize PromptAI Task RunnerPrompt Result Output.

Ollama Chat Engine är ansluten som språkmodell för AI Task Runner—se till att inloggningsuppgifter läggs till i Ollama Chat Engine, inte i agentnoden.

Steg 5: lägg till felhantering

Om valideringen misslyckas stoppar arbetsflödet med ett tydligt felmeddelande som listar de saknade platshållarna.

  1. I Halt with Error ställer ni in Error Message till =Missing Prompt Variables : {{ $('Validate Prompt Variables').item.json.missingKeys }}.
  2. Koppla den falska grenen från Branch on Validation till Halt with Error.

Steg 6: testa och aktivera ert arbetsflöde

Kör ett manuellt test för att säkerställa att prompten hämtas, valideras, ersätts och bearbetas av AI-agenten.

  1. Klicka på Execute Workflow för att trigga Manual Launch Trigger.
  2. Bekräfta att Prompt Result Output tar emot ett promptResponse-värde från ={{ $json.output }}.
  3. Om ni ser ett fel, verifiera att platshållarna i promptfilen matchar nycklarna i Initialize Variables.
  4. När allt fungerar, växla arbetsflödet till Active för att aktivera användning i produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • GitHub-credentials kan löpa ut eller kräva specifika behörigheter. Om saker slutar fungera, kontrollera först din credential-post i n8n för GitHub-noden och bekräfta repo-åtkomst (särskilt för privata repos).
  • Om du använder Wait-noder eller extern rendering varierar processtider. Öka väntetiden om nedströms noder fallerar på tomma svar.
  • Val av Ollama-modell spelar större roll än många tror. Om outputkvaliteten plötsligt sjunker, säkerställ att Ollama Chat-noden pekar på rätt modell och att din lokala Ollama-tjänst är nåbar från n8n.

Vanliga frågor

Hur lång tid tar det att sätta upp den här GitHub Ollama-automationen?

Cirka 30 minuter om GitHub och Ollama redan är nåbara från n8n.

Behöver jag kunna koda för att automatisera GitHub Ollama-automation?

Nej. Du kopplar mest konton och redigerar några få fält. Den enda ”koden” här är redan byggd, och du kan oftast lämna den som den är.

Är n8n gratis att använda för det här GitHub Ollama-automation-workflowet?

Ja. n8n har ett gratis self-hosted-alternativ och en gratis testperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in Ollamas beräkningskostnader (den maskin som kör modellen).

Var kan jag hosta n8n för att köra den här automationen?

Två alternativ: n8n Cloud (hanterat, enklast att sätta upp) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger dig obegränsat antal körningar men kräver grundläggande serveradministration.

Kan jag anpassa det här GitHub Ollama-automation-workflowet för att hämta variabler från Google Sheets?

Ja, och det är en vanlig uppgradering. Byt ut steget ”Initialize Variables” (setVars) mot en Google Sheets-läsning, och mappa sedan kolumner i arket till samma variabelnamn som används i GitHub-prompten (som company och launch_date). Du kan också behålla setVars-noden som fallback för standardvärden. Nyckeln är konsekvens: platshållarnamnen i prompten måste matcha nycklarna du skickar ut från Sheets.

Varför misslyckas min GitHub-anslutning i det här workflowet?

Oftast är det ett token- eller behörighetsproblem. Skapa en ny GitHub-token om den har löpt ut och bekräfta att den kan läsa det specifika repot (privata repos ställer ofta till det). Kontrollera också att filsökvägen du begär matchar den branch du förväntar dig. Om du nyligen flyttade eller döpte om promptfilen kommer workflowet fortfarande att anropa den gamla platsen tills du uppdaterar den.

Hur många prompts kan den här GitHub Ollama-automationen hantera?

Många, så länge din hosting hänger med. På n8n Cloud är begränsningen främst dina månatliga körningar. Om du self-hostar finns ingen fast körningsgräns, men din server och Ollama-maskinen blir flaskhalsen när körningar toppar.

Är den här GitHub Ollama-automationen bättre än att använda Zapier eller Make?

Ofta, ja, för just det här användningsfallet. Promptvalidering och förgreningslogik är där n8n glänser, och self-hosting spelar roll om du vill köra mycket utan att oroa dig för task-prissättning. Zapier och Make kan fortfarande fungera, men du hamnar ofta i mer skör ”string replace”-logik och mindre kontroll över felhantering. En praktisk punkt till: Ollama är enklast när du kan kontrollera miljön, vilket är enklare med n8n self-hosted. Om du är osäker, prata med en automationskonsult så hjälper vi dig välja den mest robusta vägen.

När detta väl är på plats slutar promptändringar att kännas riskabla. Du levererar snabbare, och workflowet fångar de dumma misstagen innan modellen ens får se dem.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Launch login modal Launch register modal