Zelfgehoste n8n: zo draai je n8n op je eigen server

Al zes maanden zie je je Zapier-rekening oplopen.

Elke nieuwe workflow voegt een regel aan de factuur toe, en elke geslaagde actiestap telt als een taak. De maandfactuur is inmiddels hoger dan die van je projectmanagementtool.

Je gaat op zoek naar alternatieven en komt uit bij n8n, een automatiseringsplatform dat je zelf kunt hosten op je eigen virtual private server (VPS), voor de prijs van een kleine server.

Geen uitvoeringsquotum. Geen prijs per taak. Geen onverwachte rekeningen als je automatiseringen een vlucht nemen.

En ja, we lopen alles met je door, commando voor commando: van een kale Ubuntu-server tot een draaiende instantie met HTTPS, back-ups en een geteste herstelprocedure.

Wat is n8n en waarom hosten mensen het zelf?

n8n is een platform voor workflowautomatisering waarmee je apps koppelt, gegevens tussen diensten verplaatst en complexe automatiseringen bouwt in een visuele editor. Zie het als de motor achter als X gebeurt, doe dan Y en Z, alleen sleep je nodes en trek je verbindingen in plaats van code te schrijven.

Het project heeft de grens van 200.000 GitHub-sterren gepasseerd en de officiële Docker-image is al meer dan 100 miljoen keer gedownload. Er draait dus op heel wat servers n8n.

Het platform valt onder een Sustainable Use License, en die is het waard om te begrijpen voordat je eraan begint. Het is geen traditionele open source (n8n gebruikt die term zelf niet, omdat door OSI goedgekeurde licenties het gebruik niet mogen beperken), maar het zit ook niet dichtgetimmerd. Je mag het vrij gebruiken voor de interne doeleinden van je eigen bedrijf. Je mag geen product, dienst of module verkopen waarvan de waarde volledig of grotendeels uit de functionaliteit van n8n komt.

Mensen kiezen ervoor om n8n zelf te hosten omdat de rekensom omslaat zodra je verder gaat dan basisgebruik. n8n Cloud begint bij €20 per maand (jaarlijks gefactureerd) voor 2.500 uitvoeringen met het Starter-abonnement. Draai je echt volume, dan loop je snel tegen die limieten aan.

Op je eigen VPS? Geen uitvoeringsquotum, controle over de gegevens die je n8n-instantie opslaat en geen licentie- of uitvoeringsrekening van n8n. Je server, domein, back-upopslag en beheer kosten wel geld. De uitvoeringen zelf kosten niets extra. Meer volume vraagt wel meer geheugen en opslag, maar dat is een kwestie van dimensionering (daarover hieronder meer), niet van facturering.

Wat kun je automatiseren met n8n?

Met meer dan 400 integraties dekt n8n veel terrein, en nodes uit de community breiden die lijst nog verder uit. n8n is bovendien maar een van de vele zelfgehoste alternatieven voor SaaS-tools. Dezelfde redenering geldt voor alles van CRM tot projectmanagement.

Een paar veelvoorkomende toepassingen:

• CRM en leadrouting. Synchroniseer contacten tussen je CRM, e-mailplatform en Slack zodra er nieuwe leads binnenkomen.
• Workflows die door webhooks worden gestart. Reageer in realtime op gebeurtenissen van betalingsverwerkers, formulierinzendingen of GitHub-commits.
• Automatisering van datapijplijnen. Haal gegevens op uit API's, bewerk ze en zet ze volgens een schema in databases of spreadsheets.
• Ketens van AI-agents. Koppel LLM's aan je interne tools om eigen AI-assistenten te bouwen die je gegevens kunnen doorzoeken, samenvatten en ermee aan de slag kunnen.

(Bij die laatste beginnen je serverresources er echt toe te doen. Daarover meer in het gedeelte over specificaties.)

Wat kost het om n8n zelf te hosten?

De zelfgehoste Community-editie kent voor toegestaan gebruik geen licentie- of uitvoeringskosten van n8n. Je totale kosten bestaan uit de server, plus eventueel een domein, back-upopslag en de tijd die beheer kost. De kostenanalyse van ExpressTech voor 2026 schat een kale VPS met Docker op $4–5 per maand, een VPS beheerd via Coolify op $5–8 en beheerde n8n-platforms met installatie in één klik op $3–7.

