n8n zelf hosten in 2026: deployen, TLS, webhooks en back-ups

Een n8n-container kan groen zijn terwijl de taak die gebruikers belangrijk vinden niet werkt. Bij n8n bestaat die verborgen fout meestal uit webhooklinks die nog naar localhost verwijzen of proxyheaders die HTTP rapporteren. In deze handleiding beschouwen we “een workflow met een production-webhook activeren, die webhook van buiten de server aanroepen en bevestigen dat de execution de laatste node bereikt” als de acceptatietest. Vervolgens bouwen we de deployment terug vanaf dat resultaat.

n8n heeft een specifieke rol in de stack: workflowautomatisering met meer dan 400 integraties en een uitbreidbaar nodesysteem. De production-vraag is daarom niet of poort 5678 één keer antwoord geeft, maar of state, dependencies en het publieke adres na een restart, update en restore op elkaar afgestemd blijven.

Maak onderscheid tussen vervangbare containers en blijvende data

Definieer het recovery point en de recovery time voor n8n aan de hand van de database plus de .n8n-encryptie- en configuratiedata. Mount /home/node/.n8n vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Een named volume zorgt voor persistence bij een redeploy, maar beschermt niet tegen een compromise of verlies van de server.

Bouw een schone restore-omgeving, gebruik dezelfde vastgezette applicatieversie en bewijs dat herstelde credentials nog steeds kunnen worden gedecrypt en dat een herstelde workflow dezelfde publieke webhook-URL ontvangt. Leg commando’s, fixes voor ownership en de verstreken tijd vast. De handleiding voor back-ups is een bruikbare standaard: een back-up is pas betrouwbaar na een restore, niet na het uploaden.

Maak de startup van n8n reproduceerbaar

Een minimaal commando is nuttig wanneer het laat zien wat het platform later gaat beheren.

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

Hier blijft poort 5678 privé op de host en is elk vereist pad expliciet. Voeg de gecontroleerde verbindingsinstellingen voor Postgres toe voor een duurzame production-setup met meerdere gebruikers; gebruik private namen voor private services. Controleer de startup met zowel logs als applicatiespecifiek bewijs: activeer een workflow met een production-webhook, roep die webhook van buiten de server aan en bevestig dat de execution de laatste node bereikt. Zodra dit is geverifieerd, leg je de imageversie vast zodat een routinevervanging het gedrag niet ongemerkt verandert.

Poorten, processen en private services

Begin met de network namespace van n8n: de weblistener gebruikt poort 5678, niet een hostpoort die je uit een laptop-tutorial hebt overgenomen. Het netwerkcontract voor n8n is Postgres voor een duurzame production-setup met meerdere gebruikers. Houd private endpoints op interne DNS, sta alleen noodzakelijke uitgaande calls toe en geef n8n een servicecredential met beperkte scope.

Voer, zodra aan de vereiste is voldaan, het volledige scenario uit — activeer een workflow met een production-webhook, roep die webhook van buiten de server aan en bevestig dat de execution de laatste node bereikt. Leg logs en metingen vast voor execution concurrency, queue depth, de grootte van binary payloads en langlopende nodes in plaats van editorweergaven. Dat bewijs vormt de eerste bekende goede architectuur en maakt latere verhuizingen tussen Dockup compute en een aangesloten server testbaar.

Voorkom dat proxy-success applicatiefouten verbergt

De publieke boundary voor n8n moet bestaan uit één canonical hostname, automatische TLS en één intern target op 5678. Stel WEBHOOK_URL in op de exacte externe HTTPS-URL, zodat clients terugkeren naar een adres dat de service herkent.

Als de acceptatietransactie mislukt, classificeer dan de eerste fout. Problemen met DNS, certificaten en 502 horen thuis in de TLS-validatiechecklist. De situatie “webhooklinks verwijzen nog naar localhost of proxyheaders rapporteren HTTP” hoort bij de applicatiekant, nadat een request n8n succesvol heeft bereikt.

Wat moet slagen voordat er echte n8n-data binnenkomt

Maak van de n8n-smoketest een herhaalbaar releasecommando of een korte runbook. De output moet deze uitkomst aantonen: activeer een workflow met een production-webhook, roep die webhook van buiten de server aan en bevestig dat de execution de laatste node bereikt. Leg de applicatieversie, containerdigest, route-hostname en identifier van de testdata samen met het resultaat vast.

Voer dezelfde controle uit na een routinevervanging van de container en na het elders herstellen van de database plus de .n8n-encryptie- en configuratiedata. De restore is geslaagd wanneer herstelde credentials nog steeds kunnen worden gedecrypt en een herstelde workflow dezelfde publieke webhook-URL ontvangt. Vergelijk timing en verbruik voor execution concurrency, queue depth, de grootte van binary payloads en langlopende nodes in plaats van editorweergaven; een grote verandering verdient onderzoek, ook wanneer de laatste actie nog steeds slaagt.

