SSD Nodes Learn
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-07-24

n8n auf VPS installieren Docker HTTPS

n8n mit Docker Compose und Postgres aufsetzen. Erfahren Sie alles über die WEBHOOK_URL Konfiguration sowie Fehler bei der encryption-key Handhabung.

Was Sie aufbauen

n8n ist ein Tool zur Workflow-Automatisierung: Ein visueller Editor, bei dem ein Trigger — etwa ein Webhook, ein Zeitplan oder ein Formular-Submit — eine Kette von Nodes auslöst. Diese Nodes rufen APIs auf, transformieren Daten und schreiben Informationen in andere Systeme. n8n ist zum Standard für KI-Agenten-Workflows geworden, da es mit jedem Modell-Anbieter und jeder Datenbank kommunizieren kann, ohne dass ein eigener Service programmiert werden muss. Ein docker run erhält in zwei Minuten einen funktionsfähigen Editor. Dieser Guide behandelt die restlichen neunzig Prozent: Die dauerhafte Speicherung mit Postgres statt der Standard-SQLite-Datei, die Erreichbarkeit über HTTPS und — der Teil, den fast jeder falsch macht — die Konfiguration von Webhooks, damit diese eine URL bereitstellen, die von außen erreichbar ist.

Der fertige Stack besteht aus zwei Containern in einem Docker-Netzwerk: n8n selbst und einer Postgres-Datenbank, die die Workflows und Credentials speichert. Ein Reverse Proxy auf dem Host terminiert TLS und leitet die Anfragen an n8n auf localhost weiter. Dadurch ist nichts außer dem Proxy direkt über das Internet erreichbar. n8n steht auf der 2026 Self-Hosting Shortlist neben anderen Diensten.

Voraussetzungen und technische Grenzen

Sie benötigen einen VPS mit mindestens 1 GB RAM. Planen Sie 2 GB ein, sobald die Workflows intensive Aufgaben ausführen. Die Ausführungen und die Node.js-Laufzeit verbrauchen viel Arbeitsspeicher. Ein Abbruch durch den Out-of-Memory-Killer während des Betriebs ist ein schwieriger Lernprozess. Eine einzelne vCPU ist für den Start ausreichend.

Sie benötigen eine Domain oder Subdomain — zum Beispiel n8n.example.com — mit einem A-Record, der auf die öffentliche IP des VPS zeigt. Die Auflösung muss vor der Zertifikatsanforderung funktionieren. Die Ports 80 und 443 müssen für den Proxy geöffnet sein; der n8n-eigene Port 5678 darf nicht direkt aus dem Internet erreichbar sein. Sie benötigen Docker Engine und das Compose-Plugin. Wenn docker compose version den Fehler docker: 'compose' is not a docker command ausgibt, verwenden Sie die alte Standalone-Binary; das Plugin ist sudo apt install docker-compose-plugin.

SQLite eignet sich für Tests, Postgres für produktive Umgebungen

Die Standarddatenbank von n8n ist eine SQLite-Datei unter /home/node/.n8n/database.sqlite. Für einfache Tests ist dies ausreichend. Wenn Sie kein Volume mounten, gehen die Daten beim ersten Neuerstellen des Containers verloren. Der Wechsel zu Postgres erfolgt nicht wegen der Geschwindigkeit. SQLite verwendet einen Single-Writer-Lock. Wenn eine Instanz mehrere Workflows gleichzeitig ausführt oder der Queue-Modus genutzt wird, führt dies bei hoher Parallelität zu SQLITE_BUSY: database is locked. Postgres hat diese Einschränkung nicht. Es ermöglicht saubere Backups mit pg_dump. Die n8n-Dokumentation setzt Postgres für produktive Server voraus. Ein späterer Wechsel erfordert eine manuelle Datenmigration. Verwenden Sie daher von Beginn an Postgres, wenn die Daten wichtig sind.

DNS und die Firewall

Verweisen Sie zuerst auf den Record und öffnen Sie die Ports. Andernfalls schlägt der spätere Zertifikats-Schritt fehl, wenn der Name nicht aufgelöst werden kann.

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

Öffnen Sie den Port 5678 nicht. Die Compose-Datei bindet n8n an 127.0.0.1:5678, sodass nur der Reverse Proxy des Hosts darauf zugreifen kann. Ein ufw allow 5678 würde diese Isolation aufheben.

