Die wichtigsten Umgebungsvariablen erklärt (N8N_HOST, WEBHOOK_URL, GENERIC_TIMEZONE ...)

Wer eine n8n-Instanz selbst hostet, konfiguriert zentrale Einstellungen wie Erreichbarkeit, Zeitzone, Datenbank und Sicherheit nicht über die Oberfläche, sondern über Umgebungsvariablen, die beim Start des Containers oder Prozesses gesetzt werden. Von den mehr als hundert dokumentierten Variablen sind für die meisten deutschen Self-Hosting-Setups nur eine Handvoll wirklich entscheidend, etwa N8N_HOST für den Hostnamen, WEBHOOK_URL für den öffentlichen Zugriff hinter einem Reverse Proxy oder GENERIC_TIMEZONE, damit zeitgesteuerte Workflows zur richtigen Uhrzeit auslösen. Dieser Artikel ordnet die praxisrelevantesten Variablen nach Themenbereich und zeigt jeweils ein Beispiel für den Einsatz. Stand: Juli 2026.

Grundkonfiguration: Erreichbarkeit, URL und Zeitzone

Diese Variablen legen fest, wie n8n intern und nach außen erreichbar ist und in welcher Zeitzone zeitgesteuerte Workflows laufen.

• N8N_HOST: Legt fest, unter welchem Hostnamen n8n intern erreichbar ist, Standardwert ist localhost, für einen Server mit eigener Domain zum Beispiel n8n.ihrefirma.de.
• N8N_PORT: Der Port, auf dem der n8n-Prozess lauscht, Standardwert 5678, relevant wenn mehrere Dienste auf demselben Server parallel laufen.
• N8N_PROTOCOL: Bestimmt, ob n8n intern über http oder https angesprochen wird, Standard ist http, hinter einem TLS-terminierenden Reverse Proxy bleibt es intern meist bei http.
• N8N_EDITOR_BASE_URL: Die öffentliche URL, unter der Nutzer den Editor erreichen, wird auch für E-Mail-Links und SAML-Weiterleitungen verwendet, Beispiel https://n8n.ihrefirma.de.
• WEBHOOK_URL: Wird manuell gesetzt, wenn n8n hinter einem Reverse Proxy läuft, damit eingehende Webhooks die richtige öffentliche Adresse verwenden, Beispiel https://n8n.ihrefirma.de/.
• GENERIC_TIMEZONE: Die Zeitzone der n8n-Instanz, Standardwert ist America/New_York, für deutsche Setups gehört hier praktisch immer Europe/Berlin hinein, sonst lösen Cron- und Schedule-Trigger zur falschen Uhrzeit aus.

Sicherheit und Datenschutz

Gerade für Unternehmen, denen deutsche Datenhoheit und Kontrolle über die eigenen Daten wichtig sind, lohnt sich ein genauer Blick auf die sicherheitsrelevanten Variablen.

• N8N_ENCRYPTION_KEY: Der Schlüssel, mit dem n8n Zugangsdaten in der Datenbank verschlüsselt, wird ohne Angabe zufällig generiert, sollte in produktiven Setups aber fest gesetzt und sicher aufbewahrt werden, da gespeicherte Zugangsdaten sonst nach einem Neuaufbau nicht mehr entschlüsselt werden können.
• N8N_SECURE_COOKIE: Sorgt dafür, dass Cookies nur über HTTPS übertragen werden, Standardwert ist true, sollte nur bei reinem HTTP-Testbetrieb ohne TLS auf false gesetzt werden.
• N8N_BLOCK_ENV_ACCESS_IN_NODE: Verhindert, dass Nutzer über Expressions oder den Code-Node auf Umgebungsvariablen des Servers zugreifen, Standardwert ist false, für Mehrbenutzer-Instanzen mit sensiblen Zugangsdaten empfiehlt sich true.
• N8N_DIAGNOSTICS_ENABLED: Steuert, ob n8n anonymisierte Telemetriedaten an den Hersteller sendet, Standardwert ist true, wer maximale Datenhoheit will, setzt hier false.

Datenbank und Betrieb

Für den produktiven Betrieb wechseln die meisten Setups von der mitgelieferten SQLite-Datenbank auf PostgreSQL, was über eigene Variablen konfiguriert wird.

• DB_TYPE: Legt die verwendete Datenbank fest, Standardwert ist sqlite, für produktive Umgebungen mit mehreren gleichzeitigen Nutzern ist postgresdb der gängige Wert.
• DB_POSTGRESDB_HOST: Der Hostname des PostgreSQL-Servers, Standardwert ist localhost, bei einer separaten Datenbank etwa der interne Hostname des Datenbank-Containers.
• DB_POSTGRESDB_DATABASE: Der Name der PostgreSQL-Datenbank, Standardwert ist n8n, kann bei mehreren Instanzen auf demselben Server angepasst werden.
• DB_POSTGRESDB_USER / DB_POSTGRESDB_PASSWORD: Zugangsdaten für die PostgreSQL-Verbindung, ohne Standardwert für das Passwort, sollten wie jedes Datenbankpasswort nicht im Klartext im Repository landen, sondern über ein Secret verwaltet werden.
• N8N_PROXY_HOPS: Gibt an, hinter wie vielen Reverse Proxies n8n läuft, Standardwert ist 0, bei einem einzelnen Nginx oder Traefik davor typischerweise 1, damit n8n die tatsächliche Client-IP korrekt ermittelt.

Die meisten Probleme beim n8n-Self-Hosting entstehen nicht durch fehlende Variablen, sondern durch falsch gesetzte URLs oder eine Zeitzone, die nicht zum Serverstandort passt. Wer die eigene n8n-Instanz einrichten, absichern oder auf Postgres umziehen lassen möchte, findet bei den n8n-Leistungen von NordFlux Unterstützung bei Aufbau und Konfiguration.

Häufige Fragen zu n8n-Umgebungsvariablen

Wo setze ich Umgebungsvariablen bei n8n?

Das hängt von der Installationsart ab. Bei Docker geschieht das über -e-Flags oder eine .env-Datei im docker-compose.yml, bei einer klassischen Installation als Systemumgebungsvariablen, die vor dem Start des n8n-Prozesses gesetzt werden.

Was passiert, wenn ich N8N_ENCRYPTION_KEY nicht setze?

n8n generiert dann beim ersten Start automatisch einen zufälligen Schlüssel. Geht dieser verloren, etwa bei einem Container-Neuaufbau ohne persistenten Speicher, lassen sich bereits gespeicherte Zugangsdaten nicht mehr entschlüsseln.

Muss ich WEBHOOK_URL immer setzen?

Nur wenn n8n hinter einem Reverse Proxy oder unter einer anderen öffentlichen Adresse läuft als intern konfiguriert. Bei direktem Zugriff über N8N_HOST und N8N_PORT ist die Variable meist nicht nötig.

Kann ich Umgebungsvariablen nachträglich ändern?

Ja, die meisten Variablen wirken erst nach einem Neustart des n8n-Prozesses. Laufende Workflows und bereits gespeicherte Daten bleiben davon unberührt, solange sich die Datenbank-Verbindung nicht ändert.

Weitere Details zu allen dokumentierten Variablen finden sich in der n8n-Dokumentation zu Umgebungsvariablen sowie speziell zur Datenbankkonfiguration.