n8n auf VPS selbst hosten mit Docker und HTTPS

Was Sie erstellen

n8n ist ein Tool zur Workflow-Automatisierung: ein visueller Editor, in dem ein Trigger, ein Webhook, ein Zeitplan oder eine Formulareinsendung eine Kette von Nodes auslöst, die APIs aufrufen, Daten umformen und in andere Systeme schreiben. n8n ist zum Standardwerkzeug für Workflows mit KI-Agenten geworden, weil es mit jedem Modellanbieter und jeder Datenbank kommuniziert, ohne dass Sie dafür einen eigenen Dienst schreiben müssen. Mit einem docker run erhalten Sie in zwei Minuten einen funktionierenden Editor. In dieser Anleitung geht es um die übrigen 90 Prozent: um einen dauerhaften Betrieb mit Postgres statt der standardmäßigen SQLite-Datei, um den Zugriff über HTTPS und, was fast alle falsch konfigurieren, darum, dass Webhooks eine URL ausgeben, die tatsächlich aus dem Internet erreichbar ist.

Der fertige Stack besteht aus zwei Containern in einem Docker-Netzwerk: n8n selbst und einer Postgres-Datenbank, die seine Workflows und Zugangsdaten speichert. Ein Reverse Proxy auf dem Host übernimmt die TLS-Terminierung und leitet den Datenverkehr an n8n auf localhost weiter. Dadurch ist nichts außer diesem Proxy direkt aus dem Internet erreichbar. Der Stack läuft neben den anderen Diensten aus der Self-Hosting-Kurzübersicht 2026.

Voraussetzungen und die ehrlichen Grenzen

Sie benötigen einen VPS mit mindestens 1 GB RAM. Planen Sie 2 GB ein, sobald Workflows tatsächlich arbeiten, weil Ausführungen und die Node.js-Laufzeit Speicher verbrauchen. Wenn der Out-of-Memory-Killer den Container während der Ausführung beendet, erfahren Sie das auf besonders unangenehme Weise. Eine vCPU reicht für den Anfang aus. Wenn auf diesem System zusätzlich ein anspruchsvollerer Dienst läuft, dimensionieren Sie es zuerst für diesen Dienst: Eine Fotobibliothek ist meist der Hauptverursacher, und der tatsächliche RAM-Bedarf von PhotoPrism und Immich liegt deutlich über dem, was n8n benötigt. Das Gleiche gilt für einen Mediaserver: Ein Jellyfin-Server zusammen mit einer durchsuchbaren Oberfläche dafür, etwa Halcyon, das die Bibliothek als Videothek der 90er-Jahre neu aufbaut, beansprucht den verfügbaren RAM und Spielraum für die Transkodierung lange bevor n8n dies bemerkt.

Sie benötigen eine Domain oder Subdomain, zum Beispiel n8n.example.com, mit einem A-Record, der auf die öffentliche IP-Adresse des VPS zeigt und bereits aufgelöst wird, bevor Sie ein Zertifikat anfordern. Die Ports 80 und 443 müssen für den Proxy geöffnet sein. Der eigene Port 5678 von n8n darf nicht aus dem Internet erreichbar sein. Sie benötigen Docker Engine und das Compose-Plugin. Wenn docker compose version mit docker: 'compose' is not a docker command fehlschlägt, ist die alte eigenständige Binärdatei installiert. Das Plugin ist sudo apt install docker-compose-plugin.

SQLite ist für einen Test geeignet, Postgres für alles, worauf Sie angewiesen sind

Die Standarddatenbank von n8n ist eine SQLite-Datei unter /home/node/.n8n/database.sqlite. Für einen kurzen Test ist das ausreichend. Binden Sie kein Volume ein, verlieren Sie die Daten beim ersten erneuten Erstellen des Containers. Auch das ist eine eigene Lernmöglichkeit. Der Grund für den Wechsel zu Postgres ist nicht die reine Geschwindigkeit. SQLite verwendet eine einzelne Schreibsperre. Eine Instanz, die mehrere Workflows gleichzeitig ausführt, oder der Queue-Modus, den Sie später wahrscheinlich benötigen, führt deshalb bei gleichzeitigen Zugriffen zu SQLITE_BUSY: database is locked. Diese Begrenzung gibt es bei Postgres nicht. Die Datenbank lässt sich mit pg_dump sauber sichern. Außerdem setzt die n8n-Dokumentation für einen Server, auf den Sie angewiesen sind, Postgres voraus. Ein späterer Wechsel erfordert eine manuelle Migration der Daten. Wenn dieser Server wichtig ist, sollten Sie daher von Anfang an Postgres verwenden.