Die Compose-Datei

Erstellen Sie ein Arbeitsverzeichnis und eine docker-compose.yml. Dies umfasst den gesamten Stack — zwei Services, ein privates Netzwerk und zwei benannte 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:

Einige Entscheidungen sollten explizit erwähnt werden. DB_POSTGRESDB_HOST=postgres ist der Service-Name, den Docker im gemeinsamen Netzwerk auflöst — nicht localhost, was innerhalb des n8n-Containers n8n selbst bedeutet. Die depends_on mit condition: service_healthy verhindert, dass n8n beim Systemstart vor Postgres startet; ohne diese Konfiguration startet n8n, findet keine Datenbank und beendet den Prozess. Das benannte Volume n8n_data unter /home/node/.n8n speichert den Verschlüsselungsschlüssel und bei SQLite die Datenbank — das eine Verzeichnis, das nicht verloren gehen darf. Fixieren Sie das Image auf eine exakte Version und nutzen Sie niemals latest; die Gründe hierfür finden Sie im Abschnitt zur Aktualisierung unten.

Die Secrets-Datei

Speichern Sie Passwörter niemals in der Compose-Datei. Erstellen Sie stattdessen eine .env-Datei im selben Verzeichnis, die von Compose automatisch eingelesen wird. Generieren Sie diese Passwörter mit einem Zufallsgenerator.

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

Der N8N_ENCRYPTION_KEY ist der wichtigste Wert in diesem Kontext — er ist der Schlüssel, mit dem alle gespeicherten Anmeldedaten verschlüsselt werden. Legen Sie diesen Wert explizit fest, anstatt die automatische Generierung durch n8n zu nutzen. Ein selbst gewählter Wert kann dokumentiert und bei Bedarf wiederhergestellt werden. Sobald n8n die ersten Anmeldedaten mit diesem Schlüssel verschlüsselt hat, führt eine Änderung des Schlüssels dazu, dass alle Anmeldedaten nicht mehr entschlüsselt werden können. Setzen Sie den Wert daher einmalig fest und ändern Sie diese Zeile nie wieder.

Die Umgebungsvariablen für die Webhook-Funktionalität

Vier Variablen steuern, wie n8n sich gegenüber externen Systemen darstellt. Falsche Einstellungen dieser Variablen sind die häufigste Ursache für Support-Anfragen bei n8n.

  • N8N_HOST ist der öffentliche Hostname, n8n.example.com. Wenn dieser hinter einem Proxy auf dem Standardwert localhost bleibt, versucht der Editor, seine eigene API von localhost in Ihrem Browser zu laden, was fehlschlägt.
  • N8N_PROTOCOL=https teilt n8n mit, dass der Dienst über TLS bereitgestellt wird. Dadurch wird das Session-Cookie Secure markiert und https:// URLs werden generiert.
  • N8N_PORT=5678 ist der Port, auf dem n8n innerhalb des Containers lauscht. Dies ist nicht der öffentliche Port; der Proxy nutzt Port 443.
  • WEBHOOK_URL=https://n8n.example.com/ ist die kritische Variable. n8n generiert die Webhook-Adressen für Stripe, GitHub oder andere externe Aufrufer aus diesen Werten. Wenn diese Variable nicht gesetzt oder falsch ist, nutzt n8n als Fallback N8N_HOST:N8N_PORT und gibt Ihnen https://n8n.example.com:5678/webhook/... oder, schlimmer noch, http://localhost:5678/webhook/... aus. Diese Adressen werden ohne Fehlermeldung ausgegeben, sehen plausibel aus, sind aber aus dem Internet nicht erreichbar. Anfragen der Aufrufer kommen daher lautlos nicht an. Setzen Sie diese Variable auf die exakte öffentliche Basis-URL inklusive abschließendem Schrägstrich. Überprüfen Sie anschließend, ob der Webhook-Node eine URL ohne Port anzeigt.

N8N_PROXY_HOPS=1 weist den Express-Server von n8n an, einem vorgeschalteten Proxy zu vertrauen. Dadurch erkennen Rate-Limiting und Funktionen, die die Client-IP auslesen, die echte Adresse statt der Adresse des Proxys. Eine Variable, die hier bewusst nicht gesetzt werden sollte, ist N8N_RUNNERS_ENABLED: Task-Runner — n8n führt die Logik von Code-Nodes in einem separaten Sandboxed-Prozess aus — sind seit Version 1.69 Standard und ab der Version 2.x (die in dieser Anleitung verwendet wird) obligatorisch. Die alte Opt-in-Methode ist veraltet. Wenn Sie diese Variable dennoch setzen, schreibt n8n lediglich einen Hinweis, dass sie entfernt werden soll.

