n8n zelf hosten op een VPS

Wat de licentie toestaat

Zelf gehoste n8n valt onder de Sustainable Use License, een fair-code-licentie die n8n in 2022 schreef. Je mag de software gratis gebruiken, aanpassen en verder verspreiden, met drie beperkingen: je mag hem alleen gebruiken voor je eigen interne bedrijfsdoeleinden of voor niet-commercieel en persoonlijk gebruik; je mag hem alleen kosteloos en voor niet-commerciële doeleinden aan anderen geven; en je mag de licentie- en copyrightvermeldingen van n8n niet verwijderen.

De regel die de meeste gevallen beslist, is de eerste in de licentie-FAQ van n8n: als workflows alleen worden gemaakt of aangepast door jou of door mensen in je organisatie, kun je de Community-licentie gratis gebruiken.

Toegestaan onder de Community-licentie

• Je eigen bedrijf erop draaien, en persoonlijke projecten, leren of onderzoek.
• Automatiseringen voor klanten bouwen op jouw instance, zolang de klanten ze niet kunnen maken of bewerken.
• Klanten laten betalen voor het bouwen, opzetten en onderhouden van workflows, en voor training en advies.
• n8n achter de schermen gebruiken in je eigen product, waarbij gebruikers automatiseringen starten die jij hebt gebouwd en zelfs hun eigen accounts koppelen.
• Meerdere instances draaien.

Niet toegestaan zonder commerciële overeenkomst

• n8n hosten als dienst waarin je klanten workflows bouwen.
• Externe gebruikers via je product hun eigen workflows laten bouwen of configureren, of dat nu via je eigen interface gaat, via de API, via MCP of via een AI-agent die namens hen handelt.
• De code forken om je eigen automatiseringsproduct te lanceren, of n8n white-labelen door de branding te verwijderen.
• Enterprise-functies die om een licentiesleutel vragen gebruiken zonder Enterprise-licentie.

Als je plan tussen de twee lijsten in valt, vraagt n8n je om naar license@n8n.io te schrijven voordat je het bouwt.

Hoe groot de server moet zijn

n8n vraagt weinig CPU. De pagina met vereisten zegt dat geheugen meestal zwaarder weegt dan CPU, en dat een n8n Cloud-instance in rust ongeveer 100 MB gebruikt. Wat het geheugengebruik opdrijft, is het werk zelf: grote JSON-payloads, binaire bestanden zoals pdf's en afbeeldingen, veel nodes in één workflow, de Code-node, en handmatige testruns, die een extra kopie van de data bewaren voor de editor.

Tel Postgres, de reverse proxy en het besturingssysteem op bij het cijfer voor n8n. Het getal waarop je plant, is de piek tijdens je zwaarste workflow, niet het cijfer in rust: draai die workflow één keer op de nieuwe server en kijk naar docker stats terwijl hij loopt. Als je de sandbox van de n8n Assistant wilt draaien vanuit het officiële Compose-bestand, beschouw 4 GB en 2 vCPU's dan als ondergrens.

Docker Compose met Postgres

Standaard slaat n8n alles op in SQLite. De Docker Compose-handleiding zegt dat SQLite prima is om dingen uit te proberen, maar dat een productie-instance met meer dan een handvol gebruikers, of met workflows die de klok rond draaien, Postgres moet gebruiken. Queue mode ondersteunt SQLite helemaal niet, dus wie op Postgres begint, bespaart zich later een migratie.

Installeer Docker Engine met de Compose-plugin, maak een map zoals ~/n8n en zet er twee bestanden in. Eerst het .env-bestand. Zet N8N_VERSION vast op een echt releasenummer van de GitHub-releasepagina van n8n, en genereer de encryptiesleutel zelf, zodat hij ook ergens anders dan op de server genoteerd staat:

# .env (keep it out of version control)
N8N_VERSION=2.xx.x
N8N_HOST=n8n.example.com
N8N_ENCRYPTION_KEY=change-me-long-random-string
POSTGRES_USER=n8n
POSTGRES_PASSWORD=change-me-password
POSTGRES_DB=n8n
GENERIC_TIMEZONE=Europe/Amsterdam

Daarna compose.yaml:

services:
  postgres:
    image: postgres:18
    restart: always
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
      PGDATA: /var/lib/postgresql/data
    volumes:
      - db-storage:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h localhost -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 10

  n8n:
    image: n8nio/n8n:${N8N_VERSION}
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      N8N_HOST: ${N8N_HOST}
      N8N_PORT: 5678
      N8N_PROTOCOL: https
      NODE_ENV: production
      N8N_WEBHOOK_URL: https://${N8N_HOST}/
      N8N_PROXY_HOPS: 1
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}
      TZ: ${GENERIC_TIMEZONE}
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  db-storage:
  n8n_data:

• Laat de regel PGDATA staan. Postgres 18 heeft de standaardlocatie voor data veranderd, en zonder die regel wordt de database buiten het volume geschreven en is hij leeg nadat de container opnieuw is aangemaakt.
• Poort 5678 is gebonden aan 127.0.0.1, dus alleen de reverse proxy op dezelfde server kan n8n bereiken. Alleen 80 en 443 hoeven open te staan naar het internet.
• Het volume n8n_data op /home/node/.n8n blijft ook met Postgres belangrijk: het bevat het bestand met de encryptiesleutel, logs en bestanden voor source control.

Start het met docker compose up -d. n8n maakt bij de eerste start zijn tabellen aan in Postgres. Data uit een eerdere SQLite-instance gaat niet vanzelf mee; exporteer workflows en credentials met de CLI-commando's uit het back-upgedeelte en importeer ze.

HTTPS, de reverse proxy en webhook-URL's

n8n bouwt webhook-URL's op uit N8N_PROTOCOL, N8N_HOST en N8N_PORT. Achter een proxy levert dat het verkeerde resultaat op, omdat n8n luistert op 5678 terwijl de publieke URL op 443 zit. De pagina over reverse proxy's vraagt om drie dingen:

1. Zet N8N_WEBHOOK_URL op het publieke adres, bijvoorbeeld https://n8n.example.com/. Het vervangt WEBHOOK_URL, dat vanaf n8n 2.35.0 verouderd is. Gebruik op versies vóór 2.30.0 WEBHOOK_URL.
2. Zet N8N_PROXY_HOPS=1 als er één proxy voor n8n staat.
3. Laat de laatste proxy X-Forwarded-For, X-Forwarded-Host en X-Forwarded-Proto doorgeven.

Elke proxy werkt als hij die drie dingen doet. Met Caddy is de hele configuratie vier regels. De reverse_proxy-directive van Caddy zet alle drie de forwarded-headers en geeft WebSocket-verbindingen door zonder extra instellingen, en Caddy vraagt zelf het certificaat voor het domein aan zodra DNS naar de server wijst:

# /etc/caddy/Caddyfile
n8n.example.com {
    reverse_proxy 127.0.0.1:5678
}

Als webhooks in de editor localhost:5678 tonen, of externe diensten de URL weigeren, ontbreekt N8N_WEBHOOK_URL of is de container niet opnieuw aangemaakt nadat je hem instelde. Draai docker compose up -d opnieuw na elke wijziging in de omgevingsvariabelen.

Queue mode: wanneer je Redis en workers nodig hebt

In de standaardmodus draait één n8n-proces de editor, ontvangt het webhooks en voert het elke workflow uit. Dat is genoeg voor de meeste instances van één team. Twee tekenen dat het niet meer genoeg is: uitvoeringen stapelen zich op achter langlopende uitvoeringen, of de editor reageert niet meer terwijl zware workflows draaien.

Probeer eerst de goedkope oplossing. N8N_CONCURRENCY_PRODUCTION_LIMIT begrenst hoeveel productie-uitvoeringen tegelijk draaien en zet de rest in een wachtrij; standaard staat dit uit. Als één proces dan nog steeds de bottleneck is, verdeelt queue mode het werk: het hoofdproces ontvangt triggers en webhooks, Redis houdt de wachtrij bij, en workerprocessen voeren de uitvoeringen uit.

# 1. in the n8n service: name the environment block, add the queue settings
    environment: &n8n-env
      # ...everything from before, plus:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: 6379
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started

# 2. two new services
  redis:
    image: redis:7
    restart: always

  n8n-worker:
    image: n8nio/n8n:${N8N_VERSION}
    restart: always
    command: worker --concurrency=10
    environment: *n8n-env
    depends_on:
      - postgres
      - redis

