So hostest du n8n selbst auf einem VPS

Was die Lizenz erlaubt

Selbst gehostetes n8n wird unter der Sustainable Use License veröffentlicht, einer Fair-Code-Lizenz, die n8n 2022 verfasst hat. Sie erlaubt dir, die Software kostenlos zu nutzen, zu verändern und weiterzugeben, mit drei Einschränkungen: Du darfst sie nur für deine eigenen internen Geschäftszwecke oder für nicht-kommerzielle und private Zwecke nutzen; du darfst sie anderen nur kostenlos und für nicht-kommerzielle Zwecke weitergeben; und du darfst die Lizenz- und Urheberrechtshinweise von n8n nicht entfernen.

Der Satz, der die meisten Fälle klärt, ist der erste in der Lizenz-FAQ von n8n: Wenn Workflows nur von dir oder von Personen in deiner Organisation erstellt oder geändert werden, kannst du die Community-Lizenz kostenlos nutzen.

Erlaubt unter der Community-Lizenz

• Dein eigenes Unternehmen damit betreiben, dazu private Projekte, Lernen oder Forschung.
• Automatisierungen für Kunden auf deiner Instanz bauen, solange die Kunden sie nicht erstellen oder bearbeiten können.
• Kunden das Bauen, Einrichten und Warten von Workflows in Rechnung stellen, ebenso Schulungen und Beratung.
• n8n im Hintergrund deines eigenen Produkts nutzen, wo Nutzer Automatisierungen auslösen, die du gebaut hast, und sogar ihre eigenen Konten verbinden.
• Mehrere Instanzen betreiben.

Ohne kommerzielle Vereinbarung nicht erlaubt

• n8n als Dienst hosten, in dem deine Kunden Workflows bauen.
• Externe Nutzer über dein Produkt eigene Workflows bauen oder konfigurieren lassen, egal ob über deine eigene Oberfläche, die API, MCP oder einen KI-Agenten, der für sie handelt.
• Den Code forken, um dein eigenes Automatisierungsprodukt zu starten, oder n8n als White Label anbieten, indem du das Branding entfernst.
• Enterprise-Funktionen, die einen Lizenzschlüssel verlangen, ohne Enterprise-Lizenz nutzen.

Wenn dein Vorhaben zwischen den beiden Listen liegt, bittet n8n dich, an license@n8n.io zu schreiben, bevor du es baust.

Wie groß der Server sein muss

n8n braucht wenig CPU. Die Seite zu den Voraussetzungen sagt, dass der Speicherbedarf meist wichtiger ist als die CPU und dass eine n8n-Cloud-Instanz im Leerlauf etwa 100 MB belegt. Den Speicherbedarf treibt die Arbeit selbst nach oben: große JSON-Payloads, Binärdateien wie PDFs und Bilder, viele Nodes in einem Workflow, der Code-Node und manuelle Testläufe, die eine zusätzliche Kopie der Daten für den Editor vorhalten.

Rechne Postgres, den Reverse Proxy und das Betriebssystem zum Wert für n8n dazu. Planen solltest du mit der Spitze während deines schwersten Workflows, nicht mit dem Leerlaufwert: Führ diesen Workflow einmal auf dem neuen Server aus und beobachte docker stats, während er läuft. Wenn du die Sandbox des n8n Assistant aus der offiziellen Compose-Datei betreiben willst, betrachte 4 GB und 2 vCPUs als Untergrenze.

Docker Compose mit Postgres

Ab Werk speichert n8n alles in SQLite. Der Docker-Compose-Leitfaden sagt, dass SQLite zum Ausprobieren reicht, eine Produktivinstanz mit mehr als einer Handvoll Nutzern oder mit Workflows, die rund um die Uhr laufen, aber Postgres verwenden sollte. Der Queue-Modus unterstützt SQLite überhaupt nicht, wer also gleich mit Postgres startet, spart sich später eine Migration.

Installiere Docker Engine mit dem Compose-Plugin, leg einen Ordner wie ~/n8n an und leg zwei Dateien hinein. Zuerst die Datei .env. Setze N8N_VERSION fest auf eine echte Versionsnummer von der GitHub-Releases-Seite von n8n und erzeuge den Verschlüsselungsschlüssel selbst, damit er auch an einem anderen Ort als auf dem Server notiert ist:

# .env (keep it out of version control)
N8N_VERSION=2.xx.x
N8N_HOST=n8n.example.com
N8N_ENCRYPTION_KEY=change-me-long-random-string
POSTGRES_USER=n8n
POSTGRES_PASSWORD=change-me-password
POSTGRES_DB=n8n
GENERIC_TIMEZONE=Europe/Amsterdam

Dann compose.yaml:

services:
  postgres:
    image: postgres:18
    restart: always
    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
      timeout: 5s
      retries: 10

  n8n:
    image: n8nio/n8n:${N8N_VERSION}
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      N8N_HOST: ${N8N_HOST}
      N8N_PORT: 5678
      N8N_PROTOCOL: https
      NODE_ENV: production
      N8N_WEBHOOK_URL: https://${N8N_HOST}/
      N8N_PROXY_HOPS: 1
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}
      TZ: ${GENERIC_TIMEZONE}
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  db-storage:
  n8n_data:

• Behalte die Zeile PGDATA. Postgres 18 hat seinen Standard-Speicherort für Daten geändert, und ohne diese Zeile wird die Datenbank außerhalb des Volumes geschrieben und startet nach einem Neuerstellen leer.
• Port 5678 ist an 127.0.0.1 gebunden, sodass nur der Reverse Proxy auf demselben Server n8n erreichen kann. Nur 80 und 443 müssen zum Internet hin offen sein.
• Das Volume n8n_data unter /home/node/.n8n ist auch mit Postgres wichtig: Es enthält die Datei mit dem Verschlüsselungsschlüssel, Logs und Assets der Versionsverwaltung (Source Control).

Starte es mit docker compose up -d. n8n legt beim ersten Start seine Tabellen in Postgres an. Daten aus einer früheren SQLite-Instanz wandern nicht von selbst mit; exportiere Workflows und Zugangsdaten mit den CLI-Befehlen aus dem Backup-Abschnitt und importiere sie.

HTTPS, Reverse Proxy und Webhook-URLs

n8n baut Webhook-URLs aus N8N_PROTOCOL, N8N_HOST und N8N_PORT. Hinter einem Proxy ergibt das die falsche Adresse, weil n8n auf 5678 lauscht, während die öffentliche URL auf 443 liegt. Die Seite zum Reverse Proxy verlangt drei Dinge:

1. Setze N8N_WEBHOOK_URL auf die öffentliche Adresse, zum Beispiel https://n8n.example.com/. Sie hat WEBHOOK_URL ersetzt, das ab n8n 2.35.0 veraltet ist. Auf Versionen vor 2.30.0 verwendest du WEBHOOK_URL.
2. Setze N8N_PROXY_HOPS=1, wenn ein Proxy vor n8n sitzt.
3. Sorg dafür, dass der letzte Proxy X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto weitergibt.

Jeder Proxy funktioniert, wenn er diese drei Punkte erfüllt. Mit Caddy besteht die ganze Konfiguration aus vier Zeilen. Caddys reverse_proxy-Direktive setzt alle drei Forwarded-Header und reicht WebSocket-Verbindungen ohne zusätzliche Einstellungen durch, und Caddy holt sich das Zertifikat für die Domain selbst, sobald das DNS auf den Server zeigt:

# /etc/caddy/Caddyfile
n8n.example.com {
    reverse_proxy 127.0.0.1:5678
}

Wenn Webhooks im Editor localhost:5678 anzeigen oder externe Dienste die URL ablehnen, fehlt N8N_WEBHOOK_URL oder der Container wurde nach dem Setzen nicht neu erstellt. Führ nach jeder Änderung an der Umgebung erneut docker compose up -d aus.

Queue-Modus: wann du Redis und Worker brauchst

Im Standardmodus stellt ein einziger n8n-Prozess den Editor bereit, empfängt Webhooks und führt jeden Workflow aus. Das reicht für die meisten Instanzen eines einzelnen Teams. Zwei Zeichen dafür, dass es nicht mehr reicht: Ausführungen stauen sich hinter lang laufenden, oder der Editor reagiert nicht mehr, während schwere Workflows laufen.

Probier zuerst die günstige Lösung. N8N_CONCURRENCY_PRODUCTION_LIMIT begrenzt, wie viele Produktiv-Ausführungen gleichzeitig laufen, und stellt den Rest in eine Warteschlange; standardmäßig ist es aus. Wenn ein Prozess trotzdem der Engpass bleibt, teilt der Queue-Modus die Arbeit auf: Der Hauptprozess empfängt Trigger und Webhooks, Redis hält die Warteschlange, und Worker-Prozesse führen die Ausführungen aus.

# 1. in the n8n service: name the environment block, add the queue settings
    environment: &n8n-env
      # ...everything from before, plus:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PORT: 6379
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started

# 2. two new services
  redis:
    image: redis:7
    restart: always

  n8n-worker:
    image: n8nio/n8n:${N8N_VERSION}
    restart: always
    command: worker --concurrency=10
    environment: *n8n-env
    depends_on:
      - postgres
      - redis