Test vervolgens een veilige fout: blokkeer tijdelijk de toegang van de testidentiteit tot Postgres voor een duurzame production-setup met meerdere gebruikers. Bevestig dat n8n de fout zichtbaar maakt en zonder destructieve handmatige wijzigingen terugkeert naar de normale toestand. Bewaar alleen het noodzakelijke, geredigeerde logfragment. Deze gate in vier delen dekt startup, persistence, recovery en foutafhandeling.

Capaciteits- en upgradecontroles

Bouw dashboards rond execution concurrency, queue depth, de grootte van binary payloads en langlopende nodes in plaats van editorweergaven. Een CPU-grafiek zonder context over de workload kan niet verklaren waarom n8n traag is. Voeg een synthetische of geplande controle toe die probeert een workflow met een production-webhook te activeren, die webhook van buiten de server aan te roepen en te bevestigen dat de execution de laatste node bereikt met onschadelijke testdata.

Houd vóór een upgrade rekening met dit applicatiespecifieke risico: databasemigraties, credential-encryptie en geïnstalleerde community nodes moeten compatibel blijven met de doelversie van n8n. Herstel een recente back-up in een geïsoleerde deployment, voer daar de migraties uit en vergelijk het gedrag. Als webhooklinks nog naar localhost verwijzen of proxyheaders HTTP rapporteren, inspecteer dan eerst de betrokken boundary — public origin, storage of dependency — voordat je niet-gerelateerde instellingen aanpast.

Beveilig n8n na de bootstrap

Neem beveiligingsaannames uit een lokale tutorial niet zomaar over. Voor n8n is het specifieke aandachtspunt het roteren van N8N_ENCRYPTION_KEY nadat credentials zijn opgeslagen. In production moet de editor daarom geauthenticeerd blijven en mogen alleen de webhookpaden worden blootgesteld die integraties daadwerkelijk nodig hebben.

Genereer N8N_ENCRYPTION_KEY één keer, houd deze buiten Git en bewaar hem in het recovery-manifest, omdat wijzigen ervan versleutelde of ondertekende applicatiestate ongeldig kan maken. Beperk filesystem- en netwerktoegang, bescherm setup-endpoints en definieer limieten voor uploads, requests of executions rond execution concurrency, queue depth, de grootte van binary payloads en langlopende nodes in plaats van editorweergaven.

Houd n8n expliciet terwijl Dockup de routing afhandelt

De one-click n8n-deployment van Dockup moet vervanging veilig maken: de route blijft naar 5678 wijzen, secrets worden niet in de image ingebakken en persistente paden keren terug in de nieuwe container. Dezelfde deployment kan op Dockup compute of op een aangesloten machine draaien.

Rond het applicatiespecifieke werk af door Postgres te verbinden en te testen voor een duurzame production-setup met meerdere gebruikers, het canonical public address toe te passen en deze acceptatiecheck uit te voeren: activeer een workflow met een production-webhook, roep die webhook van buiten de server aan en bevestig dat de execution de laatste node bereikt. Voeg het restore-resultaat aan het runbook toe voordat echte gebruikers arriveren.

Veelgestelde vragen

Wat heeft n8n nodig voor een production-deployment?

Routeer de n8n-container op poort 5678 via één HTTPS-origin. De vereiste voor het ondersteunende netwerk is Postgres voor een duurzame production-setup met meerdere gebruikers. Verklaar n8n pas gereed wanneer je een workflow met een production-webhook kunt activeren, die webhook van buiten de server kunt aanroepen en kunt bevestigen dat de execution de laatste node bereikt.

Welke n8n-data hoort in een back-up?

Maak /home/node/.n8n persistent en neem de database plus de .n8n-encryptie- en configuratiedata op in hetzelfde recovery-manifest. Een schone n8n-restore is alleen geslaagd wanneer herstelde credentials nog steeds kunnen worden gedecrypt en een herstelde workflow dezelfde publieke webhook-URL ontvangt.

Heeft n8n HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke n8n-origin en houd poort 5678 op de interne route. Pas de n8n-instelling correct toe: stel WEBHOOK_URL in op de exacte externe HTTPS-URL. Voor n8n beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het voor consistent gedrag van clients die gevoelig zijn voor de origin.

Hoe test je een n8n-upgrade?

Herstel de actuele n8n-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let vooral hierop, omdat databasemigraties, credential-encryptie en geïnstalleerde community nodes compatibel moeten blijven met de doelversie van n8n. Bewaar de vorige n8n-image totdat de grenzen voor datamigratie en rollback duidelijk zijn.