Erster Start

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

Ein erfolgreicher erster Boot endet mit einer Editor is now accessible via: Zeile, wobei eine n8n ready on ..., port 5678 Zeile darüber steht. docker compose ps sollte beide Container Up anzeigen, wobei postgres als (healthy) markiert ist. Falls n8n in einer Restarting Schleife feststeckt, lesen Sie die Logs — die Ursache ist fast immer die Datenbankverbindung oder die unten beschriebenen Volume-Berechtigungen.

TLS mit einem Reverse Proxy

n8n kommuniziert intern über HTTP auf Port 5678; ein vorgeschalteter Dienst terminiert HTTPS. Es gibt zwei einfache Möglichkeiten.

Wenn Sie bereits mehrere Container betreiben, schalten Sie n8n hinter einen Traefik Reverse Proxy mit automatischer TLS-Zertifikatserstellung, indem Sie einige Labels hinzufügen. Traefik fordert das Zertifikat an und erneuert es für Sie.

Wenn dies die einzige Anwendung auf dem Server ist, ist ein nginx Virtual Host mit einem Let's Encrypt Zertifikat einfacher. Nutzen Sie das Certbot und nginx TLS Setup für Ubuntu 24.04, um das Zertifikat zu erhalten, und verwenden Sie anschließend diesen Server Block:

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;
    }
}

Die Header Upgrade und Connection "upgrade" sind obligatorisch. n8n überträgt Live-Updates der Ausführung über einen WebSocket an den Editor. Ohne diese zwei Zeilen lädt die Login-Seite, bleibt dann aber mit einer Meldung über eine verlorene Verbindung hängen. proxy_read_timeout 3600 verhindert, dass lang laufende Ausführungen nach den standardmäßigen 60 Sekunden von nginx abgebrochen werden. Der Header X-Forwarded-Proto $scheme ist die Ergänzung zu N8N_PROXY_HOPS=1: Er teilt n8n mit, dass die ursprüngliche Anfrage über HTTPS erfolgte, obwohl der Proxy die Anfrage über HTTP weiterleitet. Dadurch verhindert n8n, dass die Verbindung als unsicher eingestuft und das eigene Cookie abgelehnt wird.

Ihr erster Workflow zur Verifizierung

Öffnen Sie https://n8n.example.com/, erstellen Sie das Owner-Konto (siehe nächsten Abschnitt) und erstellen Sie den kleinstmöglichen Workflow zur Überprüfung des Pfades: ein eingehender Webhook, ein HTTP-Aufruf und eine Antwort.

  1. Fügen Sie einen Webhook-Node hinzu. Stellen Sie die Methode auf POST und einen Pfad wie hello ein. Es werden zwei URLs angezeigt: eine Test URL und eine Production URL. Letztere ist die Ursache für die Hälfte aller Fehlermeldungen bezüglich nicht funktionierender Webhooks. Die Test URL reagiert nur auf einen einzigen Aufruf und nur, solange Sie auf Listen for test event geklickt haben; danach läuft sie ab. Die Production URL reagiert, sobald der Workflow auf Active steht.
  2. Fügen Sie danach einen HTTP Request-Node hinzu. Richten Sie diesen auf eine öffentliche JSON-API aus — ein GET-Request an https://api.github.com/zen liefert einen einzeiligen String zurück, was für diesen Zweck ausreicht.
  3. Fügen Sie einen Respond to Webhook-Node hinzu. Stellen Sie die Option Respond im Webhook-Node auf "Using Respond to Webhook node" ein, damit der Aufrufer die Ausgabe des HTTP-Nodes zurückerhält.
  4. Aktivieren Sie den Workflow (Active, oben rechts) und rufen Sie ihn auf: curl -X POST https://n8n.example.com/webhook/hello. Sie sollten die Testzeile zurückerhalten — POST-Eingang, API-Aufruf, Antwort-Ausgang. Dies entspricht dem Grundmuster der meisten realen Automatisierungen.