Dat zijn hostingschattingen van ExpressTech, een externe partij. Een cijfer uit eigen hand: het abonnement dat we hieronder aanraden, DreamHost VPS Hosting Stack 4, kost $8,99 per maand voor de eerste 3 maanden bij maandelijkse facturering en wordt daarna automatisch verlengd voor $15,99 per maand (stand augustus 2026). De volledige termijn plus belastingen wordt bij het afrekenen in rekening gebracht. De actuele prijzen vind je op de n8n-VPS-pagina.

Vergelijk dat met de eigen gehoste en gelicentieerde abonnementen van n8n, zoals vermeld op de prijspagina van n8n. n8n rekent in euro's, en dit zijn de tarieven bij jaarlijkse facturering:

Het verschil wordt groter als je kijkt hoe elk platform het gebruik telt. n8n rekent één uitvoering per workflowrun, regardless of complexity, en elk abonnement bevat onbeperkt veel stappen. Zapier telt daarentegen elke geslaagde actiestap als een taak.

Een workflow met vier actiestappen die 100 keer per dag draait, is dus 3.000 uitvoeringen per maand bij n8n, maar zo'n 12.000 taken bij Zapier.

Echte cijfers bevestigen dit. De analyse van ExpressTech werkt een voorbeeld uit met vier workflows die samen zo'n 7.000 uitvoeringen per maand draaien. Die werklast is te groot voor n8n Cloud Starter en vraagt om het Pro-abonnement (daar vermeld voor $60 per maand bij maandelijkse facturering), terwijl een zelfgehoste opzet van $3–7 per maand het zonder limieten draait. Volgens hen scheelt dat $636–684 per jaar.

De verborgen kosten van zelf hosten

De besparing in euro's en dollars is echt. Maar zelf hosten is niet in alle opzichten gratis.

Dit kost het je wel:

Je tijd. Hoeveel tijd onderhoud kost, hangt af van je werklast en ervaring, maar jij bent verantwoordelijk voor updates, back-ups, monitoring en hersteltests. Zwaardere opzetten met AI-automatiseringen vragen meer.

Gedoe met het instellen van OAuth. Om diensten als Google Workspace of Microsoft 365 te koppelen, moet je OAuth-referenties configureren. Reken per provider op extra installatietijd en volg de documentatie van de console van die provider. (Heb je ooit naar een laadicoontje zitten staren terwijl een toestemmingsscherm besluit of het je app vertrouwt, dan ken je het gevoel.)

TLS die je vertrouwt, maar wel controleert. De Caddy-proxy in de opzet hieronder vraagt automatisch een publiek vertrouwd certificaat aan en verlengt het, via een uitgever zoals Let’s Encrypt of ZeroSSL. Automatisch is niet hetzelfde als onbreekbaar: controleer na wijzigingen aan DNS of de proxy of het certificaat nog steeds wordt verlengd.

Inwerktijd als je nieuw bent met servers. De handleiding hieronder gaat ervan uit dat je via SSH op een server kunt inloggen, een bestand kunt bewerken en commando's kunt uitvoeren. Heb je dat nog nooit gedaan, reken dan naast de installatie zelf ook op leertijd.

Welke serverspecificaties heeft n8n nodig?

n8n zelf is licht. Het dichtst bij officiële dimensionering komen de voorbeeldcijfers in de OEM-implementatiedocumentatie van n8n, die n8n for illustrative purposes only, noemt en die gebaseerd zijn op n8n Cloud: een geheugenbereik van 320 MB tot 2 GB, een database op SSD van 512 MB tot 4 GB en ongeveer 100 MB geheugen voor een inactieve instantie. Als voorzichtige starttoewijzing, en dus niet als officieel minimum van n8n, kun je uitgaan van 2 GB om te testen en 4 GB zodra je PostgreSQL en productieworkflows toevoegt. Monitor representatieve workflows en voeg geheugen toe als de druk aanhoudend hoog is.

Onthoud ook dat n8n meestal eerder tegen geheugengrenzen aanloopt dan tegen CPU-grenzen. De documentatie van n8n zegt het onomwonden: het platform is isn’t CPU intensive, en usually, memory requirements supersede CPU requirements. Wat het geheugengebruik opdrijft, zijn je workflows: de hoeveelheid gegevens, Code-nodes (die gegevens vóór en na verwerking kopiëren) en grote binaire bestanden.

Dit is onze snelle berekening op de achterkant van een bierviltje voor voldoende speelruimte:

Dimensioneer op het aantal gelijktijdige uitvoeringen en de hoeveelheid gegevens die elke workflow verwerkt, en monitor daarna het geheugengebruik onder een representatieve werklast. Code-nodes en grote binaire payloads kunnen de geheugenbehoefte verhogen, dus houd marge over en schaal de VPS op als de monitoring aanhoudende druk laat zien.

Nieuw met VPS-hosting? Begin met de beginnersgids voor VPS van DreamHost om de basis te begrijpen voordat je je server dimensioneert.

Welke VPS kies je voor zelfgehoste n8n?

n8n publiceert geen vaste RAM-niveaus per werklast. Dimensioneer op gelijktijdige uitvoeringen en datavolume, houd marge over voor Docker en PostgreSQL, monitor daarna representatieve workflows en schaal op als de geheugendruk aanhoudt.

Zo zouden wij dat vertalen naar de abonnementen van DreamHost:

Naast RAM zijn er nog een paar specificaties die aandacht verdienen. n8n noemt SSD-opslag een best practice voor de database. Het geheugen is meestal belangrijker dan de CPU, maar waar het knelpunt echt zit, hangt af van hoeveel workflows er tegelijk draaien, de hoeveelheid gegevens en de nodes die je gebruikt. Ongelimiteerde bandbreedte is belangrijk als je workloads draait met veel webhooks en een constante stroom inkomende HTTP-verzoeken.

Kies een hostingomgeving waarin je Docker kunt draaien en de database, het netwerk, de permanente opslag en de reverse proxy zelf kunt configureren. Gewone gedeelde hosting biedt die mate van controle doorgaans niet.

De VPS-hosting-abonnementen van DreamHost voldoen aan alle belangrijke eisen (NVMe-SSD-opslag, ongelimiteerde bandbreedte, volledige root-toegang en ondersteuning voor Docker). Wil je de handmatige installatie hieronder liever overslaan? Dan kun je gebruikmaken van het feit dat n8n in de bibliotheek met apps zit die je met één klik installeert, vooraf geïnstalleerd met PostgreSQL en automatisch SSL.

Voor een n8n-server met productieworkflows kiezen wij Stack 8, het abonnement dat we op onze pagina's aanraden voor apps in productie. Stack 4 voldoet aan de starttoewijzing van 4 GB voor een eerste, lichte server. Per augustus 2026 kost dat $8,99 per maand voor de eerste 3 maanden bij maandelijkse facturering en wordt het automatisch verlengd voor $15,99 per maand, waarbij de volledige termijn plus belastingen bij het afrekenen in rekening wordt gebracht. De n8n-VPS-pagina toont altijd de actuele tarieven. Die verlengingsprijs is het eerlijke bedrag om te vergelijken met de €20 per maand van n8n Cloud Starter.

O ja, en nog iets om in je achterhoofd te houden voor later: als je gebruik groeit, ondersteunt n8n de wachtrijmodus, een schaalbare architectuur die de hoofdinstantie (gebruikersinterface, triggers, webhooks) scheidt van de uitvoering van workflows. Redis fungeert daarbij als berichtenbroker en worker-instanties voeren de taken uit. De documentatie van n8n noemt dit de modus die provides the best scalability.

Hoe installeer je n8n op een VPS?

Een zelfgehoste n8n-instantie opzetten kost 11 stappen: DNS, SSH beveiligen, een firewall, Docker, geheimen, een Compose-bestand voor de stack met drie containers (n8n, PostgreSQL en Caddy), het Caddyfile, opstarten en controleren, updates, back-ups en een hersteltest. Caddy is onze reverse proxy: de server die tussen het internet en je applicatie staat en TLS en routering afhandelt. We geven je de commando's voor de basisinstallatie en een handmatige test van back-up en herstel.

De commando's zijn bedoeld voor Ubuntu 22.04 of nieuwer. Vervang waar aangegeven het voorbeelddomein, de geheime waarden, de volumenaam en de gedateerde bestandsnamen van back-ups. De Docker Compose-documentatie van n8n behandelt hetzelfde met een Traefik-proxy, als je liever het eigen sjabloon van n8n volgt.

Wat je nodig hebt voordat je begint

• Een VPS met root-toegang met Ubuntu 22.04 of nieuwer en minimaal 2 GB RAM (voor productie raden we voorzichtigheidshalve 4 GB aan)
• Een domeinnaam die je naar het IP-adres van je server kunt laten verwijzen (voor TLS en toegang tot de n8n-editor)
• Basiservaring met de terminal — je weet hoe je via SSH inlogt op een server, een bestand bewerkt en commando's uitvoert

