n8n zelf hosten op VPS met Docker en HTTPS

Wat u bouwt

n8n is een tool voor workflowautomatisering: een visuele editor waarin een trigger, een webhook, een planning of een formulierinzending een keten van nodes activeert die API's aanroepen, data transformeren en naar andere systemen schrijven. Het is de standaardoplossing geworden voor AI-agent-workflows omdat het communiceert met elke modelprovider en database zonder dat u zelf een service hoeft te schrijven. Eén docker run zorgt binnen twee minuten voor een werkende editor. Deze handleiding richt zich op de overige negentig procent: het robuust maken van de installatie met Postgres in plaats van het standaard SQLite-bestand, het bereikbaar maken via HTTPS en – het onderdeel waar bijna iedereen de fout in gaat – zorgen dat webhooks een URL verstrekken die van buitenaf daadwerkelijk bereikbaar is.

De voltooide stack bestaat uit twee containers op één Docker-netwerk: n8n zelf en een Postgres-database die de workflows en inloggegevens opslaat. Een reverse proxy op de host handelt de TLS-termination af en stuurt het verkeer door naar n8n op localhost, waardoor er niets direct aan het internet wordt blootgesteld behalve via die proxy. Het draait naast de andere services op de 2026 self-hosting shortlist.

Vereisten en de reële limieten

U hebt een VPS nodig met minimaal 1 GB RAM. Reken op 2 GB zodra workflows daadwerkelijk werk uitvoeren, omdat uitvoeringen samen met de Node.js-runtime geheugen gebruiken. De out-of-memory-killer die de container halverwege een uitvoering beëindigt, is geen goede manier om daarachter te komen. Eén vCPU is in het begin voldoende. Als deze server ook iets zwaarders uitvoert, stemt u de capaciteit eerst af op die service. Een fotobibliotheek is meestal de boosdoener. De werkelijke RAM-minima voor PhotoPrism en Immich liggen veel hoger dan wat n8n nodig heeft. Hetzelfde geldt voor een mediaserver. Een Jellyfin-server met een doorzoekbare frontend, zoals Halcyon, dat de bibliotheek opnieuw opbouwt als een videotheek uit de jaren 90, gebruikt de beschikbare RAM en transcoderingscapaciteit al lang voordat n8n daar iets van merkt.

U heeft een domein of subdomein nodig, bijvoorbeeld n8n.example.com, met een A-record dat naar het publieke IP-adres van de VPS wijst en dat al resolveert voordat u een certificaat aanvraagt. Poort 80 en 443 moeten openstaan voor de proxy; de eigen poort 5678 van n8n mag niet direct verbonden zijn met het internet. U heeft Docker Engine en de Compose-plugin nodig; als docker compose version foutmeldingen geeft met docker: 'compose' is not a docker command, dan gebruikt u de oude standalone binary en is de plugin sudo apt install docker-compose-plugin.

SQLite is prima voor tests, Postgres voor alles waar u op vertrouwt

De standaarddatabase van n8n is een SQLite-bestand op /home/node/.n8n/database.sqlite. Voor een eerste verkenning is dit prima; als u geen volume koppelt, raakt u de data kwijt bij de eerste keer dat de container opnieuw wordt aangemaakt, wat op zichzelf al een leerzame les is. De reden om over te stappen op Postgres is niet de pure snelheid; het is het feit dat SQLite een single writer lock hanteert. Hierdoor zal een instantie die meerdere workflows tegelijk uitvoert, of de queue-modus die u uiteindelijk zult willen gebruiken, SQLITE_BUSY: database is locked-fouten geven bij gelijktijdig gebruik. Postgres heeft deze beperking niet, laat zich eenvoudig back-uppen met pg_dump en is de database waar de documentatie van n8n vanuit gaat voor een server waar u op vertrouwt. Achteraf overstappen betekent dat u de data handmatig moet migreren, dus als deze server belangrijk is, begin dan direct met Postgres.

DNS en de firewall

Stel eerst het record in en open de poorten, zodat de certificaatstap later niet mislukt door een naam die niet naar een IP-adres verwijst.

dig +short n8n.example.com
curl -s ifconfig.me
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

Open poort 5678 niet. Het compose-bestand bindt n8n aan 127.0.0.1:5678, zodat alleen de reverse proxy van de host deze kan bereiken; een ufw allow 5678 zou deze isolatie ongedaan maken.

Het Compose-bestand

Maak een werkmap en een docker-compose.yml aan. Dit is de volledige stack, bestaande uit twee services, één privaat netwerk en twee benoemde volumes.

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

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.29.10
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Europe/London
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n_net
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n_net:

Enkele beslissingen die direct verduidelijkt moeten worden. DB_POSTGRESDB_HOST=postgres is de servicenaam, die Docker op het gedeelde netwerk oplost, in tegenstelling tot localhost, wat binnen de n8n-container naar n8n zelf verwijst. De depends_on met condition: service_healthy voorkomt dat n8n tijdens het opstarten sneller is dan Postgres; zonder deze instelling start n8n, vindt het geen database en sluit het programma af. Het benoemde volume n8n_data op /home/node/.n8n bevat de encryptiesleutel en, bij gebruik van SQLite, de database; dit is de enige map die u niet mag verliezen. Pin de image vast op een exact versienummer, gebruik nooit latest; de redenen hiervoor staan in de onderstaande sectie over upgrades.

Het secrets-bestand

Plaats nooit wachtwoorden in het compose-bestand. Sla deze op in een .env-bestand dat ernaast staat en dat Compose automatisch inleest. Genereer ze zodanig dat ze daadwerkelijk willekeurig zijn.

printf 'POSTGRES_PASSWORD=%s\n'  "$(openssl rand -hex 24)" >  .env
printf 'N8N_ENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" >> .env
chmod 600 .env

De N8N_ENCRYPTION_KEY is hier de belangrijkste tekenreeks; dit is de sleutel waarmee elke opgeslagen inloggegeven wordt versleuteld. Stel deze expliciet in in plaats van n8n er zelf een te laten genereren, omdat een waarde die u zelf heeft gegenereerd, kan worden genoteerd en hersteld. Zodra n8n zijn eerste inloggegeven met deze sleutel heeft versleuteld, maakt het wijzigen ervan elk inloggegeven onleesbaar. Stel deze dus eenmalig in, doe dit nu, en wijzig deze regel daarna nooit meer.

De omgevingsvariabelen die bepalen of webhooks werken

Vier variabelen bepalen hoe n8n zichzelf presenteert aan de buitenwereld. Het onjuist instellen hiervan is de meest voorkomende vraag bij de n8n-support.

• N8N_HOST is de publieke hostnaam, n8n.example.com. Laat u dit op de standaardwaarde localhost staan achter een proxy, dan probeert de editor zijn eigen API te laden vanaf localhost in uw browser, wat mislukt.
• N8N_PROTOCOL=https vertelt n8n dat de service via TLS wordt aangeboden. Hierdoor markeert het de sessie-cookie als Secure en genereert het https://-URL's.
• N8N_PORT=5678 is de poort waarop n8n binnen de container luistert. Dit is niet de publieke poort; de proxy beheert poort 443.
• WEBHOOK_URL=https://n8n.example.com/ is de variabele die vaak voor problemen zorgt. n8n genereert de webhook-adressen die u in Stripe, GitHub of andere externe services plakt op basis van deze waarden. Als deze niet is ingesteld of onjuist is, valt n8n terug op N8N_HOST:N8N_PORT. U krijgt dan https://n8n.example.com:5678/webhook/... of, erger nog, http://localhost:5678/webhook/... te zien. Deze URL's lijken correct, maar zijn onbereikbaar vanaf het internet, waardoor verzoeken van externe services stilletjes verloren gaan. Stel deze in op de exacte publieke basis-URL inclusief de afsluitende slash en controleer daarna of de webhook-node een URL zonder poortnummer toont.

N8N_PROXY_HOPS=1 instrueert de Express-server van n8n om één proxy die ervoor staat te vertrouwen. Hierdoor zien rate-limiting en functies die het IP-adres van de client uitlezen het werkelijke adres in plaats van dat van de proxy. Eén variabele die u hier bewust niet moet instellen is N8N_RUNNERS_ENABLED: task runners, waarbij n8n de logica van de Code-node in een apart geïsoleerd proces uitvoert, zijn sinds versie 1.69 de standaard en zijn verplicht vanaf de 2.x-lijn die in deze handleiding wordt gebruikt. De oude opt-in is daarom verouderd. Stelt u deze nu in, dan logt n8n enkel een melding met het verzoek deze te verwijderen.

Eerste start

docker compose up -d
docker compose ps
docker compose logs -f n8n

Een gezonde eerste opstart eindigt met een Editor is now accessible via:-regel, met daarboven een n8n ready on ..., port 5678-regel. docker compose ps hoort beide containers Up te tonen, waarbij postgres gemarkeerd staat als (healthy). Als n8n in een Restarting-loop blijft hangen, lees dan de logs; dit wordt bijna altijd veroorzaakt door de databaseverbinding of de rechten op de volumes, zoals hieronder beschreven.

TLS met een reverse proxy

n8n communiceert zelf via standaard HTTP op poort 5678; een component aan de voorzijde handelt de HTTPS-terminatie af. Er zijn twee gangbare opties.

Als u al meerdere containers draait, plaats n8n dan achter een Traefik reverse proxy die automatisch TLS-certificaten uitgeeft. Met enkele labels vraagt en vernieuwt Traefik het certificaat voor u.

Als dit de enige applicatie op de server is, is een nginx virtual host met een Let's Encrypt-certificaat eenvoudiger. Gebruik de Certbot en nginx TLS-configuratie voor Ubuntu 24.04 om het certificaat te verkrijgen en gebruik vervolgens dit server-blok:

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
        client_max_body_size 16m;
    }
}

De headers Upgrade en Connection "upgrade" zijn verplicht. n8n verstuurt live uitvoeringsupdates naar de editor via een WebSocket; zonder deze twee regels laadt de inlogpagina, maar blijft deze hangen met een melding over een verloren verbinding. proxy_read_timeout 3600 voorkomt dat langlopende uitvoeringen worden afgebroken door de standaard nginx-timeout van 60 seconden. De header X-Forwarded-Proto $scheme is de aanvulling op N8N_PROXY_HOPS=1: deze vertelt n8n dat het oorspronkelijke verzoek HTTPS was, ook al bereikt de proxy de applicatie via standaard HTTP. Hierdoor concludeert n8n niet onterecht dat de verbinding onveilig is en weigert het de eigen cookie niet.

Uw eerste workflow, om het concreet te maken

Open https://n8n.example.com/, maak het eigenaarsaccount aan (volgende sectie) en bouw de kleinst mogelijke workflow die bewijst dat het pad werkt: een webhook als input, een HTTP-aanroep en een respons als output.

1. Voeg een Webhook-node toe. Stel de methode in op POST en een pad zoals hello. Deze toont twee URL's, een Test URL en een Production URL; dit is de bron van de helft van alle meldingen over "mijn webhook werkt niet". De Test URL beantwoordt één aanroep, en alleen terwijl u op Listen for test event heeft geklikt; daarna verloopt deze. De Production URL beantwoordt aanroepen zodra de workflow Active is.
2. Voeg daarna een HTTP Request-node toe, gericht op een willekeurige publieke JSON API; een GET naar https://api.github.com/zen geeft een string van één regel terug, wat voldoende is.
3. Voeg een Respond to Webhook-node toe en stel de Respond-optie van de Webhook-node in op "Using Respond to Webhook node", zodat de aanroeper de output van de HTTP-node terugkrijgt.
4. Zet de workflow op Active (rechtsboven) en roep deze aan: curl -X POST https://n8n.example.com/webhook/hello. U hoort de zen-regel terug te krijgen: POST erin, API-aanroep, respons eruit; dit is de structuur van de meeste echte automatiseringen.

Een geplande variant vervangt de Webhook-node door een Schedule Trigger en roept in plaats daarvan een model-endpoint aan. Een zelf-gehoste variant via Ollama draaiend op dezelfde VPS is een nette manier om een dagelijkse samenvatter te bouwen.

Gebruikersbeheer, geen basic auth

Oudere n8n-handleidingen adviseren u om N8N_BASIC_AUTH_ACTIVE=true in te stellen. Deze variabelen zijn in n8n 1.0 verwijderd en hebben nu geen effect meer. Tegenwoordig is authenticatie gebaseerd op het owner-account: wanneer u de editor voor het eerst opent, moet u in n8n een owner-account met e-mailadres en wachtwoord aanmaken. Deze toegangsbeveiliging is verplicht; anonieme toegang is niet beschikbaar. Maak het account direct na de eerste start aan, voordat u de URL aan anderen verstrekt: tussen docker compose up en het indienen van dat eerste formulier kan iedereen die de instance als eerste bereikt deze claimen. Een extra basic-auth-laag op de reverse proxy is een redelijke aanvullende beveiliging, maar dit is een tweede beveiligingslaag en niet de daadwerkelijke authenticatie. Het owner-account en alle overige functies in deze handleiding werken in de gratis Community Edition. Als u later extra gebruikers met gedetailleerde rollen of SSO wilt, is welke n8n-functies een betaalde licentie vereisen het lezen waard voordat u uw ontwerp daarop baseert.

Backups: eerst de encryptiesleutel, dan de database

Er moeten twee zaken worden geback-upt, en deze zijn niet in gelijke mate vervangbaar.

De N8N_ENCRYPTION_KEY. Elke inloggegeven dat u in n8n opslaat, API-tokens, databasewachtwoorden, OAuth-geheimen, wordt hiermee versleuteld opgeslagen. De workflows in Postgres zijn waardeloos zonder deze sleutel: als u de database terugzet op een nieuwe server met een andere sleutel, kan n8n geen enkel inloggegeven ontsleutelen. Er is geen herstel- of resetmogelijkheid. Uw .env-bestand bevat de sleutel; kopieer dit op de dag van aanmaak naar een locatie buiten de server, bij voorkeur in een wachtwoordmanager. Dit is de backup die er echt toe doet.

De Postgres-database, voor de workflows, de uitvoeringsgeschiedenis en de versleutelde inloggegevens zelf:

docker compose exec -T postgres pg_dump -U n8n -d n8n \
  | gzip > n8n-db-$(date +%F).sql.gz

Voer dit volgens een schema uit en kopieer de dump van de server af. Om te herstellen op een nieuwe VPS: start de stack eenmaal zodat de database bestaat, stop n8n, laad de dump terug met psql, plaats dezelfde N8N_ENCRYPTION_KEY in .env en start n8n. Dezelfde sleutel plus de dump resulteert in een werkende instantie; een nieuwe sleutel resulteert in workflows die geen enkel inloggegeven kunnen gebruiken.

Upgrades: de tag vastzetten

Het compose-bestand zet n8nio/n8n:2.29.10 vast in plaats van latest met een specifieke reden. n8n brengt bijna wekelijks een nieuwe minor-versie uit en wijzigt daarbij soms het databaseschema of het gedrag van nodes. Daarom betekent latest dat een onbeheerde pull een build kan ophalen die uw database migreert zodra deze opstart. Zet een versie vast, lees de release notes voordat u de versie verhoogt, n8n vermeldt daar ingrijpende wijzigingen (breaking changes), en voer upgrades bewust uit:

docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip > pre-upgrade.sql.gz
# edit the image tag in docker-compose.yml, then:
docker compose pull n8n
docker compose up -d n8n
docker compose logs -f n8n

Bij sprongen naar een nieuwe major-versie is dit het belangrijkst. De 2.0-lijn wijzigde bijvoorbeeld standaard N8N_BLOCK_ENV_ACCESS_IN_NODE naar true, waardoor elke Code-node die process.env las, stilletjes de toegang verliest totdat u dit terugzet naar false; dezelfde release begon met het afdwingen van strikte rechten op het instellingenbestand. Lees de pagina over ingrijpende wijzigingen in 2.0 voordat u een major-versie overschrijdt. n8n voert bij het opstarten automatisch alle benodigde databasemigraties uit, en dat is precies waarom de pg_dump vóór de upgrade niet optioneel is. Omdat inloggegevens versleuteld zijn met een sleutel in .env en de data in Postgres staat, zijn de containers vervangbaar: u voert een upgrade uit door ze te vervangen, en u rolt terug door de vorige tag vast te zetten en de dump terug te plaatsen.

Foutmodi en de bijbehorende meldingen

The requested webhook "POST hello" is not registered. Een 404-fout bij het aanroepen van een webhook waarvan de workflow niet op Active staat, of bij het aanroepen van het testpad terwijl er niemand luistert. Testpaden (/webhook-test/...) antwoorden alleen als u op "Listen for test event" heeft geklikt; productiepaden (/webhook/...) antwoorden alleen als de workflow-schakelaar is ingeschakeld. De verwante fout This webhook is not registered for GET requests. Did you mean to make a POST request? betekent dat de methode onjuist is; de node verwacht een POST-verzoek, maar u heeft een GET-verzoek verzonden.

De webhook-URL toont een :5678 of localhost. De node geeft https://n8n.example.com:5678/webhook/... of http://localhost:5678/... weer. WEBHOOK_URL is niet ingesteld of onjuist, waardoor n8n het adres heeft opgebouwd op basis van N8N_HOST:N8N_PORT in plaats van uw publieke basis-URL. Stel WEBHOOK_URL=https://n8n.example.com/ in, maak de container opnieuw aan met docker compose up -d, en de poort zal verdwijnen.

There was a problem loading init data in de browser. De editor is geladen, maar kan de eigen backend-API niet bereiken. Achter een proxy is dit bijna altijd een onjuiste N8N_HOST of WEBHOOK_URL, een proxy die de WebSocket Upgrade-headers mist, of N8N_PROTOCOL dat niet overeenkomt met de manier waarop u verbinding maakt. Controleer de vier publieke variabelen en zorg dat de proxy Upgrade en Connection doorstuurt.

password authentication failed for user "n8n" in de logs, waarbij de container herstart. Het wachtwoord dat n8n verstuurt, komt niet overeen met het wachtwoord waarmee de database is geïnitialiseerd. De valkuil: Postgres leest POSTGRES_PASSWORD alleen wanneer het een lege datamap initialiseert. Start de stack één keer, wijzig daarna POSTGRES_PASSWORD in .env, en het bestaande postgres_data-volume bevat nog steeds het oude wachtwoord. Stel het terug naar het origineel, of, als u geen gegevens hoeft te bewaren, docker compose down en docker volume rm het postgres-volume en start het opnieuw op.

EACCES: permission denied, open '/home/node/.n8n/config' bij het opstarten. n8n draait als de node-gebruiker (UID 1000) en kan niet naar de configuratiemap schrijven. Dit treft gebruikers die een hostmap (./n8n_data:/home/node/.n8n) mounten die eigendom is van root. Gebruik het benoemde volume zoals hierboven getoond, of als u per se een bind-mount wilt gebruiken, voer dan eerst sudo chown -R 1000:1000 ./n8n_data uit.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. Vanaf de 2.x-lijn dwingt n8n standaard 0600 af op dat instellingenbestand en herstelt dit zelf bij het opstarten. Deze logregel betekent dat de rechten al zijn gecorrigeerd, meestal na een bind-mount of nadat een herstelactie het bestand met te ruime rechten heeft teruggeplaatst. Er is geen actie vereist; stel N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false alleen in als uw bestandssysteem daadwerkelijk geen rechten ondersteunt.