DNS und die Firewall

Verweisen Sie den DNS-Eintrag auf den Server und öffnen Sie zuerst die Ports. Andernfalls schlägt der Zertifikatsschritt später 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 Port 5678 nicht. Die Compose-Datei bindet n8n an 127.0.0.1:5678. Dadurch kann nur der Reverse Proxy des Hosts darauf zugreifen. Ein ufw allow 5678 würde diese Isolation aufheben.

Die Compose-Datei

Erstellen Sie ein Arbeitsverzeichnis und eine docker-compose.yml. Dies ist der gesamte Stack: zwei Dienste, 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 ausdrücklich genannt werden. DB_POSTGRESDB_HOST=postgres ist der Dienstname, den Docker im gemeinsamen Netzwerk auflöst, nicht localhost. Innerhalb des n8n-Containers bezeichnet localhost n8n selbst. Die depends_on mit condition: service_healthy verhindert, dass n8n beim Start vor Postgres startet. Ohne diese Prüfung startet n8n, findet keine Datenbank und wird beendet. Das benannte Volume n8n_data unter /home/node/.n8n enthält den Verschlüsselungsschlüssel und bei SQLite auch die Datenbank. Dies ist das eine Verzeichnis, das Sie nicht verlieren dürfen. Fixieren Sie das Image auf eine exakte Version und verwenden Sie niemals latest. Die Gründe werden im folgenden Abschnitt zum Upgrade erläutert.

Die Secrets-Datei

Legen Sie niemals Passwörter in der Compose-Datei ab. Speichern Sie sie in einer .env-Datei daneben, die Compose automatisch einliest, und erzeugen Sie die Werte so, dass sie tatsächlich zufällig sind.

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 die wichtigste einzelne Zeichenfolge in dieser Konfiguration. Er ist der Schlüssel, mit dem alle gespeicherten Zugangsdaten verschlüsselt werden. Setzen Sie ihn explizit, statt ihn von n8n erzeugen zu lassen. Einen selbst erzeugten Wert können Sie dokumentieren und wiederherstellen. Sobald n8n die erste Zugangsdaten mit diesem Schlüssel verschlüsselt hat, macht eine Änderung alle Zugangsdaten unentschlüsselbar. Setzen Sie den Wert daher jetzt einmalig und ändern Sie diese Zeile danach nie wieder.

Umgebungsvariablen, die bestimmen, ob Webhooks funktionieren

Vier Variablen legen fest, wie n8n sich nach außen darstellt. Falsche Werte sind die häufigste Frage an den n8n-Support.

• N8N_HOST ist der öffentliche Hostname, n8n.example.com. Belassen Sie den Wert hinter einem Proxy auf dem Standardwert localhost, versucht der Editor, seine eigene API in Ihrem Browser von localhost zu laden. Das schlägt fehl.
• N8N_PROTOCOL=https teilt n8n mit, dass der Dienst über TLS bereitgestellt wird. Dadurch markiert n8n sein Session-Cookie mit Secure und erstellt https://-URLs.
• N8N_PORT=5678 ist der Port, auf dem n8n innerhalb des Containers Verbindungen annimmt. Es handelt sich nicht um den öffentlichen Port. Der Proxy verwendet Port 443.
• WEBHOOK_URL=https://n8n.example.com/ verursacht die häufigsten Probleme. n8n erzeugt die Webhook-Adressen, die Sie in Stripe, GitHub oder bei einem anderen externen Aufrufer hinterlegen, aus diesen Werten. Ist die Variable nicht gesetzt oder falsch, verwendet n8n ersatzweise N8N_HOST:N8N_PORT und gibt Ihnen https://n8n.example.com:5678/webhook/... oder, noch schlimmer, http://localhost:5678/webhook/... aus. Die Adresse wird ohne Fehlermeldung angezeigt, wirkt plausibel, ist aber aus dem Internet nicht erreichbar. Die Requests des Aufrufers kommen dadurch unbemerkt nie an. Setzen Sie die Variable auf die exakte öffentliche Basis-URL mit abschließendem Schrägstrich. Prü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 sehen die Ratenbegrenzung und alle Funktionen, die die Client-IP auswerten, die echte Adresse und nicht die des Proxys. Eine Variable, die Sie hier bewusst nicht setzen, ist N8N_RUNNERS_ENABLED. Task Runner führen n8n-Code-Node-Logik in einem vom Hauptprozess isolierten separaten Prozess aus. In der gesamten 1.x-Reihe waren sie optional aktiviert. Die Variable hatte den Standardwert false und musste auf true gesetzt werden. n8n 2.0 aktiviert Task Runner standardmäßig. Daher kennzeichnet diese Anleitung die Variable in der 2.x-Reihe als veraltet, und laut n8n-Dokumentation müssen Sie sie nicht mehr setzen.

Erster Start

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

Ein erfolgreicher erster Start endet mit einer Zeile Editor is now accessible via: und darüber einer Zeile n8n ready on ..., port 5678. docker compose ps sollte beide Container Up anzeigen, wobei postgres als (healthy) markiert ist. Wenn n8n in einer Restarting-Schleife festhängt, prüfen Sie die Logs. Fast immer liegt die Ursache bei der Datenbankverbindung oder den unten beschriebenen Berechtigungen für das Volume.

TLS mit einem Reverse Proxy

n8n verwendet selbst unverschlüsseltes HTTP auf Port 5678. Ein vorgeschalteter Dienst übernimmt die TLS-Terminierung. Dafür gibt es zwei saubere Optionen.

Wenn Sie bereits mehrere Container betreiben, setzen Sie n8n hinter einen Traefik-Reverse-Proxy, der TLS-Zertifikate automatisch ausstellt. Dazu genügen einige Labels. Traefik fordert das Zertifikat für Sie an und erneuert es automatisch.

Wenn dies die einzige Anwendung auf dem Server ist, ist ein nginx-Virtual-Host mit einem Let's-Encrypt-Zertifikat einfacher. Verwenden Sie die Certbot- und nginx-TLS-Konfiguration für Ubuntu 24.04, um das Zertifikat abzurufen. 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 erforderlich. n8n überträgt laufende Ausführungsaktualisierungen über einen WebSocket an den Editor. Ohne diese beiden Zeilen wird die Anmeldeseite geladen und hängt anschließend mit einem Hinweis auf die verlorene Verbindung. 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 ergänzt N8N_PROXY_HOPS=1: Er teilt n8n mit, dass die ursprüngliche Anfrage über HTTPS eingegangen ist, obwohl der Proxy n8n über unverschlüsseltes HTTP erreicht. Dadurch stuft n8n die Verbindung nicht als unsicher ein und lehnt sein eigenes Cookie nicht ab.

Ihr erster Workflow: Umsetzung

Öffnen Sie https://n8n.example.com/, erstellen Sie das Owner-Konto (im nächsten Abschnitt) und bauen Sie den kleinsten Workflow, der den Ablauf bestätigt: Webhook-Eingang, HTTP-Aufruf, Antwort.

1. Fügen Sie einen Webhook-Knoten hinzu. Setzen Sie die Methode auf POST und den Pfad beispielsweise auf hello. Der Knoten zeigt zwei URLs an: eine Test URL und eine Production URL. Das ist die Ursache für einen großen Teil der Meldungen, dass Webhooks nicht funktionieren. Die Test URL beantwortet eine Anfrage, und zwar nur, solange Sie auf Listen for test event geklickt haben. Danach läuft sie ab. Die Production URL wird registriert, wenn Sie den Workflow publish und beantwortet ab diesem Zeitpunkt Anfragen.
2. Fügen Sie dahinter einen HTTP Request-Knoten hinzu und richten Sie ihn auf eine beliebige öffentliche JSON-API. Ein GET-Aufruf an https://api.github.com/zen gibt eine einzeilige Zeichenfolge zurück. Das genügt.
3. Fügen Sie einen Respond to Webhook-Knoten hinzu. Setzen Sie im Webhook-Knoten die Option Respond auf „Using Respond to Webhook node“, damit der Aufrufer die Ausgabe des HTTP-Knotens zurückerhält.
4. Klicken Sie oben rechts auf Publish und rufen Sie den Workflow auf: curl -X POST https://n8n.example.com/webhook/hello. Sie sollten die Zen-Zeile zurückerhalten: POST hinein, API-Aufruf, Antwort hinaus. Das ist der grundlegende Aufbau der meisten realen Automatisierungen. In älteren Anleitungen wird hier noch empfohlen, einen Active-Schalter zu aktivieren. n8n 2.0 hat diesen Schalter durch Publish und Unpublish ersetzt.

Bei einer zeitgesteuerten Variante wird der Webhook-Knoten durch einen Schedule Trigger ersetzt. Stattdessen wird ein Modellendpunkt aufgerufen. Ein selbst gehostetes Modell aus Ollama auf demselben VPS ist eine übersichtliche Möglichkeit, einen nächtlichen Zusammenfassungs-Workflow zu erstellen.

Benutzerverwaltung statt einfacher Authentifizierung

Ältere n8n-Anleitungen empfehlen, N8N_BASIC_AUTH_ACTIVE=true zu setzen. Diese Variablen wurden in n8n 1.0 entfernt und haben jetzt keine Wirkung mehr. Die Authentifizierung erfolgt heute über das Owner-Konto: Beim ersten Aufruf des Editors müssen Sie in n8n ein Owner-Konto mit E-Mail-Adresse und Passwort anlegen. Diese Zugriffssperre ist obligatorisch. Einen anonymen Modus gibt es nicht. Legen Sie das Konto direkt nach dem ersten Start an, bevor Sie die URL weitergeben: Zwischen docker compose up und dem Absenden dieses ersten Formulars kann die Instanz von der Person übernommen werden, die sie zuerst erreicht. Eine zusätzliche Basic-Auth-Schicht im Reverse Proxy ist als weitere Sperre sinnvoll. Sie ist jedoch eine zweite Schutzmaßnahme und nicht die eigentliche Authentifizierung. Das Owner-Konto und alle weiteren Funktionen in dieser Anleitung laufen in der kostenlosen Community Edition. Wenn Sie später zusätzliche Benutzer mit granularen Rollen oder SSO benötigen, sollten Sie vor der Planung lesen, welche n8n-Funktionen eine kostenpflichtige Lizenz erfordern.

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

Zwei Dinge müssen gesichert werden. Sie lassen sich jedoch nicht gleichermaßen ersetzen.

Der N8N_ENCRYPTION_KEY. Alle Zugangsdaten, die Sie in n8n speichern, darunter API-Tokens, Datenbankpasswörter und OAuth-Secrets, werden mit diesem Schlüssel im Ruhezustand verschlüsselt. Die Workflows in Postgres sind ohne ihn unbrauchbar: Wenn Sie die Datenbank auf einem neuen System mit einem anderen Schlüssel wiederherstellen, kann n8n keine einzige Zugangsdaten entschlüsseln. Es gibt dann weder eine Wiederherstellungsmöglichkeit noch eine Möglichkeit zum Zurücksetzen. Ihre Datei .env enthält den Schlüssel. Kopieren Sie sie am Tag ihrer Erstellung an einen Ort außerhalb des Servers. Ein Eintrag in einem Passwort-Manager ist dafür ideal. Diese Sicherung ist entscheidend.

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

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

Führen Sie das regelmäßig aus und kopieren Sie den Dump vom System herunter. Um die Daten auf einem frischen VPS wiederherzustellen, starten Sie den Stack einmal, damit die Datenbank angelegt wird. Stoppen Sie n8n. Spielen Sie den Dump mit psql zurück. Tragen Sie denselben N8N_ENCRYPTION_KEY in .env ein und starten Sie n8n. Derselbe Schlüssel zusammen mit dem Dump ergibt eine funktionsfähige Instanz. Ein neuer Schlüssel führt zu Workflows, die keine einzige Zugangsdaten verwenden können.

Upgrades: Tag festlegen

Die Compose-Datei legt absichtlich n8nio/n8n:2.29.10 statt latest fest. n8n veröffentlicht fast jede Woche eine neue Minor-Version und ändert dazwischen gelegentlich das Datenbankschema oder das Verhalten von Nodes. latest bedeutet daher, dass ein unbeaufsichtigter Pull eine Version bereitstellen kann, die Ihre Datenbank beim Start sofort migriert. Legen Sie eine Version fest, lesen Sie vor der Aktualisierung die Release Notes, in denen n8n auf inkompatible Änderungen hinweist, und führen Sie das Upgrade bewusst 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

Bei Sprüngen auf eine neue Major-Version ist das besonders wichtig. In der Version-2.0-Reihe wurde beispielsweise N8N_BLOCK_ENV_ACCESS_IN_NODE standardmäßig in true geändert. Jeder Code-Node, der process.env gelesen hat, verliert dadurch stillschweigend den Zugriff, bis Sie den Wert wieder auf false setzen. Mit derselben Version wurden außerdem strenge Berechtigungen für die Einstellungsdatei erzwungen, Task Runner standardmäßig aktiviert und der Schalter zum Aktivieren von Workflows durch die Funktion Publish ersetzt. Lesen Sie die Seite zu inkompatiblen Änderungen in 2.0, bevor Sie eine Major-Versionsgrenze überschreiten. n8n führt erforderliche Datenbankmigrationen beim Start automatisch aus. Genau deshalb ist pg_dump vor dem Upgrade nicht optional. Da die Zugangsdaten mit einem Schlüssel in .env verschlüsselt gespeichert werden und die Daten in Postgres liegen, können die Container jederzeit ersetzt werden. Für ein Upgrade ersetzen Sie die Container. Für ein Rollback legen Sie den vorherigen Tag fest und stellen den Dump wieder her.

Fehlerbilder und die angezeigten Meldungen

The requested webhook "POST hello" is not registered. Eine 404-Antwort tritt auf, wenn Sie einen Webhook aufrufen, dessen Workflow nicht veröffentlicht ist, oder wenn Sie den Testpfad aufrufen, während kein Prozess lauscht. Testpfade (/webhook-test/...) antworten nur, solange Sie auf „Listen for test event“ geklickt haben. Produktionspfade (/webhook/...) antworten erst, wenn der Workflow veröffentlicht wurde. Das verwandte 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 aber GET gesendet.

Die Webhook-URL zeigt ein :5678 oder localhost. Der Node zeigt https://n8n.example.com:5678/webhook/... oder http://localhost:5678/... an. WEBHOOK_URL ist nicht gesetzt oder falsch. Deshalb hat n8n die Adresse aus N8N_HOST:N8N_PORT statt aus Ihrer öffentlichen Basis-URL erstellt. 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 seine eigene Backend-API nicht erreichen. Hinter einem Proxy sind fast immer ein falsches N8N_HOST oder WEBHOOK_URL, fehlende WebSocket-Upgrade-Header im Proxy oder ein nicht zu Ihrer Verbindungsart passendes N8N_PROTOCOL die Ursache. Prüfen Sie die vier öffentlich erreichbaren 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 gestartet wird. Das von n8n gesendete Passwort stimmt nicht mit dem Passwort überein, mit dem die Datenbank initialisiert wurde. Die typische Falle: Postgres liest POSTGRES_PASSWORD nur bei der Initialisierung eines leeren Datenverzeichnisses. Starten Sie den Stack einmal, ändern Sie danach POSTGRES_PASSWORD in .env, und das vorhandene postgres_data-Volume enthält weiterhin das alte Passwort. Setzen Sie das ursprüngliche Passwort wieder ein. Wenn Sie keine Daten behalten müssen, führen Sie docker compose down aus, löschen Sie das Postgres-Volume mit docker volume rm und starten Sie den Stack anschließend neu.

EACCES: permission denied, open '/home/node/.n8n/config' beim Start. n8n wird als Benutzer node (UID 1000) ausgeführt und kann nicht in sein Konfigurationsverzeichnis schreiben. Das tritt häufig auf, wenn ein Host-Verzeichnis per Bind-Mount eingebunden ist und (./n8n_data:/home/node/.n8n) root gehört. Verwenden Sie das oben gezeigte Named Volume. Wenn Sie stattdessen unbedingt einen Bind-Mount verwenden, 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.. Seit der Version-2.x-Reihe erzwingt n8n standardmäßig 0600 für diese Einstellungsdatei und korrigiert die Berechtigungen beim Start selbst. Diese Logzeile bedeutet, dass n8n den Modus bereits korrigiert hat. Das geschieht häufig nach einem Bind-Mount oder wenn eine Wiederherstellung die Datei mit zu weit gefassten Berechtigungen zurückkopiert hat. Es ist keine Aktion erforderlich. Setzen Sie N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false nur, wenn Ihr Dateisystem Berechtigungen tatsächlich nicht 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 bei einem früheren Lauf in sein Daten-Volume geschrieben hat. Ursache ist meist, dass n8n beim vorherigen Start einen zufälligen Schlüssel erzeugt hat, weil die Variable nicht gesetzt war, und Sie danach einen anderen Schlüssel festgelegt haben. Tragen Sie den ursprünglichen Schlüssel wieder in .env ein. Wenn Sie wirklich keine gespeicherten Zugangsdaten behalten müssen, löschen Sie die Datei config im n8n_data-Volume und lassen Sie n8n sie neu erzeugen. Dabei werden vorhandene Zugangsdaten unlesbar.

Eine Anmeldeinformation 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, n8n aber über unverschlüsseltes HTTP aufgerufen. Das geschieht meist, wenn Sie die IP-Adresse und den Port direkt statt den HTTPS-Proxy verwenden. Rufen Sie n8n über https://n8n.example.com/ auf. Nur wenn Sie HTTPS tatsächlich nicht verwenden können, sollten Sie N8N_SECURE_COOKIE=false setzen. Auf einem aus dem Internet erreichbaren System dürfen Sie diese Einstellung niemals verwenden.

Informationen dazu, wie Sie ein Sprachmodell in diese Workflows integrieren, finden Sie unter KI-Workflows mit Claude und n8n erstellen.

FAQ

Sollte ich SQLite oder Postgres für n8n verwenden?

SQLite (die Standardeinstellung) eignet sich für erste Tests mit n8n und für eine persönliche Instanz, die jeweils nur einen Workflow ausführt. Verwenden Sie für alles, worauf Sie angewiesen sind, Postgres: Die Sperre für den einzigen Schreibprozess von SQLite verursacht bei gleichzeitigen Zugriffen database is locked, und Postgres lässt sich mit pg_dump sauber sichern. Eine spätere Migration ist manuell. Wenn der Server wichtig ist, beginnen Sie daher mit Postgres.

Warum werden meine n8n-Webhooks nie ausgelöst?

Fast immer liegt es an WEBHOOK_URL. Wenn der Wert nicht gesetzt oder falsch ist, gibt n8n Webhook-Adressen aus, die aus N8N_HOST:N8N_PORT erstellt werden und häufig :5678 oder localhost enthalten. Diese Adressen sehen zwar gültig aus, sind aus dem Internet jedoch nicht erreichbar. Die Anfragen des Aufrufers treffen daher nie ein. Setzen Sie WEBHOOK_URL=https://n8n.example.com/ und prüfen Sie, ob der Node eine URL ohne Port anzeigt. Die zweite Ursache ist, dass Sie die Produktions-URL eines Workflows aufrufen, den Sie noch nicht veröffentlicht haben. Das führt zu The requested webhook ... is not registered.

Was muss ich in n8n sichern?

Zwei Dinge. Erstens N8N_ENCRYPTION_KEY aus Ihrer .env-Datei. Jede gespeicherte Zugangsdaten wird damit verschlüsselt. Wenn Sie den Wert verlieren, können die Zugangsdaten dauerhaft nicht mehr entschlüsselt werden. Kopieren Sie ihn am Tag seiner Erstellung vom Server weg. Zweitens benötigen Sie pg_dump der Postgres-Datenbank mit den Workflows, dem Verlauf und den Zugangsdaten. Eine Wiederherstellung benötigt beides: denselben Schlüssel und den Dump.

Wie betreibe ich n8n hinter HTTPS?

n8n stellt unverschlüsseltes HTTP auf Port 5678 bereit. Ein vorgeschalteter Reverse Proxy übernimmt die TLS-Terminierung. 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 außerdem sicher, dass der Proxy die WebSocket-Header Upgrade weiterleitet. Andernfalls hängt der Editor.

Wie aktualisiere ich n8n sicher?

Verwenden Sie ein bestimmtes Image-Tag statt latest. Erstellen Sie zuerst pg_dump, weil n8n beim Start automatisch Datenbankmigrationen ausführt. Lesen Sie die Release Notes auf inkompatible Änderungen. Aktualisieren Sie anschließend das Tag und führen Sie docker compose pull n8n && docker compose up -d n8n aus. Der Container ist austauschbar. Für ein Rollback setzen Sie das vorherige Tag und stellen den Dump vor der Aktualisierung wieder her.