Nog één vereiste die op geen enkele officiële lijst staat: maak een back-up van je N8N_ENCRYPTION_KEY zodra je hem genereert. Daarom maak je de sleutel in stap 5 vóór de eerste start aan met openssl rand -hex 32, in plaats van n8n er stilletjes zelf een te laten genereren. Deze sleutel versleutelt al je opgeslagen inloggegevens, inclusief elke API-sleutel, elk OAuth-token en elk databasewachtwoord dat je hebt gekoppeld. De eigen Docker-documentatie van n8n waarschuwt dat n8n een nieuwe sleutel aanmaakt als de sleutel bij het opstarten niet te vinden is, waarna bestaande inloggegevens niet meer te ontsleutelen zijn. Dan mag je elke integratie helemaal opnieuw opbouwen (en vraag je je af waar het misging in je leven). Bewaar de sleutel op een veilige plek, los van je databaseback-ups.

Heb je van je provider alleen een root-login gekregen? Maak dan eerst een gebruiker voor de deployment aan. Dat doe je via de console van je provider of een SSH-sessie als root, voordat je de lokale SSH-commando's in stap 2 uitvoert:

adduser deploy
usermod -aG sudo deploy

Alles hieronder voer je uit als die gebruiker, met sudo waar nodig.

Stap 1: laat je domein naar de server verwijzen

Maak een DNS A-record aan voor een apart subdomein (in deze gids steeds n8n.example.com) dat naar het IP-adres van je server verwijst, precies zoals de Docker Compose-gids van n8n beschrijft. Doe dit als eerste: als de DNS-wijziging nog niet is doorgevoerd, kan Caddy geen certificaat ophalen en toont je browser mogelijk een beveiligingsfout in plaats van de n8n-editor.

Stap 2: beveilig de SSH-toegang

Genereer op je lokale computer een sleutelpaar (de OpenSSH-documentatie van Ubuntu raadt ed25519 aan) en kopieer het naar de server:

ssh-keygen -t ed25519
ssh-copy-id deploy@your_server_ip

Controleer of je met de sleutel kunt inloggen. Schakel daarna op de server het inloggen met een wachtwoord en als root uit, en controleer wat sshd daadwerkelijk afdwingt:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
EOF
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '

Het voorvoegsel 00- is bewust gekozen. Volgens de sshd_config-handleiding gebruikt OpenSSH voor elk sleutelwoord de eerste waarde die het leest, en images van cloudservers bevatten vaak al eerdere drop-ins in dezelfde map (cloud-init schrijft bijvoorbeeld zijn SSH-instellingen naar 50-cloud-init.conf). Noem je je bestand 99-hardening.conf, dan kan een van die fragmenten ongemerkt voorrang krijgen. sshd -t controleert de configuratie op fouten; sshd -T toont de effectieve instellingen nadat alle bestanden zijn samengevoegd. Controleer of het laatste commando passwordauthentication no en permitrootlogin no toont voordat je verdergaat. Herstart daarna sshd:

sudo systemctl restart ssh.service

De documentatie van Ubuntu waarschuwt dat een foute sshd-configuratie op een externe server je kan buitensluiten. Houd je huidige sessie open en test een nieuwe login in een tweede terminal voordat je iets sluit.

Stap 3: zet de firewall aan

Ubuntu levert UFW (Uncomplicated Firewall) standaard uitgeschakeld. Sta SSH toe voordat je de firewall inschakelt, zodat die je eigen sessie niet kan afbreken:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo ufw status

Drie poorten, verder niets. Eén Docker-specifieke waarschuwing uit de eigen installatiedocumentatie van Docker: poorten die Docker naar de host publiceert, omzeilen de UFW-regels volledig. Daarom publiceert het Compose-bestand in stap 6 alleen hostpoorten voor Caddy: 80 en 443 zijn de enige containerpoorten die Compose publiceert (SSH op poort 22 staat ook open), en n8n en PostgreSQL krijgen helemaal geen gepubliceerde hostpoorten.

Stap 4: installeer Docker en Docker Compose

Installeer Docker Engine vanuit de officiële apt-repository van Docker, niet met het gemaksscript get.docker.com, dat de documentatie van Docker alleen aanraadt voor testen en ontwikkeling. Eerst de vereisten en de ondertekeningssleutel van Docker:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Registreer daarna de repository zelf. Hiermee schrijf je het repositorybestand uit de Ubuntu-installatiegids van Docker weg, waarbij je Ubuntu-versie automatisch wordt ingevuld:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Installeer en controleer daarna:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