Eine zeitgesteuerte Variante ersetzt den Webhook-Node durch einen Schedule Trigger und ruft stattdessen einen Model-Endpoint auf. Ein selbst gehosteter Endpoint von Ollama, das auf demselben VPS läuft ist eine effiziente Methode, um einen nächtlichen Summarizer zu erstellen.

Benutzerverwaltung, nicht Basic Auth

Ältere n8n-Anleitungen empfehlen die Verwendung von N8N_BASIC_AUTH_ACTIVE=true. Diese Variablen wurden in n8n 1.0 entfernt und haben keine Funktion mehr. Die Authentifizierung erfolgt heute über das Owner-Konto: Beim ersten Laden des Editors fordert n8n die Erstellung eines Owner-Kontos per E-Mail und Passwort an. Dieser Schritt ist obligatorisch — ein anonymer Modus existiert nicht. Erstellen Sie dieses Konto sofort nach dem ersten Start, bevor Sie die URL an andere weitergeben: Zwischen docker compose up und dem Absenden des ersten Formulars kann die Instanz von jedem beansprucht werden, der sie zuerst erreicht. Eine zusätzliche Basic-Auth-Ebene über einen Reverse-Proxy ist als zusätzliche Sicherung sinnvoll, stellt jedoch nur einen zweiten Faktor und nicht die eigentliche Authentifizierung dar.

Backups: zuerst der Verschlüsselungsschlüssel, dann die Datenbank

Es müssen zwei Dinge gesichert werden, die nicht gleichermaßen ersetzbar sind.

Der N8N_ENCRYPTION_KEY. Jede in n8n gespeicherte Anmeldedaten — API-Token, Datenbank-Passwörter, OAuth-Secrets — wird mit diesem Schlüssel im Ruhezustand verschlüsselt. Die Workflows in Postgres sind ohne diesen Schlüssel unbrauchbar: Wenn Sie die Datenbank auf einem neuen System mit einem anderen Schlüssel wiederherstellen, kann n8n kein einziges Credential entschlüsseln. Es gibt keine Wiederherstellung und keinen Reset. Ihre .env-Datei enthält den Schlüssel; kopieren Sie diese am Tag der Erstellung an einen Ort außerhalb des Servers — ein Eintrag in einem Passwort-Manager ist ideal. Dies ist das Backup, das entscheidend ist.

Die Postgres-Datenbank für die Workflows, die Ausführungshistorie und die verschlüsselten Credentials selbst:

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

Führen Sie diesen Befehl nach einem Zeitplan aus und kopieren Sie den Dump vom Server. Um auf einem neuen VPS wiederherzustellen: Starten Sie den Stack einmal, damit die Datenbank existiert, stoppen Sie n8n, laden Sie den Dump mit psql wieder hoch, setzen Sie denselben N8N_ENCRYPTION_KEY in .env ein und starten Sie n8n. Der gleiche Schlüssel zusammen mit dem Dump ergibt eine funktionierende Instanz; ein neuer Schlüssel führt zu Workflows, die kein einziges Credential nutzen können.

Upgrades: Tag fixieren

Die Compose-Datei fixiert absichtlich n8nio/n8n:2.29.10 anstatt latest. n8n veröffentlicht fast jede Woche eine neue Minor-Version. Dabei ändern sich gelegentlich das Datenbank-Schema oder das Verhalten von Nodes. latest bedeutet, dass ein automatischer Pull eine Version bereitstellt, die beim Start sofort die Datenbank migriert. Fixieren Sie eine Version, lesen Sie die Release Notes vor einem Update – n8n listet dort Breaking Changes auf – und führen Sie Upgrades gezielt durch:

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

Sprünge zwischen Major-Versionen sind hierbei am kritischsten. Die 2.0-Serie hat beispielsweise standardmäßig N8N_BLOCK_ENV_ACCESS_IN_NODE auf true geändert. Jeder Code-Node, der process.env ausliest, verliert ohne manuelle Anpassung den Zugriff, bis Sie den Wert wieder auf false setzen. Dieselbe Version hat zudem strikte Berechtigungen für die Settings-Datei eingeführt. Lesen Sie die 2.0 breaking-changes Seite, bevor Sie eine Major-Version überspringen. n8n führt alle erforderlichen Datenbank-Migrationen beim Start automatisch aus. Aus diesem Grund ist das pg_dump vor dem Upgrade zwingend erforderlich. Da die Credentials verschlüsselt mit einem Key in .env gespeichert sind und die Daten in Postgres liegen, sind die Container austauschbar: Sie führen ein Upgrade durch, indem Sie die Container ersetzen. Ein Rollback erfolgt durch das Fixieren des vorherigen Tags und das Wiederherstellen des Dumps.

Fehlerursachen und die angezeigten Meldungen

The requested webhook "POST hello" is not registered. Ein 404-Fehler tritt auf, wenn ein Webhook aufgerufen wird, dessen Workflow nicht auf Active steht, oder wenn der Testpfad aufgerufen wird, während kein Listener aktiv ist. Testpfade (/webhook-test/...) antworten nur, wenn Sie auf "Listen for test event" geklickt haben; Produktionspfade (/webhook/...) antworten nur, wenn der Workflow-Schalter aktiviert ist. Die zugehörige Meldung This webhook is not registered for GET requests. Did you mean to make a POST request? bedeutet, dass die Methode falsch ist — der Node erwartet POST, Sie haben jedoch GET gesendet.

Die Webhook-URL zeigt :5678 oder localhost an. Der Node zeigt https://n8n.example.com:5678/webhook/... oder http://localhost:5678/... an. WEBHOOK_URL ist nicht gesetzt oder falsch, weshalb n8n die Adresse aus N8N_HOST:N8N_PORT statt Ihrer öffentlichen Basis erstellt hat. Setzen Sie WEBHOOK_URL=https://n8n.example.com/, erstellen Sie den Container mit docker compose up -d neu, und der Port wird nicht mehr angezeigt.

There was a problem loading init data im Browser. Der Editor wurde geladen, kann aber die eigene Backend-API nicht erreichen. Hinter einem Proxy liegt dies fast immer an einer falschen N8N_HOST oder WEBHOOK_URL, einem Proxy, dem die WebSocket Upgrade Header fehlen, oder an einer N8N_PROTOCOL, die nicht mit Ihrer Verbindung übereinstimmt. Überprüfen Sie die vier öffentlichen Variablen und stellen Sie sicher, dass der Proxy Upgrade und Connection weiterleitet.

password authentication failed for user "n8n" in den Logs, während der Container neu startet. Das von n8n gesendete Passwort stimmt nicht mit dem Passwort überein, mit dem die Datenbank initialisiert wurde. Die Falle: Postgres liest POSTGRES_PASSWORD nur beim Initialisieren eines leeren Datenverzeichnisses. Starten Sie den Stack einmal, ändern Sie dann POSTGRES_PASSWORD in .env; das bestehende postgres_data Volume enthält weiterhin das alte Passwort. Setzen Sie es auf den Originalwert zurück oder, falls Sie keine Daten behalten müssen, löschen Sie docker compose down und docker volume rm das Postgres-Volume und starten Sie es neu.

EACCES: permission denied, open '/home/node/.n8n/config' beim Start. n8n läuft als node User (UID 1000) und kann das Konfigurationsverzeichnis nicht beschreiben. Dies tritt auf, wenn ein Host-Ordner (./n8n_data:/home/node/.n8n) als Bind-Mount verwendet wird, der Root-Rechte besitzt. Verwenden Sie das oben gezeigte Named Volume oder, falls Sie einen Bind-Mount verwenden möchten, führen Sie zuerst sudo chown -R 1000:1000 ./n8n_data aus.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. Ab der Version 2.x erzwingt n8n standardmäßig 0600 für diese Einstellungsdatei und korrigiert dies beim Booten selbst — diese Log-Zeile bedeutet, dass die Berechtigung bereits korrigiert wurde, meist nach einem Bind-Mount oder nach einem Restore, bei dem die Datei mit unsicheren Berechtigungen kopiert wurde. Es ist keine Aktion erforderlich; setzen Sie N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false nur, wenn Ihr Dateisystem keine Berechtigungen unterstützt.