• Jeder Prozess braucht denselben N8N_ENCRYPTION_KEY, dieselben Datenbankeinstellungen und dieselbe Image-Version.
• Ein Worker führt standardmäßig 10 Jobs gleichzeitig aus. n8n empfiehlt 5 oder mehr pro Worker: Viele Worker mit niedriger Parallelität können den Verbindungspool der Datenbank erschöpfen.
• Queue-Modus mit SQLite wird nicht unterstützt, und Binärdaten können nicht im lokalen Dateisystem bleiben; n8n verweist dafür auf externen S3-Speicher.
• Bei viel Webhook-Verkehr füge Webhook-Prozessoren (n8n webhook) hinzu und setze N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true auf dem Hauptprozess. Mehrere Hauptprozesse zu betreiben erfordert eine Enterprise-Lizenz.

Backups, mit denen sich Zugangsdaten wiederherstellen lassen

Ein vollständiges Backup besteht laut der Seite zu Backup und Wiederherstellung von n8n aus zwei Teilen: dem Ordner .n8n, der den Verschlüsselungsschlüssel enthält, und der Postgres-Datenbank. Zugangsdaten in der Datenbank sind mit diesem Schlüssel verschlüsselt, daher lassen sie sich aus einem Datenbank-Dump ohne den Schlüssel nicht wiederherstellen.

# workflows and credentials as JSON, one file each
docker compose exec n8n n8n export:workflow --backup --output=/home/node/.n8n/backups/workflows/
docker compose exec n8n n8n export:credentials --backup --output=/home/node/.n8n/backups/credentials/

# the whole Postgres database
docker compose exec -T postgres pg_dumpall -U n8n > n8n-db-$(date +%F).sql

• Das Flag --backup schreibt jeden Workflow und jeden Satz Zugangsdaten als eigene JSON-Datei. Nutze getrennte Ordner für Workflows und Zugangsdaten; der Import von Zugangsdaten schlägt fehl, wenn Workflow-Dateien im selben Ordner liegen.
• CLI-Exporte lassen Nutzer, Ausführungsverlauf, Variablen und Instanzeinstellungen weg, einschließlich des Schlüssels. Sie übertragen Workflows zwischen Instanzen; eine Instanz bauen sie damit nicht neu auf.
• Kopiere den Dump, die Exporte und das Volume .n8n vom Server weg. Ein Backup auf derselben Festplatte übersteht den Verlust des Servers nicht.
• Importierte Workflows kommen deaktiviert an. Plane ein, sie nach einer Wiederherstellung wieder einzuschalten.

Updates ohne Überraschungen

Die Update-Seite von n8n empfiehlt, mindestens einmal im Monat zu aktualisieren, damit du nie viele Versionen auf einmal überspringst, und die Release Notes jeder Version zwischen deiner und der Zielversion zu lesen.

# 1. back up first (see above), then set the new N8N_VERSION in .env
docker compose pull
docker compose up -d
docker compose logs -f n8n

Mach zuerst das vollständige Backup. Jeder Prozess führt beim Start ausstehende Datenbankmigrationen aus, und den Image-Tag auf die alte Version zurückzusetzen macht sie nicht rückgängig. Zurückrollen bedeutet, mit dem neueren Image n8n db:revert Migration für Migration auszuführen oder das Backup wiederherzustellen. Im Queue-Modus aktualisierst du Hauptprozess, Worker und Webhook-Prozessoren gemeinsam auf denselben Tag.

Häufige Fehler und Lösungen

Die Lösungen für Speicherprobleme stammen von der n8n-Seite zu speicherbezogenen Fehlern. Das Heap-Limit anzuheben sieht so aus:

# n8n service environment: raise the Node.js heap limit (value in MB)
      NODE_OPTIONS: --max-old-space-size=2048

Das Ganze auf Evorxa betreiben

Alles oben funktioniert auf einem Evorxa-Server, mit Root- und SSH-Zugriff. Du kannst mit einem schlichten Ubuntu- oder Debian-Image starten, das meist in etwa einer Minute bereit ist, oder die n8n-App mit einem Klick wählen, deren Installation ein paar Minuten länger dauert. Tarife beginnen bei $2.99 im Monat und werden monatlich, für sechs Monate oder jährlich im Voraus bezahlt. Die Server laufen in einer Region, Eygelshoven in den Niederlanden.

Quellen

Die Fakten in dieser Anleitung stammen von diesen Seiten.

1. n8n: Sustainable Use License und Lizenz-FAQ
2. n8n: Installation mit Docker Compose (Abschnitt Postgres)
3. n8n: Webhook-URLs mit einem Reverse Proxy konfigurieren
4. n8n: Queue-Modus aktivieren
5. n8n: Backup und Wiederherstellung
6. n8n: Speicherbezogene Fehler