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.

Die Umgebungsvariablen, die festlegen, ob Webhooks funktionieren

Vier Variablen bestimmen, wie n8n sich gegenüber externen Systemen beschreibt. Falsche Werte sind die häufigste n8n-Supportfrage.

• N8N_HOST ist der öffentliche Hostname, n8n.example.com. Hinter einem Proxy müssen Sie den Standardwert localhost ändern. Andernfalls versucht der Editor, seine eigene API in Ihrem Browser unter 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 lauscht. Das ist nicht der öffentliche Port. Der Proxy verwendet Port 443.
• WEBHOOK_URL=https://n8n.example.com/ verursacht die meisten Probleme. n8n erstellt 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. Dadurch erhalten Sie https://n8n.example.com:5678/webhook/... oder, schlimmer noch, http://localhost:5678/webhook/.... Die Adresse wird ohne Fehlermeldung ausgegeben, sieht plausibel aus und ist aus dem Internet nicht erreichbar. Die Anfragen des Aufrufers kommen dann unbemerkt nie an. Setzen Sie die Variable auf die exakte öffentliche Basis-URL einschließlich abschließendem Schrägstrich. Prüfen Sie anschließend, dass 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 Rate-Limiting und alle Funktionen, die die Client-IP auslesen, die tatsächliche Adresse statt der Proxy-Adresse. Eine Variable, die Sie hier absichtlich nicht setzen, ist N8N_RUNNERS_ENABLED: Task Runner, in denen n8n Code-Node-Logik in einem separaten, isolierten Prozess ausführt, sind seit 1.69 standardmäßig aktiviert. Ab der 2.x-Version, auf die diese Anleitung festgelegt ist, sind sie zwingend erforderlich. Die frühere Option ist daher veraltet. Wenn Sie sie jetzt setzen, protokolliert n8n lediglich einen Hinweis, dass Sie sie entfernen sollen.

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.

Der erste Workflow in der Praxis

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

1. Fügen Sie einen Webhook-Knoten hinzu. Setzen Sie die Methode auf POST und den Pfad beispielsweise auf hello. Es werden zwei URLs angezeigt: eine Test URL und eine Production URL. Das ist die Ursache für einen großen Teil der Meldungen, dass ein Webhook nicht funktioniert. Die Test URL beantwortet genau einen Aufruf und nur, solange Sie auf Listen for test event geklickt haben. Danach läuft sie ab. Die Production URL antwortet, sobald der Workflow Active ist.
2. Fügen Sie danach einen HTTP Request-Knoten hinzu. 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 ist ausreichend.
3. Fügen Sie einen Respond to Webhook-Knoten hinzu. Setzen Sie die Option Respond des Webhook-Knotens auf "Using Respond to Webhook node", damit der Aufrufer die Ausgabe des HTTP-Knotens zurückerhält.
4. Aktivieren Sie den Workflow oben rechts (Active) und rufen Sie ihn auf: curl -X POST https://n8n.example.com/webhook/hello. Sie sollten die Zen-Zeile zurückerhalten. Der Ablauf besteht aus POST-Eingang, API-Aufruf und Antwort. Das ist die Grundstruktur der meisten realen Automatisierungen.