Mismatching encryption keys — die vollständige Meldung besagt, dass der Verschlüsselungsschlüssel in der Einstellungsdatei /home/node/.n8n/config nicht mit dem N8N_ENCRYPTION_KEY in Ihrer Umgebung übereinstimmt. Der Schlüssel in Ihrer Umgebung unterscheidet sich von dem Schlüssel, den n8n beim vorherigen Durchlauf in sein Daten-Volume geschrieben hat — meistens, weil n8n beim ersten Booten, als die Variable nicht gesetzt war, einen zufälligen Schlüssel generiert hat und Sie danach einen anderen gesetzt haben. Setzen Sie den Originalschlüssel in .env wieder ein oder, falls Sie keine gespeicherten Anmeldedaten behalten möchten, löschen Sie die config Datei innerhalb des n8n_data Volumes und lassen Sie n8n diese neu generieren — beachten Sie dabei, dass bestehende Anmeldedaten unlesbar werden.

Ein Login-Banner zu sicheren Cookies: Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. Sie haben N8N_PROTOCOL=https gesetzt, aber n8n über unverschlüsseltes HTTP erreicht — meistens durch den direkten Aufruf der IP und des Ports statt über den HTTPS-Proxy. Erreichen Sie n8n über https://n8n.example.com/. Nur wenn Sie HTTPS tatsächlich nicht nutzen können, sollten Sie N8N_SECURE_COOKIE=false setzen, und niemals auf einem im Internet erreichbaren System.

Um ein Sprachmodell in diese Workflows zu integrieren, lesen Sie building AI workflows with Claude and n8n.

FAQ

Sollte ich SQLite oder Postgres für n8n verwenden?

SQLite (Standardeinstellung) ist für Testzwecke und für eine persönliche Instanz, die jeweils nur einen Workflow ausführt, ausreichend. Wechseln Sie zu Postgres für alle produktiven Anwendungen: Der Single-Writer-Lock von SQLite verursacht database is locked bei gleichzeitigen Zugriffen. Postgres lässt sich mit pg_dump sauber sichern. Eine spätere Migration erfolgt manuell. Wenn die Daten wichtig sind, starten Sie direkt mit Postgres.

Warum werden meine n8n Webhooks nie ausgelöst?

Meistens liegt es an WEBHOOK_URL. Wenn die Variable nicht gesetzt oder falsch konfiguriert ist, generiert n8n Webhook-Adressen basierend auf N8N_HOST:N8N_PORT. Diese enthalten oft :5678 oder localhost. Die Adressen sehen gültig aus, sind aber aus dem Internet nicht erreichbar, weshalb die Anfragen des Aufrufers nie ankommen. Setzen Sie WEBHOOK_URL=https://n8n.example.com/ und prüfen Sie, ob der Node eine URL ohne Port anzeigt. Die zweite Ursache ist der Aufruf eines Webhooks, dessen Workflow nicht auf Active steht; dies führt zu The requested webhook ... is not registered..

Was muss ich in n8n sichern?

Zwei Dinge. Den N8N_ENCRYPTION_KEY aus Ihrer .env-Datei, da alle gespeicherten Credentials damit verschlüsselt sind. Ein Verlust macht diese dauerhaft unlesbar – kopieren Sie die Datei direkt nach der Erstellung vom Server. Zudem ist ein pg_dump der Postgres-Datenbank für Workflows, Historie und Credentials erforderlich. Eine Wiederherstellung benötigt beides: denselben Key und das Dump.

Wie schalte ich n8n hinter HTTPS?

n8n stellt HTTP auf Port 5678 bereit; ein Reverse Proxy davor terminiert TLS. Binden Sie n8n an 127.0.0.1:5678, damit nur der Proxy darauf zugreifen kann. Verwenden Sie anschließend Traefik mit automatischen Zertifikaten oder nginx mit einem Let's Encrypt Zertifikat. Setzen Sie N8N_PROTOCOL=https und WEBHOOK_URL=https://your-host/. Stellen Sie sicher, dass der Proxy die WebSocket Upgrade Header weiterleitet, da der Editor sonst einfriert.

Wie aktualisiere ich n8n sicher?

Verwenden Sie ein spezifisches Image-Tag anstatt latest. Erstellen Sie zuerst ein pg_dump, da n8n beim Start automatische Migrationen durchführt. Lesen Sie die Release Notes auf Breaking Changes. Erhöhen Sie dann das Tag und führen Sie docker compose pull n8n && docker compose up -d n8n aus. Der Container ist austauschbar. Ein Rollback erfolgt durch das Fixieren des vorherigen Tags und das Wiederherstellen des Dumps vor dem Upgrade.

#n8n#automation#docker#self-hosting#https