Toont hello-world zijn bevestigingsbericht? Dan zijn Docker en de Compose-plug-in klaar voor gebruik.

Stap 5: maak de projectmap en geheimen aan

Maak de projectmap aan en genereer daarna je encryptiesleutel. Laat n8n er bij de eerste start niet stilletjes zelf een verzinnen:

sudo mkdir -p /opt/n8n-compose
cd /opt/n8n-compose
openssl rand -hex 32

Kopieer de uitvoer nu meteen naar een veilige plek, buiten de server. Zet de sleutel daarna, samen met een sterk databasewachtwoord, in een beveiligd bestand .env naast je compose-bestand (Docker Compose leest het automatisch in). Vervang beide voorbeeldwaarden door je eigen waarden:

sudo tee /opt/n8n-compose/.env > /dev/null <<'EOF'
POSTGRES_PASSWORD=choose_a_strong_password
N8N_ENCRYPTION_KEY=paste_the_64_character_key_you_just_generated
EOF
sudo chmod 600 /opt/n8n-compose/.env

De chmod 600 is belangrijk: dit bestand bevat geheimen, dus alleen de eigenaar (root) mag het kunnen lezen. In het compose-bestand past N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true hetzelfde principe toe binnen de container. Volgens het overzicht van de beveiligingsvariabelen van n8n laat deze instelling n8n proberen om de rechten 0600 in te stellen op zijn eigen instellingenbestand.

Stap 6: schrijf het Docker Compose-bestand

Maak /opt/n8n-compose/docker-compose.yml aan (bijvoorbeeld met sudo nano /opt/n8n-compose/docker-compose.yml) en plak het volgende erin. Vervang n8n.example.com in beide URL-regels door je eigen domein en stel je tijdzone in:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.36.7
    restart: unless-stopped
    expose:
      - "5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=America/New_York
      - TZ=America/New_York
      - EXECUTIONS_DATA_MAX_AGE=168
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - n8n_data:/home/node/.n8n

  postgres:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=n8n
      - PGDATA=/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  caddy_data:
  caddy_config:
  n8n_data:
  postgres_data:

Vijf details hierin verdienen extra aandacht:

