n8n self-hosted med Docker. Installation, backup och autoskalning.
Self-hostad n8n är en av de mest kostnadseffektiva automationsplattformarna som finns - rätt uppsatt. Du slipper prismodeller som straffar volym, din data lämnar aldrig din miljö, och du kan bygga precis så avancerade flöden du vill. Men "rätt uppsatt" gör allt det tunga arbetet i den meningen. Jag ser regelbundet n8n-installationer som körs som en ensam container utan backup, utan plan för uppdateringar och utan en tanke på vad som händer den dag flödena blir affärskritiska. Då har man bytt en förutsägbar SaaS-kostnad mot en oförutsägbar driftrisk.
Jag sätter upp och driftar n8n för svenska bolag inom AI-automation, och här är vad som skiljer en installation som håller från en som blir ett problem.
Grunden: n8n behöver mer än en container
Det går att starta n8n med en enda Docker-container, och för att prova är det helt rätt. Men en produktionsuppsättning har fler delar. Den viktigaste är databasen: kör n8n mot en riktig PostgreSQL, inte den inbäddade SQLite-lösningen, eftersom det är där alla era flöden och exekveringsdata lever. Lägg till en omvänd proxy framför för HTTPS och en genomtänkt hantering av hemligheter och miljövariabler. Redan där har du en installation som tål att tas på allvar, snarare än ett experiment som råkade bli kvar i produktion.
Backup: det du ångrar att du inte hade
Den fråga jag alltid ställer är: om servern försvann just nu, hur mycket skulle ni förlora? För många med en naiv n8n-uppsättning är svaret allt, och det inser de först när det hänt. En riktig backupstrategi täcker två saker:
- Databasen: regelbundna, automatiska säkerhetskopior av PostgreSQL där alla flöden och deras historik finns. Detta är hjärtat.
- Hemligheter och credentials: de krypteringsnycklar och inloggningar som flödena använder måste säkras separat och säkert - utan dem är en databasdump halvt värdelös.
Och det självklara som ändå glöms: testa att återställningen faktiskt fungerar. En backup ingen prövat är en förhoppning, inte ett skydd. Jag har sett fler trasiga backuper än lyckade återställningar hos bolag som trodde de var säkra.
Uppdateringar och versionshantering
n8n utvecklas snabbt, vilket är bra, men det betyder att uppdateringar är en del av driften, inte en engångshändelse. Lås versionen explicit i stället för att alltid dra senaste, så att en container som startar om inte plötsligt kör en ny version med ändrat beteende. Ha en plan för att testa uppdateringar innan de når produktion. Och versionshantera era flöden - n8n kan exportera dem, och att ha dem i git ger er både historik och en väg tillbaka när en ändring blev fel.
Skalning: när en instans inte räcker
För de flesta bolag räcker en välkonfigurerad instans förvånansvärt långt. Men när volymen växer eller flödena blir tunga finns n8n:s köbaserade läge, där exekveringar fördelas över flera arbetar-processer. Det låter dig hantera fler samtidiga körningar och skala arbetarna efter last. Min uppmaning är dock att inte börja där - inför skalning när ni faktiskt behöver den, eftersom en distribuerad uppsättning är mer att förvalta. Att bygga för en skala ni inte har är ett lika vanligt misstag som att inte planera för den ni får.
Var ärlig om driftansvaret
Self-hosting är inte gratis bara för att licensen är det. Någon måste äga servern, uppdateringarna, backuperna och övervakningen. För ett bolag med teknisk förmåga är det en utmärkt affär - kontroll och låg kostnad. För ett utan den förmågan kan en hostad lösning, antingen n8n:s egen molntjänst eller en plattform som Make, vara klokare trots högre styckpris. Den ärliga frågan är inte vad som är billigast på pappret, utan vem som vaknar mitt i natten när det slutar fungera.
Relaterat
- Evals-driven development: Så testar du LLM-applikationer i CI/CD
- Prompt injection-attacker: 12 mönster och hur du försvarar dig 2026
- AI-agent observability: Tracing, costs och token-budgets med Langfuse
Ett exempel på en n8n-driftuppsättning finns i kundcase.
Vill du ta det vidare?
Jag sätter upp produktionsklar self-hostad n8n för svenska bolag - med PostgreSQL, backup, uppdateringsplan och skalning där den behövs. Boka ett förutsättningslöst samtal så går vi igenom er driftmiljö.
“Den ärliga frågan är inte vad som är billigast på pappret, utan vem som vaknar mitt i natten när det slutar fungera. En backup ingen prövat är en förhoppning, inte ett skydd.”
- Simon Axelsson
Vanliga frågor
- Räcker det att köra n8n som en enda Docker-container?
- För att prova, ja. För produktion behöver du mer: en riktig PostgreSQL i stället för SQLite, en omvänd proxy för HTTPS, säkrad hantering av hemligheter och en backupstrategi. En ensam container utan backup blir en driftrisk så fort flödena blir affärskritiska.
- Vad måste en n8n-backup omfatta?
- Två saker: databasen där alla flöden och deras historik finns, och de krypteringsnycklar och credentials som flödena använder. Utan credentials är en databasdump halvt värdelös. Och testa återställningen - en backup ingen prövat är ingen garanti.
- När behöver vi skala n8n över flera instanser?
- Senare än du tror. En välkonfigurerad instans räcker förvånansvärt långt. När volymen verkligen växer finns n8n:s köbaserade läge som fördelar exekveringar över flera arbetare. Inför det vid faktiskt behov, eftersom en distribuerad uppsättning är mer att förvalta.
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar