n8n Docker Setup: Compose, PostgreSQL und Queue-Mode

n8n Docker ist für die meisten Teams der einfachste Einstieg, um die Open-Source-Automatisierungsplattform selbst zu hosten. Statt einzelne Node.js-Abhängigkeiten zu pflegen, ziehen Sie ein fertiges Image, hängen ein Volume ein und haben in wenigen Minuten eine laufende Instanz. Der Teufel steckt allerdings im Detail: Ohne feste Konfiguration verlieren Sie beim ersten Neustart Ihre gespeicherten Zugangsdaten, und mit der Standard-Datenbank stoßen Sie unter Last schnell an Grenzen. Dieser Leitfaden zeigt Schritt für Schritt, wie Sie n8n mit Docker sauber aufsetzen: vom offiziellen Image über Docker Compose mit PostgreSQL bis zum Queue-Mode mit Redis.

Kurz gesagt: Um n8n mit Docker zu betreiben, starten Sie das offizielle Image docker.n8n.io/n8nio/n8n, hängen ein persistentes Volume ein und setzen einen festen N8N_ENCRYPTION_KEY. Für den Produktivbetrieb ergänzen Sie per Docker Compose eine PostgreSQL-Datenbank (DB_TYPE=postgresdb) und, bei hoher Last, den Queue-Mode mit einem Redis-Container. So bleiben Workflows, Credentials und Ausführungen dauerhaft erhalten.

Warum n8n über Docker betreiben?

n8n ist eine Node.js-Anwendung mit vielen Abhängigkeiten. Eine native Installation funktioniert, macht aber Updates, Rollbacks und den Umzug auf einen anderen Server unnötig kompliziert. Ein Container kapselt die komplette Laufzeitumgebung: Sie tauschen den Image-Tag aus und bekommen ein reproduzierbares Update. Genau deshalb ist Docker der offiziell empfohlene Weg, n8n selbst zu hosten.

Drei Konfigurationsentscheidungen bestimmen dabei, ob Ihr Setup produktionsreif ist oder beim ersten Zwischenfall Daten verliert: die Datenbank, der Encryption-Key und das persistente Volume. Wir gehen sie einzeln durch.

n8n Docker Setup: das offizielle Image

Für einen ersten Test genügt ein einzelner Container. Legen Sie zuerst ein benanntes Volume an, damit die interne SQLite-Datenbank einen Neustart übersteht, und starten Sie dann das Image:

bash

docker volume create n8n_data

docker run -d --name n8n \
  -p 5678:5678 \
  -e N8N_ENCRYPTION_KEY="$(openssl rand -base64 32)" \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Danach erreichen Sie die Oberfläche unter http://localhost:5678. Das ist gut zum Ausprobieren, aber noch nicht produktionsreif: n8n legt hier standardmäßig alles in einer SQLite-Datei im Volume ab. Für einen ernsthaften Betrieb sollten Sie auf PostgreSQL wechseln und mehrere Container über Docker Compose orchestrieren. Details zum Image und den unterstützten Tags stehen in der offiziellen n8n-Docker-Dokumentation.

SQLite oder PostgreSQL: die richtige Datenbank für n8n

n8n startet ohne Zusatzkonfiguration mit SQLite. Das ist bequem, weil keine zweite Komponente nötig ist. Der Haken: SQLite serialisiert Schreibzugriffe. Sobald mehrere Workflows gleichzeitig laufen oder Sie viele Ausführungsdaten speichern, wird die Datei zum Engpass, und der Queue-Mode ist mit SQLite gar nicht erst möglich.

PostgreSQL löst beide Probleme. Es verträgt nebenläufige Zugriffe, skaliert mit der Datenmenge und lässt sich sauber sichern. Für alles jenseits einer reinen Testinstanz ist PostgreSQL die richtige Wahl. Aktivieren lässt es sich über die Umgebungsvariable DB_TYPE=postgresdb plus die passenden Verbindungsdaten. Wenn Sie PostgreSQL nicht selbst betreiben möchten, finden Sie im Beitrag zu kostenlosem PostgreSQL-Hosting einen Überblick über verwaltete Optionen.

docker-compose.yml: n8n mit PostgreSQL

Mit Docker Compose beschreiben Sie n8n und die Datenbank gemeinsam in einer Datei. Das folgende Beispiel startet PostgreSQL, wartet per Healthcheck auf dessen Bereitschaft und verbindet n8n darüber:

yaml

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

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: bitte-aendern
      N8N_ENCRYPTION_KEY: ihr-fester-schluessel
      N8N_HOST: n8n.ihre-domain.de
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.ihre-domain.de/
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

Zwei Volumes sind hier entscheidend: postgres_data sichert die eigentlichen Datenbankinhalte, n8n_data bewahrt lokale Einstellungen unter /home/node/.n8n. Wer die Compose-Syntax vertiefen möchte, findet in unserer Docker-Compose-Anleitung die Grundlagen zu Services, Netzwerken und Volumes.

Der N8N_ENCRYPTION_KEY: Credentials über Neustarts retten

Der wohl häufigste Fehler beim Selbst-Hosten: Man vergisst, den Encryption-Key festzulegen. n8n erzeugt dann bei jedem frischen Start einen zufälligen Schlüssel, und gespeicherte Zugangsdaten lassen sich nach einem Container-Neuaufbau nicht mehr entschlüsseln.

Der N8N_ENCRYPTION_KEY ist der geheime Schlüssel, mit dem n8n alle gespeicherten Zugangsdaten (Credentials) verschlüsselt. Bleibt er über Neustarts hinweg konstant, lassen sich vorhandene Credentials weiterhin entschlüsseln. Ändert er sich, werden alle gespeicherten Zugangsdaten unbrauchbar und müssen neu angelegt werden.

Erzeugen Sie den Schlüssel einmalig, etwa mit openssl rand -base64 32, und behandeln Sie ihn wie ein Passwort. In Compose gehört er als Umgebungsvariable in eine .env-Datei, nicht ins Repository. Bei einem späteren Umzug nehmen Sie exakt denselben Wert mit, sonst starten Sie mit einer leeren Credential-Liste.

WEBHOOK_URL richtig setzen

Viele Automatisierungen in n8n reagieren auf eingehende Webhooks. Damit n8n externen Diensten die korrekte, öffentlich erreichbare Adresse mitteilt, müssen Sie WEBHOOK_URL explizit auf Ihre echte HTTPS-Domain setzen. Ohne diese Variable generiert n8n Webhook-Adressen auf Basis von localhost, und externe Systeme können Ihre Workflows nicht mehr auslösen.

Hinter einem Reverse Proxy (etwa Traefik, Caddy oder nginx), der die TLS-Terminierung übernimmt, setzen Sie zusätzlich N8N_PROTOCOL=https und N8N_HOST auf Ihre Domain. Achten Sie darauf, dass die WEBHOOK_URL mit einem Schrägstrich endet und exakt der Adresse entspricht, unter der die Instanz von außen erreichbar ist.

Queue-Mode: n8n mit Redis skalieren

Im Standardbetrieb (regular) arbeitet ein einzelner Prozess alle Workflows nacheinander ab. Das reicht lange, doch bei vielen parallelen Ausführungen oder rechenintensiven Nodes wird dieser Prozess zum Flaschenhals. Hier kommt der Queue-Mode ins Spiel.

Der Queue-Mode ist die skalierbare Betriebsart von n8n: Ein Main-Prozess nimmt Auslöser und Webhooks entgegen und legt Aufgaben in eine Redis-Warteschlange. Aus dieser holen ein oder mehrere Worker-Prozesse die Workflows und arbeiten sie parallel ab. So verteilt sich die Last auf beliebig viele Container.

Sie benötigen dafür drei Bausteine: den bestehenden n8n-Prozess (jetzt mit EXECUTIONS_MODE=queue), einen Redis-Container als Warteschlange und mindestens einen zusätzlichen Worker. Ergänzen Sie Ihre Compose-Datei:

yaml

redis:
    image: redis:7
    restart: unless-stopped
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    command: worker
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: bitte-aendern
      N8N_ENCRYPTION_KEY: ihr-fester-schluessel
    depends_on:
      - redis
      - postgres

Setzen Sie beim Haupt-Service n8n ebenfalls EXECUTIONS_MODE: queue und QUEUE_BULL_REDIS_HOST: redis. Worker und Main teilen sich zwingend dieselbe PostgreSQL-Datenbank und denselben Encryption-Key. Mehr Durchsatz erreichen Sie, indem Sie weitere Worker-Container starten. Alle technischen Details beschreibt die n8n-Dokumentation zum Queue-Mode.

