Sådan self-hoster du n8n i 2026: Deploy, TLS, webhooks og backups
Self-host n8n med korrekte porte, persistent storage, HTTPS, secrets, backups og opgraderingskontroller. Lær, hvordan du løser problemer med webhook-links, der stadig peger på localhost.
En n8n-container kan være grøn, selvom det job, brugerne faktisk er afhængige af, er gået i stykker. For n8n er den skjulte fejl som regel, at webhook-links stadig peger på localhost, eller at proxy-headere angiver HTTP. Denne guide bruger “aktivér et workflow med en production-webhook, kald denne webhook udefra serveren, og bekræft, at eksekveringen når sin sidste node” som acceptance-test og bygger deploymentet baglæns ud fra dette resultat.
n8n har en specifik rolle i stacken: workflow-automatisering med over 400 integrationer og et udvideligt node-system. Det afgørende produktionsspørgsmål er derfor ikke, om port 5678 svarer én gang, men om state, afhængigheder og den offentlige adresse fortsat stemmer overens efter en genstart, opdatering og restore.
Adskil udskiftelige containere fra permanente data
Definér recovery point og recovery time for n8n ud fra databasen samt .n8n-krypterings- og konfigurationsdataene. Mount /home/node/.n8n før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. En named volume løser persistence ved redeploy; den løser ikke kompromittering eller tab af serveren.
Opret et rent restore-miljø, brug den samme pinnede applikationsversion, og bevis, at restored credentials stadig kan dekrypteres, og at et restored workflow modtager den samme offentlige webhook-URL. Notér kommandoer, rettelser af ejerskab og tidsforbrug. Backup-guiden er en nyttig standard: En backup er først pålidelig efter en restore, ikke efter en upload.
Gør n8n-start reproducerbar
En minimal kommando er nyttig, når den viser, hvad platformen senere kommer til at administrere.
docker run -d \
--name n8n \
--restart unless-stopped \
-p 127.0.0.1:5678:5678 \
-v n8n-data:/home/node/.n8n \
-e N8N_ENCRYPTION_KEY=replace-with-a-long-random-value \
docker.n8n.io/n8nio/n8n
Her forbliver port 5678 privat på hosten, og alle nødvendige stier er eksplicit angivet. Tilføj de gennemgåede forbindelsesindstillinger for Postgres til et persistent multi-user-produktionssetup, og brug private navne til private services. Bekræft opstarten med både logs og det applikationsspecifikke bevis: Aktivér et workflow med en production-webhook, kald denne webhook udefra serveren, og bekræft, at eksekveringen når sin sidste node. Når det er verificeret, skal image-versionen låses, så en rutinemæssig udskiftning ikke lydløst ændrer adfærden.
Porte, processer og private services
Start med n8n's network namespace: Dets web listener er port 5678, ikke en host-port kopieret fra en laptop-tutorial. Netværkskontrakten for n8n er Postgres til et persistent multi-user-produktionssetup. Hold private endpoints på intern DNS, tillad kun nødvendige udgående kald, og giv n8n en afgrænset service-credential.
Når kravet er opfyldt, skal du køre det komplette scenarie — aktivér et workflow med en production-webhook, kald denne webhook udefra serveren, og bekræft, at eksekveringen når sin sidste node. Registrér logs og målinger for execution concurrency, queue depth, binary payload size og long-running nodes i stedet for editor page views. Disse data bliver den første kendte-gode arkitektur og gør senere flytninger mellem Dockup compute og en tilknyttet server testbare.
Undgå, at proxy-succes skjuler applikationsfejl
Den offentlige grænse for n8n bør være ét canonical hostname, automatisk TLS og ét internt target på 5678. Indstil WEBHOOK_URL til den præcise eksterne HTTPS-URL, så klienter vender tilbage til en adresse, som servicen genkender.
Hvis acceptance-transaktionen fejler, skal du klassificere den første fejl. DNS-, certifikat- og 502-problemer hører til i TLS-valideringstjeklisten. Betingelsen “webhook-links peger stadig på localhost, eller proxy-headere angiver HTTP” hører til på applikationssiden, efter at en request uden problemer er nået frem til n8n.
Hvad skal bestå, før rigtige n8n-data ankommer
Gør n8n-smoketesten til en reproducerbar release-kommando eller en kort runbook. Outputtet skal demonstrere dette resultat: Aktivér et workflow med en production-webhook, kald denne webhook udefra serveren, og bekræft, at eksekveringen når sin sidste node. Registrér applikationsversion, container digest, route-hostname og testdataidentifikator sammen med resultatet.
Kør den samme kontrol efter en rutinemæssig containerudskiftning og efter restore af databasen samt .n8n-krypterings- og konfigurationsdataene et andet sted. Restoren er lykkedes, når restored credentials stadig kan dekrypteres, og et restored workflow modtager den samme offentlige webhook-URL. Sammenlign tidsforbrug og ressourceforbrug relateret til execution concurrency, queue depth, binary payload size og long-running nodes i stedet for editor page views; en stor ændring er værd at undersøge, selv når den afsluttende handling stadig består.
Udfør derefter en sikker fejltest: Afvis midlertidigt testidentitetens adgang til Postgres til et persistent multi-user-produktionssetup. Bekræft, at n8n viser fejlen og vender tilbage til normal drift uden destruktive manuelle ændringer. Gem kun det nødvendige, redigerede logudsnit. Denne gate i fire dele dækker opstart, persistence, recovery og fejlhåndtering.
Kapacitet og opgraderingskontroller
Byg dashboards omkring execution concurrency, queue depth, binary payload size og long-running nodes i stedet for editor page views. En CPU-graf uden kontekst om workloaden kan ikke forklare, hvorfor n8n er langsom. Tilføj en syntetisk eller scheduled kontrol, der forsøger at aktivere et workflow med en production-webhook, kalde denne webhook udefra serveren og bekræfte, at eksekveringen når sin sidste node ved hjælp af harmløse testdata.
Før en opgradering skal du tage højde for denne applikationsspecifikke risiko: Databasemigrationer, credential-kryptering og installerede community nodes skal forblive kompatible med den målrettede n8n-release. Gendan en nylig backup i et isoleret deployment, kør migrationerne dér, og sammenlign adfærden. Hvis webhook-links stadig peger på localhost, eller proxy-headere angiver HTTP, skal du undersøge den relevante grænse — public origin, storage eller dependency — før du ændrer andre indstillinger.
Lås n8n ned efter bootstrap
Overtag ikke sikkerhedsantagelser fra en lokal tutorial. n8n's specifikke udfordring er rotation af N8N_ENCRYPTION_KEY, efter at credentials er blevet gemt. Production bør derfor kræve autentificering af editoren, samtidig med at kun de webhook-stier, som integrationerne reelt har brug for, eksponeres.
Generér N8N_ENCRYPTION_KEY én gang, hold den ude af Git, og gem den sammen med recovery-manifestet, fordi en ændring kan gøre krypteret eller signeret applikations-state ugyldig. Afgræns adgang til filsystem og netværk, beskyt setup-endpoints, og definér grænser for upload, requests eller eksekveringer omkring execution concurrency, queue depth, binary payload size og long-running nodes i stedet for editor page views.
Hold n8n eksplicit, mens Dockup håndterer routing
Dockup's one-click n8n-deployment bør gøre udskiftning sikker: Routen fortsætter med at pege på 5678, secrets bygges ikke ind i imaget, og persistente stier kommer tilbage i den nye container. Det samme deployment kan køre på Dockup compute eller på en tilknyttet maskine.
Gennemfør det applikationsspecifikke arbejde ved at forbinde og teste Postgres til et persistent multi-user-produktionssetup, anvende den canonical offentlige adresse og køre denne acceptance-kontrol: Aktivér et workflow med en production-webhook, kald denne webhook udefra serveren, og bekræft, at eksekveringen når sin sidste node. Tilføj restore-resultatet til runbooken, før de rigtige brugere ankommer.
Ofte stillede spørgsmål
Hvad har n8n brug for i et production-deployment?
Route n8n-containeren via port 5678 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres til et persistent multi-user-produktionssetup. Kald ikke n8n klar, før du kan aktivere et workflow med en production-webhook, kalde denne webhook udefra serveren og bekræfte, at eksekveringen når sin sidste node.
Hvilke n8n-data hører hjemme i en backup?
Gør /home/node/.n8n persistent, og inkludér databasen samt .n8n-krypterings- og konfigurationsdataene i det samme recovery-manifest. En ren n8n-restore består kun, når restored credentials stadig kan dekrypteres, og et restored workflow modtager den samme offentlige webhook-URL.
Kræver n8n HTTPS bag en reverse proxy?
Brug HTTPS til den offentlige n8n-origin, og hold port 5678 på den interne route. Anvend n8n-indstillingen korrekt: Indstil WEBHOOK_URL til den præcise eksterne HTTPS-URL. For n8n beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet origin-følsom klientadfærd.
Hvordan bør en n8n-opgradering testes?
Gendan den aktuelle n8n-state i et isoleret deployment, anvend kandidatversionen, og gentag acceptance-transaktionen. Vær særligt opmærksom, fordi databasemigrationer, credential-kryptering og installerede community nodes skal forblive kompatible med den målrettede n8n-release. Behold det tidligere n8n-image, indtil grænsen for datamigration og rollback er forstået.