• Elk proces heeft dezelfde N8N_ENCRYPTION_KEY, dezelfde database-instellingen en dezelfde imageversie nodig.
• Een worker voert standaard 10 jobs tegelijk uit. n8n raadt 5 of meer per worker aan: veel workers met lage concurrency kunnen de connection pool van de database uitputten.
• Queue mode met SQLite wordt niet ondersteund, en binaire data kan niet op het lokale bestandssysteem blijven; n8n verwijst daarvoor naar externe opslag in S3.
• Voeg bij veel webhookverkeer webhookprocessors toe (n8n webhook) en zet N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true op het hoofdproces. Voor meerdere hoofdprocessen heb je een Enterprise-licentie nodig.

Back-ups waarmee je credentials kunt herstellen

Een volledige back-up bestaat volgens de pagina over back-up en herstel van n8n uit twee delen: de map .n8n, die de encryptiesleutel bevat, en de Postgres-database. Credentials in de database zijn versleuteld met die sleutel, dus met een databasedump zonder de sleutel kun je ze niet herstellen.

# workflows and credentials as JSON, one file each
docker compose exec n8n n8n export:workflow --backup --output=/home/node/.n8n/backups/workflows/
docker compose exec n8n n8n export:credentials --backup --output=/home/node/.n8n/backups/credentials/

# the whole Postgres database
docker compose exec -T postgres pg_dumpall -U n8n > n8n-db-$(date +%F).sql

• De vlag --backup schrijft elke workflow en elke credential als apart JSON-bestand. Gebruik aparte mappen voor workflows en credentials; het importeren van credentials mislukt als er workflowbestanden in dezelfde map staan.
• CLI-exports laten gebruikers, uitvoeringsgeschiedenis, variabelen en instance-instellingen weg, inclusief de sleutel. Ze verplaatsen workflows tussen instances; ze bouwen geen instance opnieuw op.
• Kopieer de dump, de exports en het volume .n8n naar een plek buiten de server. Een back-up op dezelfde schijf overleeft het verlies van de server niet.
• Geïmporteerde workflows komen gedeactiveerd binnen. Reken erop dat je ze na een herstel weer aanzet.

Updaten zonder verrassingen

De updatepagina van n8n raadt aan om minstens één keer per maand te updaten, zodat je nooit veel versies tegelijk overslaat, en om de release notes te lezen van elke versie tussen de jouwe en de doelversie.

# 1. back up first (see above), then set the new N8N_VERSION in .env
docker compose pull
docker compose up -d
docker compose logs -f n8n

Maak eerst de volledige back-up. Elk proces voert bij het starten openstaande databasemigraties uit, en de imagetag terugzetten naar de oude versie draait die niet terug. Terugrollen betekent n8n db:revert met het nieuwere image uitvoeren, één migratie per keer, of de back-up terugzetten. Update in queue mode het hoofdproces, de workers en de webhookprocessors samen naar dezelfde tag.

Veelvoorkomende fouten en oplossingen

De oplossingen voor geheugenproblemen komen van de pagina van n8n over geheugengerelateerde fouten. De heaplimiet verhogen ziet er zo uit:

# n8n service environment: raise the Node.js heap limit (value in MB)
      NODE_OPTIONS: --max-old-space-size=2048

Dit op Evorxa draaien

Alles hierboven werkt op een Evorxa-server, met root- en SSH-toegang. Je kunt beginnen met een kaal Ubuntu- of Debian-image, meestal binnen ongeveer een minuut klaar, of de n8n-app met één klik kiezen, die een paar minuten langer nodig heeft om te installeren. Plannen beginnen bij $2.99 per maand en worden vooraf betaald per maand, voor zes maanden of per jaar. Servers draaien in één regio, Eygelshoven in Nederland.

Bronnen

De feiten in deze gids komen van deze pagina's.

1. n8n: Sustainable Use License en licentie-FAQ
2. n8n: Installeren met Docker Compose (Postgres-gedeelte)
3. n8n: Webhook-URL's configureren met een reverse proxy
4. n8n: Queue mode inschakelen
5. n8n: Back-up en herstel
6. n8n: Geheugengerelateerde fouten