SQLite vs. PostgreSQL im Vergleich

Kriterium	SQLite (Standard)	PostgreSQL
Einrichtung	keine, sofort einsatzbereit	zweiter Container plus Verbindungsdaten
Nebenläufige Ausführungen	serialisiert, wird zum Engpass	echte parallele Schreibzugriffe
Queue-Mode möglich	nein	ja
Große Datenmengen	verliert bei viel Verlauf an Tempo	skaliert mit der Datenmenge
Backups und Wiederherstellung	Datei kopieren	Dump, Restore, Point-in-Time-Recovery
Empfohlen für	lokale Tests, Demos	jeden Produktivbetrieb

Die Faustregel ist klar: SQLite zum Ausprobieren, PostgreSQL für alles, was zuverlässig laufen soll. Der Umstieg ist unkompliziert, solange Sie ihn vor dem Anlegen wichtiger Workflows vollziehen.

n8n auf Out Plane deployen

Docker Compose auf einem eigenen Server bedeutet, dass Sie Betriebssystem, TLS-Zertifikate, Backups und Updates selbst verantworten. Out Plane nimmt Ihnen genau diese Betriebslast ab: Sie beschreiben die Container, die Plattform baut das Image, startet den Dienst und stellt HTTPS automatisch bereit. Was eine PaaS grundsätzlich für Sie übernimmt, erklärt der Beitrag Was ist eine PaaS?.

So bringen Sie das oben gezeigte Setup auf Out Plane:

n8n als App anlegen. Da die Plattform aus einem Dockerfile baut, genügt ein einzeiliges Dockerfile, das das offizielle Image umschließt: FROM docker.n8n.io/n8nio/n8n. Die App lauscht auf Port 5678.
Managed PostgreSQL anhängen. Statt einen eigenen Postgres-Container zu betreiben, hängen Sie eine verwaltete PostgreSQL-Datenbank an. Sie bringt Backups, Point-in-Time-Recovery und Connection-Pooling mit. Tragen Sie die bereitgestellten Verbindungsdaten als DB_TYPE=postgresdb und die zugehörigen DB_POSTGRESDB_*-Variablen ein.
Encryption-Key als Umgebungsvariable setzen. Hinterlegen Sie N8N_ENCRYPTION_KEY einmalig in den App-Variablen. So bleibt er über jedes Deployment hinweg stabil, und Ihre Credentials überstehen Neustarts.
HTTPS und WEBHOOK_URL. Ihre App ist automatisch per TLS unter einer Adresse nach dem Muster n8n-5678-ihrteam.outplane.app erreichbar. Setzen Sie WEBHOOK_URL auf genau diese HTTPS-Adresse.
Redis für den Queue-Mode selbst hosten. Out Plane bietet PostgreSQL als verwalteten Dienst an, eine managed Redis gibt es nicht. Für den Queue-Mode betreiben Sie Redis als eigene App mit einem persistenten Volume und verbinden es über das private Netzwerk. Anschließend zeigt QUEUE_BULL_REDIS_HOST auf diesen internen Dienst.

Datenresidenz lässt sich dabei steuern: Sie können Ihre App und die Datenbank in einer EU-Region (Nürnberg oder Helsinki) betreiben, sodass die Daten physisch in Europa liegen. Was das rechtlich bedeutet und was nicht, ordnet der Beitrag zu Cloud-Anbietern in Deutschland und DSGVO ein. Eine ausführliche Betrachtung speziell zum n8n-Betrieb finden Sie im Leitfaden zum n8n-Hosting in Deutschland.

Häufig gestellte Fragen

Welches Docker-Image sollte ich für n8n verwenden?

Verwenden Sie das offizielle Image docker.n8n.io/n8nio/n8n. Es wird vom n8n-Team gepflegt und deckt die gängigen Architekturen ab. Pinnen Sie im Produktivbetrieb einen konkreten Versions-Tag statt latest, damit ein Neustart nicht unbeabsichtigt eine neue Hauptversion zieht und Ihre Workflows unverändert weiterlaufen.

Warum brauche ich einen festen N8N_ENCRYPTION_KEY?