Mismatching encryption keys, de volledige regel geeft aan dat de encryptiesleutel in het instellingenbestand /home/node/.n8n/config niet overeenkomt met de N8N_ENCRYPTION_KEY in uw omgeving. De sleutel in uw omgeving verschilt van degene die n8n bij een eerdere uitvoering naar het datavolume heeft geschreven. Dit gebeurt meestal omdat n8n een willekeurige sleutel genereerde bij een eerdere start toen de variabele niet was ingesteld, en u vervolgens een andere heeft ingesteld. Plaats de oorspronkelijke sleutel terug in .env, of, alleen als u echt geen opgeslagen inloggegevens heeft die u wilt behouden, verwijder het bestand config in het n8n_data-volume en laat n8n het opnieuw genereren. Houd er rekening mee dat bestaande inloggegevens hierdoor onleesbaar worden.

Een inlogbanner over beveiligde cookies: Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. U heeft N8N_PROTOCOL=https ingesteld, maar bereikte n8n via platte HTTP, meestal door direct het IP-adres en de poort te benaderen in plaats van de HTTPS-proxy. Benader het via https://n8n.example.com/. Stel N8N_SECURE_COOKIE=false alleen in als u echt geen HTTPS kunt gebruiken, en doe dit nooit op een server die direct met het internet is verbonden.

Om een taalmodel in die workflows te gebruiken, zie AI-workflows bouwen met Claude en n8n.

FAQ

Moet ik SQLite of Postgres gebruiken voor n8n?

SQLite (de standaard) is prima voor het uitproberen van n8n en voor een persoonlijke instantie die één workflow tegelijk uitvoert. Stap over op Postgres voor alles waar u afhankelijk van bent: de single writer lock van SQLite veroorzaakt database is locked bij gelijktijdig gebruik, en Postgres laat zich eenvoudig back-uppen met pg_dump. Later migreren is handmatig werk; als de server belangrijk is, begin dan direct met Postgres.

Waarom worden mijn n8n-webhooks nooit geactiveerd?

Dit komt bijna altijd door WEBHOOK_URL. Als deze niet of verkeerd is ingesteld, toont n8n webhook-adressen die zijn opgebouwd uit N8N_HOST:N8N_PORT, vaak met een :5678 of localhost erin. Deze lijken geldig, maar zijn onbereikbaar vanaf het internet, waardoor de verzoeken van de aanroeper nooit aankomen. Stel WEBHOOK_URL=https://n8n.example.com/ in en controleer of de node een URL zonder poort toont. De tweede oorzaak is het aanroepen van een webhook waarvan de workflow niet op Active staat, wat resulteert in The requested webhook ... is not registered..

Wat moet ik back-uppen in n8n?

Twee zaken. De N8N_ENCRYPTION_KEY uit uw .env-bestand, omdat elke opgeslagen inloggegeven hiermee is versleuteld en verlies ervan betekent dat ze permanent onleesbaar zijn; kopieer deze direct na aanmaak van de server af. En een pg_dump van de Postgres-database voor de workflows, geschiedenis en inloggegevens. Een herstelactie vereist beide: dezelfde sleutel en de dump.

Hoe plaats ik n8n achter HTTPS?

n8n levert standaard HTTP op poort 5678; een reverse proxy aan de voorzijde handelt de TLS-afsluiting af. Koppel n8n aan 127.0.0.1:5678 zodat alleen de proxy het kan bereiken, en gebruik vervolgens Traefik met automatische certificaten of nginx met een Let's Encrypt-certificaat. Stel N8N_PROTOCOL=https en WEBHOOK_URL=https://your-host/ in en zorg ervoor dat de proxy de WebSocket Upgrade-headers doorstuurt, anders loopt de editor vast.

Hoe upgrade ik n8n veilig?

Pin een specifieke image-tag in plaats van latest, maak eerst een pg_dump omdat n8n bij het opstarten automatisch migraties uitvoert, lees de release notes voor ingrijpende wijzigingen en verhoog daarna de tag en voer docker compose pull n8n && docker compose up -d n8n uit. De container is vervangbaar, dus u kunt terugdraaien door de vorige tag te pinnen en de dump van vóór de upgrade terug te zetten.