n8n implementatie en zelf-hosten

Waarom n8n en niet Zapier of Make

Zapier en Make zijn goede instap-tools. Ze zijn snel ingericht en je hebt geen server nodig. Maar zodra je workflows complexer worden, stuit je op grenzen: een tarifering per taak die oploopt als je veel data verwerkt, beperkte code-mogelijkheden als je iets moet bouwen dat niet in een standaard node past, en nauwelijks controle over waar je data naartoe gaat.

n8n pakt dat anders aan. De visual editor werkt vergelijkbaar met Zapier, maar je kunt op elk punt in een workflow eigen JavaScript of Python uitvoeren. Je bent niet beperkt tot wat de tool-bouwer voor jou heeft bedacht. En omdat n8n open source is, kun je het op eigen infra draaien: geen per-taak kosten, volledige data-soevereiniteit en geen afhankelijkheid van externe beschikbaarheid.

Het nadeel van zelf-hosten is dat je iets meer beheert. Dat is precies de afruil: meer controle, iets meer verantwoordelijkheid. Ik los dat op door de setup zo te bouwen dat je er zo min mogelijk naar om hoeft te kijken.

Zelf-hosten of n8n Cloud: de afruil

n8n biedt een beheerde cloud-variant aan. Voor kleine teams of als je geen VPS wilt beheren, is dat een valide keuze. Maar er zijn situaties waar zelf-hosten duidelijk de betere optie is:

• ▸Je verwerkt persoonsgegevens of klantdata die je niet bij een externe provider wil onderbrengen (GDPR-soevereiniteit).
• ▸Je hebt veel executions per maand: bij n8n Cloud betaal je op basis van workflowexecutions, bij zelf-hosten niet.
• ▸Je wilt queue mode inschakelen voor betrouwbare verwerking van grote batches zonder timeouts.
• ▸Je wilt workers horizontaal schalen als de belasting toeneemt.
• ▸Je wilt credentials opslaan in een eigen Vault of encrypted Postgres in plaats van bij een derde partij.

Voor teams zonder devops-capaciteit is n8n Cloud prima. Voor iedereen met een VPS of een bestaand Hetzner-account, en die honderdduizenden executions per maand draait of gevoelige data verwerkt, is zelf-hosten goedkoper en veiliger.

Mijn standaard n8n setup

Ik draai n8n zelf-hosted in productie op een Hetzner VPS. De stack die ik gebruik en ook bij klanten uitrol:

• ▸Docker Compose met een aparte container voor de n8n main-instance en een of meerdere worker-containers voor queue-verwerking.
• ▸PostgreSQL als backend-database in plaats van de standaard SQLite, zodat je workflow-history en credentials stabiel opgeslagen zijn.
• ▸Redis als queue-backend voor queue mode: workflows worden in een wachtrij gezet en door workers afgehandeld, ook als de main-instance herstarts.
• ▸Traefik als reverse proxy met automatische TLS via Let's Encrypt.
• ▸Dagelijkse geautomatiseerde backup van de Postgres-database naar een S3-compatible object store (Hetzner Object Storage of Backblaze B2).
• ▸Webhook-beveiliging via n8n's ingebouwde basic auth of API-key verificatie op gevoelige endpoints.

Het resultaat is een setup die crasht en herstelt zonder dat workflows verloren gaan. Queue mode zorgt dat een herstart van n8n of een server geen verloren executions betekent.

Wat ik typisch automatiseer met n8n

n8n is geen vervanging voor alles, maar voor een brede categorie van koppelings- en orkestratieproblemen is het de juiste tool. Voorbeelden uit de praktijk:

• ▸Formulier-submissions van een website of Typeform worden direct doorgestuurd naar een CRM, verrijkt met bedrijfsdata uit KvK of Clearbit, en een Slack-notificatie gestuurd.
• ▸Inkomende e-mail bijlagen worden gedownload, verwerkt (PDF-extractie, OCR of omzetten naar CSV) en opgeslagen in een gedeelde drive.
• ▸Webhook-orchestratie: meerdere externe diensten sturen events die n8n samenvoegt, dedupliceert en in de juiste volgorde verwerkt.
• ▸Dagelijkse rapportages: data uit meerdere bronnen ophalen, samenvoegen en als tabel of PDF per mail versturen.
• ▸Multi-stap goedkeuringsflows waarbij een manager een actie via e-mail of Slack goedkeurt voordat een downstream systeem wordt bijgewerkt.

De rode draad: n8n is sterk als er meerdere tools met elkaar moeten praten en er logica of condities nodig zijn. Simpele een-op-een koppelingen kunnen ook, maar dan is n8n misschien overkill.

Custom nodes bouwen in TypeScript

De ingebouwde node-bibliotheek van n8n dekt de meeste gangbare tools. Maar soms heb je een koppeling met een intern systeem, een niche-API of een dienst die n8n niet standaard ondersteunt. Daarvoor bouw ik custom nodes.

Een custom node is een TypeScript-pakket dat je naast n8n deployt. De node heeft een manifest met de velden die in de editor zichtbaar zijn, en een execute-methode die de daadwerkelijke API-call of logica uitvoert. Je publiceert de node als npm-pakket of laad je hem in via de n8n custom extension-map.

Het buildproces is overzichtelijk: TypeScript compileren, package structuur aanmaken, optioneel publiceren naar een private npm-registry. Na deployment is de node direct beschikbaar in de editor en gedraagt hij zich als elk andere node. Credentials worden via n8n's ingebouwde credential-systeem beheerd, dus je slaat geen sleutels op in de node-logica zelf.

Wat ik niet doe met n8n

n8n is een goed gereedschap, maar het is niet overal de juiste keuze. Ik gebruik n8n niet voor:

• ▸ETL-processen waarbij terabytes aan data door een pijplijn moeten: daarvoor zijn dedicated tools zoals dbt, Airbyte of Prefect beter geschikt.
• ▸Vervanging van een message queue-systeem zoals BullMQ, RabbitMQ of Kafka als je honderdduizenden berichten per minuut verwerkt en microseconde-latency nodig hebt.
• ▸Complexe state-machines waarbij je volledige controle over de executie-stack en retry-logica nodig hebt: dan bouw ik liever een lichtgewicht service in Node.js of Python.
• ▸Workflows die zo bedrijfskritisch zijn dat zelfs queue mode onvoldoende garanties biedt: dan is een proper job-orchestration systeem met SLA-monitoring de betere keuze.

Als je vraag op een van deze grenzen zit, zeg ik dat direct. Dan kijk ik samen met je naar de juiste tool.

Lees verder