n8n installierst du am schnellsten mit Docker: ein Volume für die Daten anlegen, den Container n8nio/n8n mit Port 5678 starten und http://localhost:5678 im Browser öffnen. Für den Dauerbetrieb auf einem Server nimmst du Docker Compose mit Postgres, setzt einen eigenen N8N_ENCRYPTION_KEY und stellst einen Reverse Proxy mit TLS davor. Kubernetes lohnt sich, wenn du schon einen Cluster betreibst; dafür gibt es ein offizielles Helm-Chart von n8n. Den Weg über npm streicht der Hersteller: Ab n8n 3.0 wird n8n laut Doku nur noch über Docker verteilt.
Ich habe n8n lange in meinem eigenen Kubernetes-Cluster betrieben. Ich betreibe seit 2017 Kubernetes-Cluster, heute vor allem k3s auf Hetzner Cloud, bin Kubestronaut der CNCF und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben. Die Befehle und Ausgaben unten stammen aus einem Test vom 31.10.2026 auf einem Mac mit Apple Silicon und Docker Desktop 4.93.0, gekürzt.
Welcher Weg passt: Docker, Compose oder Kubernetes
n8n selbst hosten heißt laut Doku: Server und Container einrichten, Ressourcen verwalten, alles absichern und n8n konfigurieren. Fehler können zu Datenverlust, Sicherheitslücken und Ausfällen führen, deshalb empfiehlt n8n das Selbst-Hosten erfahrenen Nutzern. Die drei Wege unterscheiden sich vor allem darin, wie viel Betrieb du übernimmst:
Dazu kommt ein Installationsskript, curl -fsSL https://get.n8n.io | sh. Es legt einen Ordner mit compose.yml und .env an und startet n8n samt einer Sandbox für den n8n Assistant und einer Websuche. Für diesen Aufbau nennt die Doku mindestens 4 GB RAM und 2 vCPUs. Die Doku-Seite zur reinen Docker-Installation ist inzwischen als veraltet markiert und verweist auf Compose; für einen Test funktioniert sie trotzdem.
Ob sich der eigene Betrieb überhaupt lohnt, ist eine eigene Frage; den Vergleich mit Make und Claude findest du in n8n, Make oder Claude: was wofür?. Was Cloud und Selbst-Hosten kosten, steht in n8n Kosten: Cloud, Self-Hosted, Business.
n8n mit Docker installieren
Voraussetzung ist Docker, auf dem Mac und unter Windows als Docker Desktop. Dann reichen zwei Befehle:
docker volume create n8n_data
docker run -d --name n8n \
-p 5678:5678 \
-e GENERIC_TIMEZONE="Europe/Berlin" \
-e TZ="Europe/Berlin" \
-e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
-v n8n_data:/home/node/.n8n \
n8nio/n8n:2.45.7
GENERIC_TIMEZONE stellt die Zeitzone für zeitgesteuerte Workflows ein, TZ die des Systems im Container. Das Volume hängt am Ordner /home/node/.n8n, dort liegen Datenbank und Schlüssel.
Die Versionsnummer trägst du fest ein statt latest. n8n bringt laut Doku fast jede Woche eine neue Minor-Version, stable ist für die Produktion gedacht, beta ist die neueste und kann instabil sein. Am Testtag zeigten stable und latest auf Docker Hub auf denselben Digest wie 2.45.7, als Beta nannte die Doku 2.46.3.
Ob n8n läuft, prüfst du mit zwei Endpunkten:
$ curl -s http://localhost:5678/healthz
{"status":"ok"}
$ curl -s http://localhost:5678/healthz/readiness
{"status":"error"}
Im Test meldete /healthz schon 2 Sekunden nach dem Start „ok“, /healthz/readiness zur selben Zeit noch einen Fehler mit HTTP 503. n8n legte gerade die Datenbank an, im Log stand: „Migrations in progress, please do NOT stop the process.“ Auf einem frischen Volume war readiness nach 4 Sekunden „ok“, und http://localhost:5678 lieferte den Editor aus. Der erste Start inklusive Download des Images dauerte 81 Sekunden, lokal belegt das Image 1,07 GB. Warte auf readiness, bevor du den Container stoppst: Im Test wurde er einmal in dieser Phase gestoppt, beim nächsten Start meldete n8n „Last session crashed“.
Was im Volume liegt: Datenbank und Encryption Key
Beim ersten Start schreibt n8n ins Log: „No encryption key found - Auto-generating and saving to: /home/node/.n8n/config“. Im Test lagen in diesem Ordner die Datei config mit dem Feld encryptionKey (32 Zeichen) und die SQLite-Datenbank database.sqlite. Mit dem Schlüssel verschlüsselt n8n alle Zugangsdaten, die du in Workflows hinterlegst.
Danach wurde der Container gelöscht und mit demselben Volume neu angelegt. Der Schlüssel war derselbe, n8n erzeugte keinen neuen. Umgekehrt löscht docker volume rm n8n_data Workflows, Zugangsdaten und Schlüssel auf einmal. Ein vollständiges Backup besteht laut Doku aus diesem Ordner und, wenn du Postgres nutzt, zusätzlich aus der Datenbank.
n8n hosting mit Docker Compose und Postgres
Für einen Server im Dauerbetrieb empfiehlt die Doku Postgres statt SQLite, sobald mehr als eine Handvoll Nutzer oder Workflows rund um die Uhr laufen. Eine schlanke compose.yml ohne die Sandbox-Dienste, so im Test gelaufen und leicht gekürzt:
services:
postgres:
image: postgres:18
restart: unless-stopped
environment:
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: ${POSTGRES_DB}
PGDATA: /var/lib/postgresql/data
volumes:
- db-storage:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -h localhost -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
interval: 5s
retries: 10
n8n:
image: n8nio/n8n:${N8N_VERSION}
restart: unless-stopped
ports:
- "127.0.0.1:5678:5678"
environment:
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: postgres
DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
DB_POSTGRESDB_USER: ${POSTGRES_USER}
DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
GENERIC_TIMEZONE: Europe/Berlin
TZ: Europe/Berlin
volumes:
- n8n-data:/home/node/.n8n
depends_on:
postgres:
condition: service_healthy
volumes:
db-storage:
n8n-data:
Die Werte stehen in einer .env daneben, die nicht ins Git-Repository gehört. Passwort und Schlüssel erzeugst du mit openssl rand -hex 16 bzw. openssl rand -hex 32:
N8N_VERSION=2.45.7
POSTGRES_USER=n8n
POSTGRES_DB=n8n
POSTGRES_PASSWORD=<zufälliger Wert>
N8N_ENCRYPTION_KEY=<zufälliger Wert>
Die Zeile PGDATA bleibt drin: Postgres 18 speichert laut n8n-Doku sonst an einem anderen Ort, den das Volume nicht abdeckt, und die Datenbank startet leer. Port 5678 ist nur auf 127.0.0.1 freigegeben, von außen kommt man also nur über den Reverse Proxy auf demselben Server heran.
Im Test war n8n 4 Sekunden nach docker compose up -d bereit, mit Postgres 18.6. n8n hatte 167 Tabellen angelegt, und der Schlüssel in config stimmte mit dem aus der .env überein.
Dann der wichtigste Versuch: n8n mit einem anderen N8N_ENCRYPTION_KEY auf demselben Volume starten. Der Container hing in einer Neustart-Schleife, im Log stand:
Error: Mismatching encryption keys. The encryption key in the settings file
/home/node/.n8n/config does not match the N8N_ENCRYPTION_KEY env var.
n8n merkt sich den Schlüssel beim ersten Start und vergleicht ab dann. Fehlt der alte Schlüssel ganz, lassen sich die in Postgres gespeicherten Zugangsdaten laut Doku nicht mehr entschlüsseln. Leg den Schlüssel deshalb in einen Passwortmanager oder Secret-Store, nicht nur auf den Server.
n8n auf Kubernetes mit dem offiziellen Helm-Chart
Für n8n auf Kubernetes pflegt n8n ein offizielles Helm-Chart im Repository n8n-io/n8n-hosting, als OCI-Paket auf ghcr.io. Laut README erscheint jeden Mittwoch eine Chart-Version mit der aktuellen stabilen n8n-Version. Chart 1.x installiert n8n 2.x. Chart 2.0 erscheint bisher nur als Release Candidate, den Helm ohne --devel überspringt. Das Chart kennt zwei Modi:
- Queue-Modus (Standard): Main-Pod, Worker und optional Webhook-Prozessoren. Braucht ein externes Postgres und Redis, die das Chart nicht mitbringt.
- Standalone: ein Pod mit SQLite auf einem PersistentVolumeClaim, laut README für Entwicklung und kleine Installationen.
Im Test lief Standalone auf minikube v1.39.0 mit Kubernetes v1.37.0 und Helm v4.3.1:
kubectl create namespace n8n
kubectl create secret generic n8n-secrets -n n8n \
--from-literal=N8N_ENCRYPTION_KEY=$(openssl rand -hex 32) \
--from-literal=N8N_HOST=localhost \
--from-literal=N8N_PORT=5678 \
--from-literal=N8N_PROTOCOL=http
helm install n8n oci://ghcr.io/n8n-io/n8n-helm-chart/n8n \
--version 1.18.0 -n n8n -f standalone.yaml
# standalone.yaml
queueMode:
enabled: false
database:
type: sqlite
useExternal: false
redis:
enabled: false
persistence:
enabled: true
size: 5Gi
secretRefs:
existingSecret: "n8n-secrets"
Chart 1.18.0 brachte n8n 2.45.5 mit, zwei Patch-Versionen hinter dem Docker-Image vom selben Tag. Der Pod lief 12 Sekunden nach helm install (das Image lag schon im Node), readiness meldete über kubectl port-forward „ok“. Das Chart nutzt dieselben Endpunkte als Probes: /healthz für Liveness und Startup, /healthz/readiness für Readiness. Wie das zusammenspielt, steht in Liveness und Readiness Probes erklärt.
Eine Falle aus dem Test: Der erste Versuch nahm das Beispiel standalone.yaml vom Branch main, auf dem Chart 2.0 entsteht. Mit Chart 1.18.0 blieb der Pod in CreateContainerConfigError, das Event lautete secret "n8n-db-password" not found. Das Beispiel vom Branch release/n8n-2.x, oben abgedruckt, setzt zusätzlich useExternal: false und verlangt N8N_HOST, N8N_PORT und N8N_PROTOCOL im Secret. Nimm Beispiele also aus dem Branch deiner Chart-Version.
Für den echten Betrieb kommen Postgres, Redis, ein Ingress mit TLS und Secrets aus einem Secret-Store dazu; die README nennt dafür den External Secrets Operator. Die Grundlagen stehen in Kubernetes Ingress und Ingress Controller und Persistent Volumes und PVC in Kubernetes. Einen Cluster nur für n8n aufzubauen, ist viel Betrieb für eine Anwendung; wie ich meinen betreibe, steht in Kubernetes auf Hetzner: k3s in Produktion.
Sicherheit: Schlüssel, Basis-URL, TLS und Updates
Vier Punkte aus der Doku, bevor n8n aus dem Internet erreichbar ist:
- Encryption Key selbst setzen und sichern.
N8N_ENCRYPTION_KEY gehört vor den ersten Start, im Queue-Modus braucht ihn laut Doku jeder Worker.
- Basis-URL setzen. Hinter einem Reverse Proxy baut n8n die Webhook-URL sonst falsch aus Protokoll, Host und Port 5678 zusammen. Setz
N8N_WEBHOOK_URL=https://n8n.example.com/ und N8N_PROXY_HOPS=1; der Proxy reicht X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto weiter. WEBHOOK_URL ist seit n8n 2.35.0 veraltet. Die Adresse des Editors setzt N8N_EDITOR_BASE_URL.
- TLS über einen Reverse Proxy. Die Doku empfiehlt einen Proxy wie Traefik oder einen Load Balancer, der auch die Zertifikate erneuert; ihre Hetzner-Anleitung nutzt Caddy. Cookies schickt n8n standardmäßig nur über HTTPS (
N8N_SECURE_COOKIE=true). Schalte das nicht ab, sondern stell TLS davor. Wie du den Server selbst absicherst, steht in Eigenen Server absichern: Linux und Windows.
- Regelmäßig aktualisieren. Laut Doku mindestens einmal im Monat, vorher die Release Notes auf Breaking Changes prüfen und ein vollständiges Backup ziehen. Mit Compose: Version in der
.env anheben, dann docker compose pull, docker compose down und docker compose up -d.
Nach der Einrichtung baust du einen ersten Ablauf mit echten Eingaben und Fehlerfällen: n8n Workflow erstellen: Tutorial mit Beispiel.
Häufige Fragen
Kann ich n8n ohne Docker installieren?
Heute noch per npm, ab n8n 3.0 laut Doku nicht mehr: Dann wird n8n nur noch über Docker verteilt. Bestehende npm-Installationen laufen vorerst weiter, neue sollen Docker nutzen.
Brauche ich Postgres?
Zum Ausprobieren nicht, SQLite im Volume reicht. Für einen Server mit mehreren Nutzern oder Workflows rund um die Uhr empfiehlt die Doku Postgres, der Queue-Modus auf Kubernetes setzt es voraus.
Was passiert, wenn ich den Encryption Key verliere?
Hinterlegte Zugangsdaten lassen sich nicht mehr entschlüsseln. Mit einem anderen Schlüssel auf dem alten Volume startet n8n gar nicht, im Test mit „Mismatching encryption keys“.
Docker oder Kubernetes: was nehme ich?
Docker Compose für einen einzelnen Server. Kubernetes, wenn du schon einen Cluster betreibst oder Worker skalieren willst. Das Helm-Chart nimmt dir die Manifeste ab, nicht den Betrieb.
Wie du weitermachst
Läuft n8n, beginnt der eigentliche Teil: Workflows und Agenten. Wie ein KI-Agent in n8n aufgebaut ist und was ich aus meinem Betrieb mitgenommen habe, steht in n8n KI-Agent erstellen: was ich gelernt habe. Weitere Wege zum eigenen Agenten findest du auf der Seite KI-Agenten und in KI-Agent erstellen kostenlos: was geht?.
Für n8n im Cluster stehen alle Grundlagen auf der Seite Kubernetes. Und wenn du bei der Installation hängst: Bring die Fehlermeldung in die Community, dort schauen wir sie gemeinsam an.