Bei einer zeitgesteuerten Variante ersetzen Sie den Webhook-Knoten durch einen Schedule Trigger und rufen stattdessen einen Modellendpunkt auf. Eine selbst gehostete Instanz aus Ollama auf demselben VPS ist eine übersichtliche Möglichkeit, einen nächtlichen Zusammenfassungsdienst 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 n8nio/n8n:2.29.10 absichtlich fest und nicht latest. n8n veröffentlicht in den meisten Wochen eine neue Minor-Version und ändert gelegentlich das Datenbankschema oder das Verhalten von Nodes. Mit latest kann ein unbeaufsichtigter Pull daher ein Build einspielen, das die Datenbank beim Start sofort migriert. Legen Sie eine Version fest und lesen Sie vor dem Aktualisieren die Release Notes. n8n weist dort auf inkompatible Änderungen hin. Aktualisieren Sie bewusst:

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-Linie wurde beispielsweise N8N_BLOCK_ENV_ACCESS_IN_NODE standardmäßig auf true umgestellt. Jeder Code-Node, der process.env gelesen hat, verliert dadurch stillschweigend den Zugriff, bis Sie den Wert wieder auf false setzen. In derselben Version wurde außerdem die Prüfung strikter Berechtigungen für die Einstellungsdatei eingeführt. Lesen Sie die Seite zu inkompatiblen Änderungen in 2.0, bevor Sie eine Major-Versionsgrenze überschreiten. n8n führt beim Start alle erforderlichen Datenbankmigrationen automatisch aus. Genau deshalb ist das 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, sind die Container entbehrlich: Für ein Upgrade ersetzen Sie sie. 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. Ein 404-Fehler tritt auf, wenn Sie einen Webhook aufrufen, dessen Workflow nicht Active ist, oder den Testpfad aufrufen, während niemand auf das Ereignis wartet. Testpfade (/webhook-test/...) antworten nur, solange Sie auf „Listen for test event“ geklickt haben. Produktionspfade (/webhook/...) antworten nur, wenn der Workflow aktiviert ist. Das benachbarte 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 verschwindet.

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, ein Proxy ohne die erforderlichen WebSocket-Upgrade-Header oder ein nicht zu Ihrer Verbindungsart passendes N8N_PROTOCOL die Ursache. Prüfen Sie die vier Variablen für den öffentlichen Zugriff sowie die Weiterleitung von Upgrade und Connection durch den Proxy.

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 wichtige Einschränkung: Postgres liest POSTGRES_PASSWORD nur bei der Initialisierung eines leeren Datenverzeichnisses. Starten Sie den Stack einmal. Ändern Sie anschließend POSTGRES_PASSWORD in .env. 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, können Sie alternativ docker compose down und docker volume rm für das Postgres-Volume ausführen und den Stack anschließend neu starten.

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 passiert häufig bei einem Bind-Mount eines Hostverzeichnisses (./n8n_data:/home/node/.n8n), das root gehört. Verwenden Sie das oben gezeigte benannte Volume. Wenn Sie unbedingt einen Bind-Mount verwenden, führen Sie zuvor 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 2.x-Reihe erzwingt n8n standardmäßig 0600 für diese Einstellungsdatei und korrigiert die Berechtigungen beim Start selbst. Diese Logzeile bedeutet, dass n8n die Dateirechte bereits korrigiert hat. Das passiert häufig nach einem Bind-Mount oder nachdem eine Sicherung die Datei wieder mit zu weit gefassten Berechtigungen eingespielt 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 Zeile 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. Meist hat n8n beim vorherigen Start einen zufälligen Schlüssel erzeugt, weil die Variable nicht gesetzt war. Danach wurde ein anderer Schlüssel gesetzt. Tragen Sie den ursprünglichen Schlüssel wieder in .env ein. Wenn Sie wirklich keine gespeicherten Zugangsdaten behalten müssen, löschen Sie alternativ die Datei config im n8n_data-Volume. n8n erzeugt sie dann neu. Bereits vorhandene Zugangsdaten sind danach nicht mehr lesbar.

Eine Anmeldewarnung 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 erreicht. Häufig geschieht das, 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. Verwenden Sie diese Einstellung niemals auf einem aus dem Internet erreichbaren Server.

Wenn Sie ein Sprachmodell in diese Workflows integrieren möchten, lesen Sie 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 einzelne Schreibvorgänge von SQLite führt bei gleichzeitigen Zugriffen zu database is locked, während sich Postgres mit pg_dump zuverlässig sichern lässt. 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 dieser Wert nicht gesetzt oder falsch ist, gibt n8n Webhook-Adressen aus, die aus N8N_HOST:N8N_PORT erstellt wurden. Diese enthalten häufig :5678 oder localhost. Sie sehen zwar gültig aus, sind aus dem Internet aber 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 einen Webhook aufrufen, dessen Workflow nicht auf Active gesetzt ist. 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. Damit werden alle gespeicherten Zugangsdaten verschlüsselt. Wenn dieser Wert verloren geht, können die Zugangsdaten dauerhaft nicht mehr entschlüsselt werden. Kopieren Sie ihn am Tag seiner Erstellung vom Server an einen sicheren Ort. Zweitens benötigen Sie einen pg_dump der Postgres-Datenbank für Workflows, Verlauf und Zugangsdaten. Für eine Wiederherstellung benötigen Sie 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 automatischer Zertifikatsverwaltung 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 bleibt der Editor hängen.

Wie aktualisiere ich n8n sicher?

Verwenden Sie ein bestimmtes Image-Tag statt latest. Erstellen Sie zuerst ein pg_dump, da n8n beim Start automatisch Migrationen ausführt. Lesen Sie die Release Notes auf inkompatible Änderungen, setzen Sie anschließend das neue 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 daher das vorherige Tag und stellen den Dump vor dem Upgrade wieder her.