• De image is vastgezet op een specifieke versie (op het moment van schrijven is 2.36.7 de huidige stabiele release, volgens de installatiedocumentatie van n8n), zodat upgrades alleen plaatsvinden wanneer jij dat besluit.
• n8n publiceert geen hostpoort. Containers op het Compose-netwerk, waaronder Caddy, kunnen n8n bereiken, maar niet via een gepubliceerde hostpoort. De editor is dus alleen bereikbaar via de reverse proxy, nooit rechtstreeks vanaf internet.
• Door de healthcheck wacht n8n op PostgreSQL. Een kale depends_on wacht alleen tot de container is gestart, niet tot de database verbindingen accepteert. Het patroon condition: service_healthy komt rechtstreeks uit het eigen voorbeeld-compose-bestand voor Postgres van n8n, dat ook PostgreSQL 18 uitrolt.
• Het paar N8N_WEBHOOK_URL / N8N_PROXY_HOPS is belangrijk achter een proxy. Normaal bouwt n8n webhook-URL's op uit zijn protocol, host en poort, en volgens de documentatie van n8n werkt dat niet achter een reverse proxy. Daarom stel je de webhook-URL handmatig in, zodat n8n register the correct webhook URLs with external services,, zet je N8N_PROXY_HOPS op 1 en zorg je dat de proxy de headers X-Forwarded-For, X-Forwarded-Host en X-Forwarded-Proto doorgeeft. (Op dezelfde pagina staat dat N8N_WEBHOOK_URL de oudere WEBHOOK_URL vervangt, die vanaf n8n 2.35.0 verouderd is.)
• TZ en GENERIC_TIMEZONE hebben elk een andere taak. Volgens de Docker-documentatie van n8n stuurt GENERIC_TIMEZONE planningsnodes zoals Schedule aan, terwijl TZ de systeemtijdzone van de container instelt (wat commando's als date rapporteren). Geef beide dezelfde waarde.

(Begin vanaf dag één met PostgreSQL. n8n gebruikt standaard SQLite, wat prima werkt om te testen, maar de hostingtemplates van n8n raden PostgreSQL aan voor productie, en later migreren is pijnlijk op de had ik dit maar meteen goed gedaan-manier.)

Stap 7: schrijf de Caddyfile

Maak /opt/n8n-compose/Caddyfile aan met je domein (vervang ook hier n8n.example.com):

n8n.example.com {
    reverse_proxy n8n:5678
}

Dat is de hele configuratie van de reverse proxy. Volgens de documentatie van Caddy over automatische HTTPS haalt Caddy automatisch een publiek vertrouwd certificaat op en vernieuwt het, via een uitgever zoals Let’s Encrypt of ZeroSSL, en stuurt het HTTP door naar HTTPS, mits je DNS A-record naar de server verwijst en de poorten 80 en 443 openstaan (stap 1 en 3). Caddy is ook een van de reverse proxy's in de officiële hostingvoorbeelden van n8n.

Stap 8: starten en controleren

cd /opt/n8n-compose
sudo docker compose up -d
sudo docker compose ps

Wacht tot ps laat zien dat de postgres-container de status healthy heeft en n8n draait, en controleer dan vanaf een willekeurige computer de voordeur:

curl -fsS -o /dev/null -w '%{http_code}' https://n8n.example.com/

Een 2xx-code (of een 3xx-doorverwijzing) betekent dat Caddy de TLS-verbinding heeft afgehandeld en n8n heeft geantwoord. Sluit curl in plaats daarvan af met een fout, dan moet je DNS, het certificaat of de containers nakijken (begin met sudo docker compose logs caddy en sudo docker compose logs n8n). Open https://n8n.example.com in een browser en maak je eigenaarsaccount aan.

Stap 9: werk n8n bewust bij

n8n brengt bijna elke week een nieuwe minor-versie uit, en de update-instructies raden je aan om vóór het upgraden de changelog met ingrijpende wijzigingen te bekijken. Ben je er klaar voor? Pas dan de versietag aan in docker-compose.yml en voer daarna het volgende uit:

cd /opt/n8n-compose
sudo docker compose pull
sudo docker compose up -d

Met een vastgezette tag verandert alleen pullen niets: je kiest elke upgrade zelf door de tag te wijzigen, en dat is precies het doel van vastzetten. Maak vóór grote versie-updates een back-up (stap 10).

Stap 10: plan back-ups in

Voor een bruikbaar herstel heb je drie dingen nodig: de PostgreSQL-database, het volume n8n_data en het bestand .env dat N8N_ENCRYPTION_KEY levert. De Docker-documentatie van n8n zegt duidelijk dat de map /home/node/.n8n (ons volume n8n_data) ook bij gebruik van PostgreSQL essentiële gegevens bevat, waaronder het materiaal voor de encryptiesleutel. Maak van alle drie een back-up en bewaar docker-compose.yml en Caddyfile, zodat je de stack opnieuw kunt opbouwen. Het script hieronder regelt de database en het volume. Direct daarna kopieer je de configuratiebestanden naar een andere locatie. Maak het script aan als een bestand dat eigendom is van root:

sudo tee /opt/n8n-compose/backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
cd /opt/n8n-compose
STAMP=$(date +%Y-%m-%d)
mkdir -p /opt/n8n-backups
docker compose exec -T postgres pg_dump -U n8n -d n8n > "/opt/n8n-backups/n8n-db-${STAMP}.sql"
docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  tar czf "/backup/n8n-data-${STAMP}.tar.gz" -C /data .
find /opt/n8n-backups -name 'n8n-db-*.sql' -mtime +30 -delete
find /opt/n8n-backups -name 'n8n-data-*.tar.gz' -mtime +30 -delete
EOF
sudo chmod 700 /opt/n8n-compose/backup.sh
sudo /opt/n8n-compose/backup.sh

Opmerkingen bij het script: n8n-compose_n8n_data is de volumenaam die Compose aanmaakt voor een projectmap met de naam n8n-compose. Controleer de jouwe met sudo docker volume ls en pas de naam aan als die afwijkt. De twee find-regels bewaren back-ups 30 dagen; stel een andere bewaartermijn in die past bij je opslag en herstelbehoeften.

Plan het in via de crontab van root. De cron van root mag alleen een script uitvoeren dat eigendom is van root (chmod 700, met de .env op 600), nooit een bestand dat een andere gebruiker kan bewerken. Voer sudo crontab -e uit en voeg één regel toe zodat het script dagelijks om 3 uur 's nachts draait:

0 3 * * * /opt/n8n-compose/backup.sh

Het script maakt volgens schema een back-up van de PostgreSQL-database en het volume n8n_data. Kopieer het bestand .env (waarin je encryptiesleutel staat) en de Compose- en Caddy-bestanden nu naar een andere locatie, en doe dat opnieuw zodra ze veranderen. Maak op de server een tijdelijk beveiligd archief aan:

sudo tar -C /opt/n8n-compose -czf /home/deploy/n8n-config.tar.gz .env docker-compose.yml Caddyfile
sudo chown deploy:deploy /home/deploy/n8n-config.tar.gz
chmod 600 /home/deploy/n8n-config.tar.gz

Haal daarna vanaf je lokale computer het configuratiearchief samen met de back-ups binnen en verwijder de tijdelijke kopie op de server:

scp deploy@your_server_ip:/home/deploy/n8n-config.tar.gz .
scp -r deploy@your_server_ip:/opt/n8n-backups .
ssh deploy@your_server_ip 'rm /home/deploy/n8n-config.tar.gz'

Een back-up die alleen bestaat op de server die hij beschermt, verdwijnt samen met die server.

Stap 11: test een herstel op een test-VPS

Dit is een back-up- en herstelprocedure waarmee je controleert of je back-ups bruikbaar zijn. Test dit herstel op een nieuwe test-VPS, nooit op je productieserver. Richt een wegwerpserver in, herhaal daar stap 4 (Docker) en kopieer je projectbestanden (docker-compose.yml, Caddyfile, .env) en je meest recente gedateerde back-ups naar dezelfde paden.

Pas eerst de hostnaam aan: zet een testhostnaam (bijvoorbeeld n8n-restore-test.example.com, met een A-record dat naar de test-VPS verwijst) in N8N_HOST, N8N_WEBHOOK_URL en de Caddyfile. Voer daarna het volgende uit, met je eigen gedateerde bestandsnamen:

cd /opt/n8n-compose
sudo docker compose create
sudo docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  sh -c "cd /data && tar xzf /backup/n8n-data-2026-08-25.tar.gz"
sudo docker compose up -d --wait postgres
sudo docker compose exec -T postgres psql -U n8n -d n8n < /opt/n8n-backups/n8n-db-2026-08-25.sql
sudo docker compose run --rm n8n unpublish:workflow --all
sudo docker compose up -d

De regel unpublish:workflow --all gebruikt de ingebouwde Server CLI van n8n om de publicatie van elke herstelde workflow in te trekken voordat de instance start. Zo gaan herstelde schema's en triggers vanaf de testserver niet af op je productiesystemen. Sluit af met dezelfde curl-controle als in stap 8, maar dan op de testhostnaam.

Wees eerlijk tegen jezelf over wat een groen vinkje betekent: het bevestigt dat de database en het volume zijn hersteld en dat de stack zonder problemen start. Je workflows worden er niet mee getest via de editor, dus log in op de testinstance en controleer steekproefsgewijs de workflows die je niet kwijt wilt raken.

Hoe houd je een zelfgehoste n8n-instantie veilig?

Een zelfgehoste n8n-instance is zo veilig als de server waarop hij draait, en jij bent degene die die server beheert.

Beveiliging komt neer op zes dingen. Geen ervan is op zichzelf ingewikkeld, maar sla je er één over, dan laat je een echt gat open. De setup hierboven regelt de eerste drie al.

1. HTTPS via een reverse proxy. Open de n8n-editor nooit via gewone HTTP. De Caddy-configuratie in stap 7 haalt automatisch een publiek vertrouwd certificaat op en vernieuwt het, via een uitgever zoals Let’s Encrypt of ZeroSSL, en stuurt HTTP door naar HTTPS.
2. Firewall dichtzetten. UFW staat alleen SSH (22), HTTP (80) en HTTPS (443) toe. Stel de standaardpoort 5678 van n8n nooit rechtstreeks open voor internet. Het compose-bestand hierboven dwingt dit af door n8n geen gepubliceerde hostpoort te geven, zodat alleen containers op het Compose-netwerk n8n kunnen bereiken.
3. Netwerkisolatie met Docker. PostgreSQL en n8n communiceren via het interne Compose-netwerk. Je databasepoort wordt nooit op de host gepubliceerd, dus die is nooit van buitenaf bereikbaar.
4. Sterke authenticatie. Gebruik een sterk wachtwoord voor het eigenaarsaccount en schakel tweestapsverificatie in; de beveiligingsgids van n8n noemt 2FA als een van de aanbevolen beschermingsmaatregelen voor zelfgehoste instances.
5. Regelmatige updates. Pas de versietag in je compose-bestand aan, pull de nieuwe versie en herstart (stap 9). Lees eerst de changelog, want updates van n8n kunnen ingrijpende wijzigingen bevatten.
6. Back-ups die je echt hebt teruggezet. Stap 10 en 11 geven je het schema en de test. Een back-up die je nooit hebt getest, is een hoop, geen plan.

Nog één ding om in de gaten te houden. Het gaat niet strikt om beveiliging, maar het maakt wel een groot verschil. n8n slaat standaard de invoer en uitvoer van elke uitvoering op in zijn database. Opschonen staat standaard aan: n8n verwijdert uitvoeringen die ouder zijn dan 336 uur (14 dagen), of zodra je boven de 10.000 opgeslagen uitvoeringen komt. Een drukke instance kan PostgreSQL in de tussentijd toch flink laten groeien.

Zijn je workflows erg spraakzaam? Scherp het dan aan: stel EXECUTIONS_DATA_MAX_AGE=168 in om uitvoeringsgegevens ouder dan zeven dagen op te schonen (het compose-bestand hierboven doet dat al), of sla geslaagde runs helemaal niet op met EXECUTIONS_DATA_SAVE_ON_SUCCESS=none.

Wat zijn de afwegingen tussen zelf hosten en n8n Cloud?

Met zelfgehoste n8n krijg je een instance zonder uitvoeringslimiet en met controle over de gegevens die erin worden opgeslagen, voor de prijs van een kleine VPS plus je eigen beheer. Met n8n Cloud heb je geen serveronderhoud, maar wel uitvoeringslimieten per abonnement. De keuze komt erop neer of je je automatiseringsinfrastructuur zelf in handen wilt hebben of iemand anders wilt betalen om die te draaien.

De documentatie van n8n zegt het zo: n8n recommends self-hosting for expert users. Mistakes can lead to data loss, security issues, and downtime. If you aren’t experienced at managing servers, n8n recommends n8n Cloud.

Zo verhouden de twee opties zich tot elkaar:

Er is ook een middenweg die het kennen waard is. Beheerde platforms zoals PikaPods (ongeveer $3,80 per maand) en Elestio (ongeveer $17 per maand, volgens de vergelijking van ExpressTech) draaien zelfgehoste n8n zonder dat je de server zelf hoeft te beheren. Deze diensten kunnen je werk aan serverbeheer verminderen, maar controleer wel wie n8n-updates, back-ups, monitoring en beveiliging regelt.

Maar kijk ook naar het grotere plaatje. Bij elk gehost abonnement is je uitvoeringscapaciteit een prijsniveau, en het platform bepaalt die niveaus. Prijzen, quota en functies kunnen veranderen rond workflows die je al hebt gebouwd.

Als je zelf host, staan de instance en de gegevens die erin worden opgeslagen op infrastructuur die jij beheert (gekoppelde diensten ontvangen nog steeds alles wat je workflows naar ze sturen). Volledige controle, volledige verantwoordelijkheid.

De knoop doorhakken

Zelf hosten is zinvol als drie dingen samenvallen:

1. Je draait zoveel automatiseringen dat de uitvoeringslimieten in de cloud zouden knellen
2. Je wilt je workflowgegevens op infrastructuur die je zelf beheert
3. Jij (of iemand in je team) wilt verantwoordelijk zijn voor updates, back-ups en monitoring

Anders is n8n Cloud een redelijke keuze. Betalen voor het Starter-abonnement zodat je nooit naar Docker-logs hoeft te kijken, is een eerlijke ruil, zeker voor een klein team dat gewoon wil dat de automatiseringen draaien.

Maar zodra je klaar bent om de stap naar zelf hosten te zetten, valt de rekensom snel duidelijk uit. Een VPS met 4 GB is een praktisch startpunt, zij het niet met benchmarks onderbouwd; de productiecapaciteit hangt af van gelijktijdigheid, datavolume en de nodes die je gebruikt, dus monitor de instance en schaal op naarmate de vraag groeit. Begin klein, upgrade als je workflows groeien en houd volledige controle over je stack.

Dat laatste is belangrijker dan het misschien lijkt. Je kunt altijd overstappen naar een grotere server. Het is een stuk lastiger om je los te maken van een SaaS-platform nadat het zijn prijzen heeft aangepast rond de workflows die je al hebt gebouwd.

Veelgestelde vragen over n8n zelf hosten