Eisen voor de n8n-server

Hoeveel machine een zelf-gehoste n8n-instantie werkelijk nodig heeft, wat de database toevoegt, en het punt waarop één instantie niet meer genoeg is. De meeste sizingadviezen die je online vindt zijn geschreven voor queue-modus, die de meeste mensen nooit nodig hebben, dus het leest als een veel grotere eis dan het is.

Het korte antwoord

Een enkele n8n-instantie die normale workflows draait is geen veeleisende software. Twee vCPU en 2 GB RAM draaien ruimschoots een echte werklast van geplande taken, webhooks en API-aanroepen, want n8n besteedt het grootste deel van zijn tijd aan wachten op de diensten van anderen in plaats van aan rekenen. Het n8n-hoofdproces zelf gebruikt in rust ongeveer 300 MB.

Wat het aantal echt omhoog drijft, is niet hoeveel workflows je hebt gedefinieerd. Het is hoeveel data één uitvoering tegelijk in het geheugen houdt, en hoeveel uitvoeringen tegelijk draaien.

Wat geheugen in n8n verbruikt

n8n geeft data tussen nodes door als items die voor de levensduur van de uitvoering in het geheugen worden gehouden. Dat heeft één belangrijk gevolg voor de sizing: een workflow die tienduizend rijen ophaalt en die door vijf nodes laat lopen is een veel zwaardere huurder dan honderd workflows die elk een webhookpayload verplaatsen.

• Payloadgrootte per uitvoering. Grote HTTP-responses, spreadsheet-imports en binaire bestanden zijn de gebruikelijke oorzaak van een instantie die prima was en ineens niet meer is.
• Gelijktijdigheid. Tien uitvoeringen die tegelijk draaien houden elk hun eigen werkset vast. Een schema dat meerdere workflows op dezelfde minuut start, is een piek die je niet had gepland.
• Uitvoeringsgeschiedenis. Opgeslagen uitvoeringsdata stapelt zich op in de database. Het is een schijf- en databasekwestie in plaats van een RAM-kwestie, maar het is het ding dat stilletjes groeit gedurende maanden en dan toch ertoe doet.

De praktische implicatie: als je grote payloads verwerkt, splits ze dan. Een grote dataset in brokken opdelen doet meer voor de stabiliteit dan welke hoeveelheid extra RAM ook, want het verandert de piek in plaats van het plafond te verhogen.

De database is een eis, geen optimalisatie

n8n gebruikt standaard SQLite, wat prima is voor een proef en een slecht idee in productie. Het gaat slecht om met gelijktijdige uitvoeringen en is lastig betrouwbaar te back-uppen en te herstellen. PostgreSQL is het productieantwoord en het is in resourceopzicht niet gratis: reken op ruwweg 500 MB tot 1 GB, afhankelijk van je uitvoeringsgeschiedenis die meegroeit.

Dat getal is het getal dat de meeste sizingguides stilletjes in dezelfde doos stoppen als n8n zelf. Op een DIY-VPS komt het uit hetzelfde RAM als je workflows, samen met de containerruntime, een reverse proxy en het besturingssysteem. Bij onze abonnementen is de PostgreSQL-cluster een aparte high-availability-component met een eigen geheugen, dus de RAM in de abonnementsnaam is RAM voor n8n.

CPU: meestal niet de beperking

n8n wordt bepaald door wachten. Een uitvoering besteedt zijn tijd aan netwerkroundtrips naar API's, niet aan rekenen, dus twee cores komen ver. De uitzonderingen zijn reëel maar specifiek: zware datatransformatie in Code-nodes, grote JSON-parsing, en AI-workflows die zinvol lokaal werk doen in plaats van een model-API aan te roepen. Als je workflows vooral integraties zijn, voeg dan eerst RAM toe voordat je cores toevoegt.

Wanneer je queue-modus nodig hebt

Standaard draait n8n alles in één proces. Queue-modus splitst dat: een hoofdinstantie accepteert triggers en geeft uitvoeringen via Redis door aan aparte workerprocessen, zodat het hoofdproces responsief blijft, hoe lang een taak ook duurt. Het is het standaardantwoord op schalen van n8n, en het is ook de reden dat de meeste gepubliceerde sizingadviezen er zo zwaar uitzien.

Je hebt het nodig wanneer een van deze waar is, en niet eerder:

• Lange uitvoeringen blokkeren korte. Een workflow die vijf minuten duurt laat een inkomende webhook erachter wachten in single-process-modus. In queue-modus bevestigt de hoofdinstantie direct en doet een worker het werk.
• Je ziet een zichtbare achterstand. Het duidelijkste signaal is uitvoeringen die meer dan een paar seconden in een wachtstatus staan in de n8n-UI. Dat betekent dat er een wachtrij ontstaat, en geen hoeveelheid extra RAM op één proces neemt die weg.
• Eén zware taak kan de instantie ermee naar beneden halen. Isolatie is vaak de echte motivatie, eerder dan doorvoer.

Queue-modus voegt twee dingen toe aan je eisen. Redis, dat klein is, rond 128 MB, maar nog een component om te draaien is, en RAM per worker: elk workerproces verbruikt ongeveer 200 tot 500 MB, afhankelijk van wat je workflows meedragen. Twee workers is het verstandige startpunt, en je voegt er alleen meer toe wanneer de achterstand dat aangeeft. Workers hebben veel meer RAM nodig dan cores, en daarom voegt het gebruikelijke schaalpad twee- of driemaal geheugen toe voordat er CPU bij komt.

Eerlijk gezegd: een multi-worker-deployment in queue-modus heeft een Redis-component nodig en meer geheugen dan de bovenstaande niveaus bieden, dus daar zijn deze abonnementen niet voor. Ze zijn bedoeld voor single-instance n8n met een high-availability database, wat de grote meerderheid van de zelf-gehoste instanties ook daadwerkelijk is. Als je een achterstand hebt gemeten en werkelijk workers nodig hebt, ben je ontgroeid aan een one-click deployment en moet je daarvoor een dedicated stack dimensioneren.

Opslag, en het ding dat groeit

n8n zelf heeft heel weinig schijfruimte nodig. Uitvoeringsgeschiedenis is wat groeit, en het groeit evenredig met hoe vaak je workflows draaien in plaats van met hoeveel je er hebt. Een workflow die elke tien minuten een API pollt, levert op zichzelf al ongeveer 4,300 uitvoeringen per maand op. Stel een bewaarbeleid in voor opgeslagen uitvoeringsdata in plaats van te wachten tot de schijf de beslissing voor je neemt, en bewaar mislukte uitvoeringen langer dan geslaagde, want dat zijn de enige die je ooit gaat lezen.

Eisen die geen hardware zijn

Twee daarvan zijn belangrijker dan elke specificatie. Webhooks hebben een stabiele openbare HTTPS-URL nodig, wat betekent een echt domein, een geldig certificaat en een reverse proxy voor n8n; een zelf-gehoste instantie zonder dat kan schema's draaien maar niets ontvangen. En een automatiseringsplatform moet online zijn wanneer de trigger afgaat, wat een laptop uitsluit en uptime tot een eis maakt in dezelfde zin als RAM dat is.

Veelgestelde vragen