Weil n8n damit alle gespeicherten Zugangsdaten verschlüsselt. Ohne festen Wert erzeugt jeder frische Start einen neuen Schlüssel, und bestehende Credentials lassen sich nicht mehr entschlüsseln. Legen Sie den Schlüssel einmalig an, etwa mit openssl rand -base64 32, und übernehmen Sie exakt denselben Wert bei jedem Update und bei jedem Serverumzug.

SQLite oder PostgreSQL für n8n mit Docker?

SQLite eignet sich für lokale Tests, weil keine zweite Komponente nötig ist. Für den Produktivbetrieb sollten Sie PostgreSQL nutzen: Es verträgt parallele Schreibzugriffe, skaliert mit der Datenmenge und ist Voraussetzung für den Queue-Mode. Aktiviert wird es über DB_TYPE=postgresdb samt den zugehörigen Verbindungsvariablen in Ihrer Compose-Datei.

Wann lohnt sich der Queue-Mode mit Redis?

Sobald ein einzelner n8n-Prozess mit der Zahl paralleler Ausführungen nicht mehr hinterherkommt. Im Queue-Mode legt der Main-Prozess Aufgaben in eine Redis-Warteschlange, aus der mehrere Worker parallel arbeiten. Für gelegentliche Workflows ist das überdimensioniert. Bei vielen gleichzeitigen Läufen oder schweren Nodes verhindert es Staus und macht den Betrieb horizontal skalierbar.

Wie setze ich die WEBHOOK_URL richtig?

Setzen Sie WEBHOOK_URL auf Ihre echte, öffentlich erreichbare HTTPS-Adresse, mit abschließendem Schrägstrich. Andernfalls erzeugt n8n Webhook-Adressen auf Basis von localhost, und externe Dienste können Ihre Workflows nicht auslösen. Hinter einem Reverse Proxy setzen Sie zusätzlich N8N_PROTOCOL=https und N8N_HOST auf dieselbe Domain, damit alle erzeugten Links stimmen.

Verliere ich meine Workflows bei einem Container-Neustart?

Nein, sofern Ihre Daten außerhalb des Containers liegen. Bei SQLite muss das Verzeichnis /home/node/.n8n in einem persistenten Volume liegen. Im Produktivbetrieb speichert PostgreSQL Workflows und Ausführungen ohnehin außerhalb des n8n-Containers. Entscheidend ist außerdem der feste Encryption-Key, damit Ihre gespeicherten Credentials nach dem Neustart weiterhin nutzbar bleiben.

Kann ich n8n mit Docker auf Out Plane betreiben?

Ja. Sie legen n8n als App an (ein einzeiliges Dockerfile, das das offizielle Image umschließt, genügt), hängen eine verwaltete PostgreSQL-Datenbank an und setzen den Encryption-Key als Umgebungsvariable. HTTPS wird automatisch bereitgestellt. Die App ist unter einer Adresse nach dem Muster n8n-5678-ihrteam.outplane.app erreichbar, auf die Sie WEBHOOK_URL verweisen.

Gibt es bei Out Plane eine managed Redis für den Queue-Mode?

Nein, verwaltet wird ausschließlich PostgreSQL. Für den Queue-Mode betreiben Sie Redis selbst: als eigene App mit einem persistenten Volume, erreichbar über das private Netzwerk. Ihre n8n-Worker verbinden sich dann per QUEUE_BULL_REDIS_HOST mit diesem internen Dienst. Den Betrieb dieses Redis-Containers verantworten Sie selbst, alles andere übernimmt die Plattform.

Fazit

Ein sauberes n8n Docker Setup steht und fällt mit drei Details: PostgreSQL statt SQLite für den Produktivbetrieb, ein fester N8N_ENCRYPTION_KEY für den Erhalt Ihrer Credentials und eine korrekt gesetzte WEBHOOK_URL. Skaliert wird bei Bedarf über den Queue-Mode mit einem Redis-Container und zusätzlichen Workern. Damit haben Sie eine reproduzierbare, wartbare Instanz, die Neustarts und Umzüge unbeschadet übersteht.

Wenn Sie den Serverbetrieb überspringen möchten, legen Sie n8n in wenigen Minuten in der Konsole unter console.outplane.com an: managed PostgreSQL, automatisches HTTPS und optional ein EU-Standort. Der permanente Hobby-Tarif und ein Startguthaben von 20 US-Dollar (ohne Kreditkarte) reichen für den ersten Test. Die Konditionen für den Produktivbetrieb finden Sie unter /pricing.