n8n selbst hosten: Anleitung für EU-Server

Was Self-Hosting von n8n bedeutet

n8n selbst zu hosten bedeutet, die Workflow-Automatisierungs-Engine n8n auf einem Server zu betreiben, den du kontrollierst, statt für n8n Cloud oder ein SaaS mit Abrechnung pro Task wie Zapier zu bezahlen. Du installierst n8n auf einem virtuellen Server (VPS), verbindest es mit deiner eigenen Datenbank und jede Workflow-Ausführung läuft auf Hardware, die dir gehört. Deine Kundendaten, API-Schlüssel und Webhook-Payloads verlassen deine Infrastruktur nie.

n8n ist ein knotenbasiertes Automatisierungstool: du verbindest Trigger (einen Webhook, einen Zeitplan, einen neuen CRM-Datensatz) mit Aktionen (eine E-Mail senden, in eine Datenbank schreiben, eine API aufrufen, ein KI-Modell ausführen), indem du Knoten auf einer visuellen Leinwand verdrahtest. Der Unterschied zu Zapier oder Make ist nicht die Leinwand. Es ist, wo die Engine läuft und wie du dafür bezahlst.

Diese Anleitung behandelt, warum Unternehmen n8n selbst hosten, die Lizenzrealität (sie ist nicht das, was die meisten annehmen), was der kostenlosen Community Edition fehlt, eine Docker-basierte Setup-Übersicht, wie du es richtig absicherst und aktuell hältst, wie du es mit dem Queue-Mode skalierst und den ehrlichen Kompromiss zwischen Eigenbetrieb und einer betreuten Lösung. Alle Angaben sind mit Stand 26. September 2026 gegen die offizielle Dokumentation geprüft und verlinkt.

Wenn du die Umsetzung auf deutschen Servern für dich erledigt haben möchtest oder grundsätzlich zwischen eigener Automatisierungs-Infrastruktur und SaaS abwägst, sieh dir unseren n8n-Automatisierungs-Service an.

Warum n8n überhaupt selbst hosten

Es gibt drei konkrete Gründe und sie verstärken sich gegenseitig.

Grund 1: Keine Gebühren pro Ausführung

Das ist das Kostenargument und es ist das schärfste. n8n zählt einen ganzen Workflow-Lauf als eine einzige Ausführung, egal wie viele Schritte er enthält (n8n-Preisseite). Zapier rechnet pro Task ab: Jeder erfolgreich ausgeführte Aktionsschritt ist ein Task, der Trigger selbst zählt nicht und manche Aktionen kosten mehr als einen Task (Zapier-Preisseite).

Rechne einen realistischen Workflow durch:

Workflow: 10 Knoten (Trigger + 9 Aktionen)
Volumen:  10.000 Läufe pro Monat

n8n  (selbst gehostet): 10.000 Ausführungen -> nur Serverkosten
Zapier (pro Task):      9 Aktionen x 10.000 = 90.000 abgerechnete Tasks

Das sind neunmal so viele abgerechnete Einheiten für identische Arbeit. Bei Zapier oder Make skalieren die Kosten damit, wie viel du automatisierst, was Erfolg leise bestraft. Bei selbst gehostetem n8n sind die Kosten der Server und dem Server ist es egal, ob du 1.000 oder 1.000.000 Ausführungen fährst, bis du der Hardware tatsächlich entwächst.

Zum Vergleich die Preise von n8n Cloud: Der Starter-Plan kostet 20 EUR pro Monat für 2.500 Ausführungen, der Pro-Plan 50 EUR pro Monat für 10.000 Ausführungen, jeweils bei jährlicher Abrechnung. Der Business-Plan für 667 EUR pro Monat und 40.000 Ausführungen ist kein Cloud-Plan, sondern eine Lizenz für selbst gehostete Instanzen. Die selbst gehostete Community Edition ist kostenlos; du bezahlst nur den VPS.

Was ein passender VPS kostet, zeigt die Hetzner-Cloud-Preisliste für die deutschen Standorte Falkenstein und Nürnberg (Stand 26. September 2026, monatlich, inklusive IPv4; die Mehrwertsteuer hängt von der Ländereinstellung auf der Seite ab):

Plan	vCPU	RAM	Speicher	Preis pro Monat
CX23 (Cost-Optimized)	2	4 GB	40 GB NVMe	5,99 EUR
CX33 (Cost-Optimized)	4	8 GB	80 GB NVMe	8,99 EUR
CPX22 (Regular Performance)	2	4 GB	80 GB NVMe	19,99 EUR
CPX32 (Regular Performance)	4	8 GB	160 GB NVMe	35,99 EUR

Die Cost-Optimized-Linie war zum Prüfzeitpunkt auf der Hetzner-Seite als vorübergehend nicht bestellbar markiert, prüfe also die aktuelle Verfügbarkeit. n8n nennt für sein eigenes Docker-Compose-Setup mindestens 2 vCPUs und 4 GB RAM als Untergrenze (Docker-Compose-Anleitung). Für n8n mit PostgreSQL und einem Task-Runner-Container ist die 8-GB-Klasse die entspanntere Wahl.

Grund 2: Datensouveränität und DSGVO

Wenn du n8n auf einem EU- oder deutschen Server selbst hostest, bleiben die Daten, die durch deine Workflows fliessen, auf deiner Infrastruktur. Es sitzt kein Drittanbieter-SaaS-Verarbeiter zwischen deinem CRM und deiner Datenbank, was bedeutet: kein Auftragsverarbeitungsvertrag mit einem US-Cloud-Anbieter und keine Frage rund um transatlantische Datentransfers. n8n selbst formuliert es in seiner Datenschutz-Dokumentation so: Bei selbst gehosteten Versionen ist n8n weder Verantwortlicher noch Auftragsverarbeiter, weil das Unternehmen deine Daten nicht verwaltet.

Fairerweise: n8n Cloud selbst läuft laut der Liste der Unterauftragsverarbeiter auf Microsoft Azure in EU-Regionen. Der grosse Unterschied entsteht gegenüber Pro-Task-SaaS-Anbietern mit Sitz und Verarbeitung in den USA. Self-Hosting geht noch einen Schritt weiter und nimmt den Verarbeiter komplett aus der Kette.

Das ist am wichtigsten, wenn Workflows personenbezogene Daten berühren: Lead-Datensätze, Support-Tickets, Rechnungen, alles mit einem Namen und einer E-Mail. Diese Verarbeitung innerhalb deines eigenen Perimeters zu halten, ist eine deutlich einfachere Compliance-Geschichte als sie durch eine US-ansässige Automatisierungs-Cloud zu leiten. Das ist eine fachliche Einordnung, keine Rechtsberatung, aber es nimmt eine ganze Kategorie von Datentransfer-Fragen vom Tisch.

Zwei Pflichten bleiben bei dir: Du bist für Löschungen verantwortlich und n8n empfiehlt dafür, alte Ausführungsdaten automatisch zu bereinigen. Das steuerst du über EXECUTIONS_DATA_PRUNE und EXECUTIONS_DATA_MAX_AGE (Standard: 336 Stunden, also 14 Tage), beschrieben unter Ausführungsdaten verwalten. Und eine selbst gehostete Instanz sendet standardmässig anonyme Telemetrie an n8n; wie du das abschaltest, steht im Abschnitt zur Härtung.

Für Teams, deren ganzer Grund für EU-Infrastruktur die Compliance ist, ist das oft der entscheidende Faktor, noch bevor die Kosten überhaupt zur Sprache kommen.

Grund 3: Kein Vendor Lock-In

Deine Workflows sind JSON. Deine Engine ist Software, die du zwischen Servern verschieben kannst. Deine Datenbank ist Standard-PostgreSQL. Mit n8n export:workflow --backup und n8n export:credentials --backup exportierst du Workflows und Zugangsdaten als lesbare JSON-Dateien und importierst sie auf einer anderen Instanz wieder (Backup und Wiederherstellung). Wenn du einem VPS entwächst, ziehst du auf einen grösseren oder auf ein Cluster um. Nichts an deiner Automatisierungslogik ist in einer proprietären Plattform gefangen, aus der du nicht exportieren kannst.

Die Lizenzrealität: n8n ist Fair-Code, nicht Open Source

Das ist die am häufigsten missverstandene Sache an n8n und es falsch zu verstehen führt zu schlechten Entscheidungen.

n8n ist nicht Open Source im Sinne der OSI. Es ist Fair-Code, veröffentlicht unter der Sustainable Use License in Version 1.0. Dateien mit .ee. im Namen fallen unter die separate n8n Enterprise License. Der Quellcode ist auf GitHub verfügbar und die Community Edition ist kostenlos zu betreiben, aber die Lizenz trägt Einschränkungen, die eine echte Open-Source-Lizenz nicht hätte. n8n schreibt selbst in seiner Lizenzdokumentation, dass es sich deshalb nicht Open Source nennt.

Was die Sustainable Use License laut Lizenz-FAQ von n8n erlaubt:

n8n für interne Geschäftszwecke kostenlos betreiben, auch in mehreren Instanzen
Es für persönliche Projekte, Lernen und Forschung betreiben
Den Quellcode für die eigene Nutzung verändern
Automatisierungen für Kunden auf deiner Instanz bauen und dafür Geld nehmen, solange die Kunden die Workflows nicht selbst erstellen oder bearbeiten können
n8n als unsichtbare Backend-Engine im eigenen Produkt nutzen, solange Endnutzer keine Workflows bauen oder konfigurieren

Was sie verbietet:

n8n als gehosteten Dienst anbieten, in dem deine Kunden selbst Workflows bauen
Endnutzern über dein Produkt erlauben, eigene Workflows zu bauen oder zu konfigurieren, egal ob per eigener Oberfläche, API, MCP oder KI-Agent
Den Code forken und ein eigenes Automatisierungsprodukt daraus machen
n8n White-Label ohne Branding als eigenes Produkt anbieten
Enterprise-Funktionen nutzen, die einen Lizenzschlüssel verlangen, ohne Enterprise-Lizenz

Für die überwältigende Mehrheit der Unternehmen ist diese Unterscheidung in der Praxis irrelevant: Wenn du n8n betreibst, um den eigenen Betrieb zu automatisieren, bewegst du dich genau innerhalb dessen, was die Lizenz erlaubt und das kostenlos. Die Einschränkung greift nur, wenn dein Geschäftsmodell darin besteht, n8n selbst weiterzuverkaufen. Für alles darüber hinaus verlangt n8n eine separate kommerzielle Vereinbarung.

Ein Punkt ist für Dienstleister und ihre Kunden wichtig: Laut FAQ darf ein Dienstleister n8n auf deinem eigenen Server installieren, konfigurieren und betreuen und dafür Honorar berechnen. Er darf dir aber keine von ihm gehostete Instanz bereitstellen, in der du selbst Workflows baust, denn das würde mit n8n Cloud konkurrieren. Genau deshalb läuft ein betreutes Setup sauber auf Infrastruktur, die auf dich läuft.

Die praktische Erkenntnis: Beschreibe n8n nicht als “Open Source” in Verträgen, Ausschreibungen oder Compliance-Dokumenten. Beschreibe es korrekt als “Fair-Code, Source-Available, unter der Sustainable Use License”. Das vermeidet ein Glaubwürdigkeitsproblem und es ist schlicht richtig.

Was die Community Edition nicht hat

Die kostenlose Community Edition enthält laut Editionsvergleich von n8n fast den kompletten Funktionsumfang. Diese Funktionen fehlen und sind den bezahlten Business- und Enterprise-Plänen vorbehalten:

Teilen von Workflows und Zugangsdaten zwischen Nutzern: In der Community Edition sehen nur der Instanz-Eigentümer und der jeweilige Ersteller einen Workflow oder eine Zugangsdate
Projekte mit rollenbasierten Rechten
Single Sign-On per SAML, OIDC oder LDAP
Versionskontrolle mit Git und getrennte Umgebungen (Dev, Staging, Prod)
Externe Secret-Stores und externe Speicherung von Binärdaten
Log-Streaming an externe Systeme (normales Logging ist enthalten)
Multi-Main-Betrieb für Hochverfügbarkeit (der Queue-Mode selbst ist enthalten)
Benutzerdefinierte Variablen

Registrierst du deine Community-Instanz kostenlos mit einer E-Mail-Adresse, bekommst du zusätzlich Ordner, Debugging im Editor und benutzerdefinierte Ausführungsdaten. Bezahlte Pläne werden über einen Lizenzschlüssel freigeschaltet, den du in der Oberfläche unter Einstellungen eingibst oder per N8N_LICENSE_ACTIVATION_KEY setzt (Lizenz verwalten). Die Preisseite ist laut n8n die verbindliche Quelle für den aktuellen Funktionsumfang je Plan.

Die fehlende Freigabe zwischen Nutzern ist der Punkt, der kleine Teams am ehesten überrascht: Zwei Kollegen mit eigenen Konten können ihre Workflows in der Community Edition nicht gegenseitig bearbeiten.

Docker-Setup-Übersicht

Docker ist der sauberste Weg, n8n zu betreiben und ab n8n 3.0 der einzige: n8n kündigt in seiner Ein-Zeilen-Installation an, dass n8n ab Version 3.0 (Start Oktober 2026) nur noch über Docker verteilt wird und npm-Installationen als veraltet gelten. Docker isoliert die Laufzeitumgebung, macht Upgrades zu einer Ein-Zeilen-Operation und hält deinen Host-Server aufgeräumt. Das Referenz-Setup ist n8n plus eine PostgreSQL-Datenbank plus ein Task-Runner-Container, hinter einem Reverse Proxy, der HTTPS übernimmt.

Betreibe ein produktives n8n nicht auf der voreingestellten SQLite-Datenbank. SQLite ist für einen Fünf-Minuten-Test in Ordnung und ein Risiko für alles Echte. n8n unterstützt laut Datenbank-Dokumentation PostgreSQL 17 und 18 vollständig und 16 aus Kompatibilitätsgründen (Stand Juli 2026). Nutze PostgreSQL ab dem ersten Tag.

Hier ist ein minimales docker-compose.yml-Gerüst, das die richtige Form erfasst. Es folgt dem offiziellen Beispiel mit PostgreSQL aus dem n8n-Hosting-Repository:

services:
  postgres:
    image: postgres:18
    restart: always
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=change-me-strong
      - POSTGRES_DB=n8n
      - PGDATA=/var/lib/postgresql/data
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h localhost -U n8n -d n8n"]
      interval: 5s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.40.7
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=change-me-strong
      - N8N_HOST=automation.example.com
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://automation.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=generate-a-long-random-secret
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_AUTH_TOKEN=generate-another-random-secret
      - N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
      - GENERIC_TIMEZONE=Europe/Berlin
      - TZ=Europe/Berlin
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

  n8n-runner:
    image: n8nio/runners:2.40.7
    restart: always
    environment:
      - N8N_RUNNERS_AUTH_TOKEN=generate-another-random-secret
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679
    depends_on:
      - n8n

volumes:
  postgres_data:
  n8n_data:

Ein paar Entscheidungen darin sind bewusst so getroffen:

Die Image-Tags sind auf eine Version festgenagelt (2.40.7 war zum Prüfzeitpunkt die aktuelle stabile Version laut Docker-Installationsseite). Das Runner-Image muss laut Task-Runner-Dokumentation exakt dieselbe Version tragen wie das n8n-Image. Die aktuelle Versionsnummer findest du in den GitHub-Releases.
PGDATA ist gesetzt, weil PostgreSQL 18 sein Datenverzeichnis verschoben hat; ohne diese Zeile startet die Datenbank laut n8n-Dokumentation mit leerem Volume.
N8N_WEBHOOK_URL ersetzt das ältere WEBHOOK_URL, das seit n8n 2.35.0 als veraltet gilt und eine Warnung im Log auslöst. Zusammen mit N8N_PROXY_HOPS=1 sagt es n8n, dass genau ein Reverse Proxy davor sitzt (Webhook-URLs hinter Reverse Proxy).
Der Task Runner läuft als eigener Container im externen Modus. Task Runner führen den Code aus deinen Code-Knoten aus und sind laut n8n die einzige Isolationsschicht zwischen nutzerdefiniertem Code und der Instanz samt Zugangsdaten. Der interne Modus (Runner als Kindprozess von n8n) ist für Produktion nicht empfohlen und wird ab n8n 3.0 als veraltet markiert. Das ältere N8N_RUNNERS_ENABLED ist seit n8n 2.0 nicht mehr nötig.
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true setzt die Konfigurationsdatei mit dem Verschlüsselungsschlüssel auf Rechte 0600 (Sicherheits-Umgebungsvariablen).
GENERIC_TIMEZONE steuert Zeitplan-Knoten, TZ die Systemzeit im Container; die Voreinstellung wäre America/New_York.

Zwei Werte darin sind nicht optional:

N8N_ENCRYPTION_KEY verschlüsselt deine gespeicherten Zugangsdaten. Setzt du ihn nicht, erzeugt n8n beim ersten Start einen zufälligen Schlüssel und legt ihn in der Datei config im Ordner .n8n ab (Verschlüsselungsschlüssel setzen). Wenn du ihn verlierst, wird jede gespeicherte Zugangsdate unlesbar. Erzeuge ihn einmal mit openssl rand -hex 32, lege ihn in deinem Passwortmanager ab und ändere ihn nie. Wer Schlüssel turnusmässig wechseln muss, nutzt die separate Rotation des Datenschlüssels, bei der der Instanzschlüssel unverändert bleibt.
N8N_WEBHOOK_URL muss die öffentliche HTTPS-Adresse sein, die externe Dienste zurückrufen. Ist sie falsch, registriert n8n falsche Webhook-Adressen bei externen Diensten und eingehende Webhooks schlagen stillschweigend fehl.

Beachte, dass der n8n-Port an 127.0.0.1 gebunden ist, nicht an 0.0.0.0. Die Engine sollte nie direkt zum öffentlichen Internet zeigen. Ein Reverse Proxy davor terminiert TLS und ist das Einzige, was nach aussen freigegeben wird. Zum schnellen Ausprobieren ohne eigene Compose-Datei gibt es die offizielle Ein-Zeilen-Installation mit curl -fsSL https://get.n8n.io | sh; sie startet allerdings mit SQLite und ist damit ein Testaufbau, kein Produktionssetup.

Deine n8n-Instanz absichern

Eine selbst gehostete Automatisierungs-Engine hält die Schlüssel zu deinem gesamten Stack: CRM-Zugangsdaten, Tokens von Zahlungsanbietern, E-Mail-API-Schlüssel. Sie abzusichern ist kein optionaler Feinschliff. Behandle sie wie produktive Infrastruktur, denn das ist sie.

HTTPS über einen Reverse Proxy

n8n empfiehlt in seiner SSL-Dokumentation einen Reverse Proxy wie Traefik vor der Instanz, der auch die Zertifikatserneuerung übernimmt. Caddy ist am schnellsten aufgesetzt, weil es Let’s-Encrypt-Zertifikate automatisch bereitstellt und erneuert:

automation.example.com {
    reverse_proxy 127.0.0.1:5678
}

Das ist die gesamte Caddy-Konfiguration für ein funktionierendes HTTPS-Frontend. Caddy setzt laut seiner reverse_proxy-Dokumentation die Header X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host standardmässig, genau die drei, die n8n hinter einem Proxy erwartet. n8n selbst bleibt auf localhost; der Proxy ist die einzige öffentliche Oberfläche. Ohne HTTPS funktioniert der Login übrigens nicht ohne Weiteres, weil n8n sein Sitzungs-Cookie standardmässig nur über HTTPS sendet (N8N_SECURE_COOKIE, Standard true).

Authentifizierung

Die Benutzerverwaltung von n8n (E-Mail plus Passwort, mit rollenbasiertem Zugriff) ist die Grundlinie. Stärke sie:

Nutze starke, einzigartige Zugangsdaten und aktiviere die Zwei-Faktor-Authentifizierung per Authenticator-App; sie steht in allen Editionen jedem Nutzer zur Verfügung. 2FA für alle Nutzer erzwingen kannst du laut Sicherheitsrichtlinien-Dokumentation nur mit Business- oder Enterprise-Lizenz.
Schränke die Admin-Oberfläche wo machbar auf bekannte IP-Bereiche an der Firewall oder Proxy-Ebene ein
Gib Teammitgliedern eigene Konten statt eines geteilten Logins, damit du eine nachvollziehbare Historie hast. Bedenke dabei die Einschränkung der Community Edition: Workflows lassen sich zwischen Konten nicht teilen.
Halte die Instanz vollständig vom öffentlichen Internet fern, wenn sie nur interne Automatisierungen bedient, erreichbar über VPN

Härtung über Umgebungsvariablen

Die Sicherheitsübersicht von n8n listet mehrere Schalter, die auf einer produktiven Instanz gesetzt sein sollten:

N8N_BLOCK_ENV_ACCESS_IN_NODE=true verhindert, dass Ausdrücke und Code-Knoten Umgebungsvariablen lesen, also auch Datenbank-Passwort und Verschlüsselungsschlüssel
N8N_PUBLIC_API_DISABLED=true, wenn du die öffentliche REST-API nicht nutzt
N8N_DIAGNOSTICS_ENABLED=false und N8N_VERSION_NOTIFICATIONS_ENABLED=false schalten die Telemetrie und die Verbindung zu n8n-Servern ab
N8N_SSRF_PROTECTION_ENABLED=true blockiert seit n8n 2.12.0 Anfragen aus Workflows an private Netzbereiche und Cloud-Metadaten-Endpunkte (SSRF-Schutz); für interne Ziele pflegst du eine Allowlist
NODES_EXCLUDE sperrt riskante Knoten wie Execute Command, der standardmässig bereits gesperrt ist (Knoten sperren)

Danach lässt du n8n audit laufen: Der Sicherheits-Audit meldet ungenutzte Zugangsdaten, ungeschützte Webhooks, riskante Knoten und eine veraltete Instanz.

Backups

Ein vollständiges Backup besteht laut Backup-Dokumentation von n8n aus drei Teilen und du brauchst alle:

Die PostgreSQL-Datenbank hält deine Workflows, die Ausführungshistorie, Nutzer und die verschlüsselten Zugangsdaten. Sichere sie mit geplanten pg_dump-Läufen (ein nächtlicher Cronjob ist das Minimum).
Der Ordner .n8n im Volume n8n_data mit der Datei config, die den Verschlüsselungsschlüssel enthält, falls du ihn nicht per Umgebungsvariable setzt.
Deine Deployment-Konfiguration, also Compose-Datei und Umgebungsvariablen inklusive N8N_ENCRYPTION_KEY. Ein Datenbank-Backup ohne den Schlüssel ist ein Backup von verschlüsseltem Müll.

Der nächtliche Datenbank-Dump läuft aus dem Compose-Verzeichnis heraus durch den Datenbank-Container:

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

Lagere Backups ausserhalb des Hosts, idealerweise auf getrenntem EU-Speicher und teste eine Wiederherstellung mindestens einmal. Ein ungetestetes Backup ist eine Hoffnung, kein Backup. n8n empfiehlt ausserdem, vor jedem Update ein vollständiges Backup zu ziehen.

Updates und Versions-Pinning

n8n veröffentlicht laut Docker-Installationsseite fast jede Woche eine neue Minor-Version. Die Update-Empfehlungen von n8n lauten: mindestens einmal im Monat aktualisieren, damit du nie mehrere Versionen auf einmal springen musst, vorher die Release Notes auf Breaking Changes prüfen und vorher ein Backup ziehen.

Mit festgenagelten Tags ist ein Update bewusst und nachvollziehbar: Du änderst die Versionsnummer bei beiden Images in der Compose-Datei, ziehst die Images mit docker compose pull und startest mit docker compose up -d neu. Datenbank-Migrationen führt n8n beim Start selbst aus. Der Tag latest erspart dir das Editieren, macht aber jedes docker compose pull zu einem unkontrollierten Versionssprung. Für Produktion ist der feste Tag die bessere Wahl.

n8n mit dem Queue-Mode skalieren

Ein voreingestelltes n8n läuft in einem einzelnen Prozess. Das ist in Ordnung, bis du auf Volumen, langlaufende Jobs oder viele gleichzeitige Webhooks stösst. Wenn du das tust, ist die Antwort der Queue-Mode.

Im Queue-Mode trennt n8n die Rolle, die Trigger empfängt (die Hauptinstanz), von den Rollen, die Workflows tatsächlich ausführen (Worker-Instanzen), koordiniert über eine Redis-Queue:

                +------------------+
   webhooks --> |  Hauptinstanz    | --> Redis-Queue
                +------------------+          |
                                              v
                              +---------------------------+
                              |  Worker 1   Worker 2 ...  |  (horizontal skalierbar)
                              +---------------------------+
                                              |
                                              v
                                     PostgreSQL (geteilt)

Die Hauptinstanz bleibt reaktionsfähig, weil sie nicht durch das Ausführen schwerer Workflows blockiert wird. Worker ziehen Jobs aus der Queue und führen sie parallel aus. Mehr Durchsatz nötig? Füge mehr Worker hinzu. So bewältigt eine selbst gehostete Instanz ernsthafte Produktionslast, ohne an die Pro-Ausführung-Wand zu stossen, die ein SaaS-Tool hätte.

Die Konfiguration ist überschaubar: EXECUTIONS_MODE=queue auf Hauptinstanz und Workern, QUEUE_BULL_REDIS_HOST und QUEUE_BULL_REDIS_PORT zeigen auf Redis, Worker startest du mit dem Kommando n8n worker und steuern die parallelen Jobs über --concurrency (Standard 10, n8n empfiehlt mindestens 5). Alle Instanzen brauchen denselben N8N_ENCRYPTION_KEY, Zugriff auf Redis und auf die Datenbank. Mit SQLite ist der Queue-Mode nicht unterstützt und jeder Worker braucht seinen eigenen Task-Runner-Container. Mehrere Hauptinstanzen für Hochverfügbarkeit (Multi-Main) sind eine Enterprise-Funktion.

Du brauchst den Queue-Mode nicht am ersten Tag. Starte mit einem einzelnen Prozess und wechsle in den Queue-Mode, wenn Ausführungsrückstau oder Webhook-Latenz dir sagen, dass es Zeit ist. Die Migration ist Konfiguration, kein Neuschrieb.

Anwendungsfälle: Was Unternehmen tatsächlich automatisieren

Selbst gehostetes n8n verdient seinen Platz bei gängigen, hochfrequenten Geschäfts-Workflows:

Lead-Erfassung und -Verteilung: Ein Formular-Eingang oder eingehender Webhook erstellt einen CRM-Datensatz, weist einen Verantwortlichen zu und postet eine Benachrichtigung, in Sekunden und ohne manuelle Triage.
Lead-Anreicherung und -Scoring: Eingehende Leads werden aus externen Datenquellen angereichert und bewertet, damit der Vertrieb Zeit für die richtigen Kontakte aufwendet.
CRM-Datenhygiene: Geplante Workflows entdoppeln Datensätze, normalisieren Felder und markieren veraltete Einträge automatisch.
Dokumenten- und Rechnungs-Workflows: Dokumente erzeugen, verteilen und ablegen; Rechnungsdaten zwischen Abrechnungs- und Buchhaltungssystemen schieben.
Interner Betrieb und IT: Provisionierung, Alarmierung, Daten zwischen internen Tools synchronisieren und der lange Schwanz an Klebearbeit, der sonst Entwicklerstunden auffrisst.

Der dokumentierte Enterprise-ROI ist real. Delivery Hero spart laut n8n-Fallstudie mit einem einzigen IT-Ops-Workflow zur Kontowiederherstellung 200 Stunden pro Monat. StepStone betreibt laut Fallstudie über 700 aktive Workflows in Produktion und verarbeitet damit zwei bis drei Millionen Stellendokumente pro Monat. Beide nutzen die Enterprise-Variante, aber es ist dieselbe Engine, die du selbst hosten kannst.

KI-Workflows auf deinem eigenen Server

Hier wird Self-Hosting zu einem echten strategischen Vorteil und nicht nur zu einem Kostenspiel.

n8n bringt eine ganze Familie von KI-Knoten auf Basis von LangChain mit: Agenten, Chains, Speicher, Tools, Output-Parser und Vektorspeicher, in der Dokumentation als Cluster-Knoten geführt. Darunter sind Vektorspeicher-Knoten für Pinecone, Qdrant, Weaviate, Chroma, PGVector, Milvus, Supabase und Redis sowie Chat-Modell-Knoten für OpenAI, Anthropic, Google Gemini, Mistral, AWS Bedrock, Azure OpenAI und weitere Anbieter. Entscheidend: Es unterstützt lokale Modelle über den Ollama-Chat-Modell-Knoten und einen passenden Ollama-Embeddings-Knoten.

Dieser letzte Punkt ist der Befreiungsschlag. Du kannst eine komplette LLM-Pipeline bauen, Dokumenteneinlesung, Embedding, Vektorsuche, Generierung, die vollständig auf deinem eigenen Server läuft, mit dem Modell selbst lokal über Ollama. Deine Prompts und deine Dokumente berühren niemals OpenAI oder eine externe API. Für Unternehmen, die sensible oder regulierte Daten verarbeiten, ist das souveräne KI: Die Intelligenzschicht lebt innerhalb desselben EU-Perimeters wie alles andere.

Eine typische RAG-auf-eigener-Infrastruktur-Form sieht so aus:

Dokumente   --> [Embedding per lokalem Modell] --> [Vektor-DB: Qdrant]
Nutzerfrage --> [relevante Abschnitte abrufen]  --> [lokales LLM via Ollama] --> Antwort
                                  (alle Knoten laufen in deiner n8n-Instanz)

n8n veröffentlicht dafür das Self-hosted AI Starter Kit, eine Docker-Compose-Vorlage mit n8n, Ollama, Qdrant und PostgreSQL. n8n selbst stuft es in der Dokumentation als Testumgebung ein, die vor dem Produktionseinsatz abgesichert und gehärtet werden muss. Wenn ein Chatbot, ein interner Wissensassistent oder ein dokumentenverarbeitender Agent auf deiner Roadmap steht und die Daten sensibel sind, erlaubt diese Architektur, ihn zu bauen, ohne diese Daten irgendwohin zu exportieren.

DIY gegen Managed: Der ehrliche Kompromiss

n8n selbst zu hosten ist tatsächlich zugänglich. Ein Basis-Docker-Setup ist eine Ein- bis Drei-Stunden-Aufgabe für jemanden, der auf einem Linux-Server sattelfest ist. n8n selbst empfiehlt Self-Hosting ausdrücklich erfahrenen Nutzern, weil Fehler zu Datenverlust, Sicherheitslücken und Ausfällen führen können. Wann ergibt es also Sinn, es selbst zu betreiben und wann nicht?

DIY ergibt Sinn, wenn:

Du interne Ops- oder DevOps-Kapazität hast
Die Workflows intern und anfangs nicht geschäftskritisch sind
Du die Plattform tief lernen willst
Ausfallzeit bei Automatisierung ein Ärgernis ist, kein Umsatzereignis

Managed ergibt Sinn, wenn:

Automatisierung tragend ist und Ausfallzeit echtes Geld kostet
Niemand im Team Server-Patching, Backups, Monitoring und Versions-Upgrades verantworten will
Du die DSGVO- und Sicherheitslage nachweisbar korrekt brauchst, nicht improvisiert
Du lieber hast, dass deine Leute Workflows bauen, als Infrastruktur zu hüten

Die versteckten Kosten von DIY sind nicht das initiale Setup; es ist die laufende Betriebssteuer. Wöchentliche Releases, Backup-Verifizierung, Monitoring, Sicherheits-Patches, Queue-Mode-Tuning und Incident-Response summieren sich. Die Engine ist kostenlos. Sie gut zu betreiben, auf Dauer, ist die eigentliche Arbeit.

Wenn du n8n selbst gehostet auf deutscher Infrastruktur möchtest, mit Sicherheit, Backups, Monitoring und Updates erledigt, ist genau das, was unser n8n-Automatisierungs-Service liefert, lizenzkonform auf Infrastruktur, die auf dich läuft. Und wenn deine grössere Frage ist, ob du überhaupt eigene Automatisierungs-Infrastruktur bauen solltest, statt SaaS-Tools zusammenzustückeln, geht unser Automatisierungs-Service diese Entscheidung mit dir durch.

Häufig gestellte Fragen

Ist n8n kostenlos?

Die selbst gehostete Community Edition ist kostenlos. Du bezahlst nur den Server, auf dem sie läuft; bei Hetzner beginnt ein passender VPS laut Preisliste bei 5,99 EUR pro Monat für 2 vCPUs und 4 GB RAM. n8n Cloud und die Business- und Enterprise-Pläne sind kostenpflichtig, wobei die Cloud-Pläne bei 20 EUR pro Monat für 2.500 Ausführungen bei jährlicher Abrechnung beginnen.

Ist n8n Open Source?

Nein. n8n ist Fair-Code, Source-Available unter der Sustainable Use License. Du kannst es für interne Geschäftsnutzung kostenlos betreiben, aber du darfst es nicht als gehosteten Dienst anbieten, in dem Kunden selbst Workflows bauen. Beschreibe es als “Fair-Code”, nicht als “Open Source”, um korrekt zu bleiben.

Ist selbst gehostetes n8n DSGVO-konform?

Self-Hosting auf einem EU- oder deutschen Server hält deine Daten innerhalb deiner eigenen Infrastruktur, was die Datentransfer- und Verarbeiter-Fragen entfernt, die mit US-SaaS-Automatisierung einhergehen. Das Setup allein macht dich nicht konform; wie du es absicherst, betreibst und Ausführungsdaten bereinigst, tut das. Das ist eine fachliche Einordnung, keine Rechtsberatung.

Brauche ich Docker, um n8n selbst zu hosten?

Ab n8n 3.0 ja: n8n verteilt n8n dann nur noch über Docker und stuft npm-Installationen als veraltet ein. Docker macht Installation, Isolierung und Upgrades ohnehin deutlich einfacher und die eigene Dokumentation von n8n ist darauf ausgerichtet.

Wann brauche ich den Queue-Mode?

Wenn ein einzelner Prozess nicht mehr mithalten kann: Ausführungsrückstaus, langsame Webhook-Antworten oder viele gleichzeitige langlaufende Workflows. Starte mit einem einzelnen Prozess und wechsle in den Queue-Mode (Hauptinstanz plus Worker plus Redis), wenn das Volumen es verlangt.

Kann ich KI-Workflows fahren, ohne Daten an OpenAI zu senden?

Ja. n8n unterstützt lokale Modelle über Ollama neben seinen LangChain-basierten KI-Knoten und den grossen Vektordatenbanken. Du kannst eine vollständige RAG-Pipeline komplett auf deinem eigenen Server fahren, sodass Prompts und Dokumente deine Infrastruktur nie verlassen.

Was passiert, wenn ich den Verschlüsselungsschlüssel verliere?

Jede gespeicherte Zugangsdate wird unlesbar. Der N8N_ENCRYPTION_KEY ist so wichtig wie die Datenbank selbst. Erzeuge ihn einmal, lege ihn in einem Passwortmanager ab und nimm ihn in deinen Notfallwiederherstellungsplan auf. Ein Datenbank-Backup ohne den Schlüssel ist nutzlos.

Zusammenfassung: Self-Hosting-Checkliste

Selbst gehostetes n8n gibt dir Automatisierung ohne Gebühren pro Ausführung, auf Infrastruktur, die du kontrollierst, mit einer sauberen DSGVO-Geschichte und einem echten Weg zu souveräner KI. Die Engine ist kostenlos. Der Wert liegt darin, sie gut zu betreiben und in der Entscheidung, ob das die Aufgabe deines Teams ist oder unsere.

Wenn Automatisierung für dein Unternehmen tragend wird, sieh dir unseren n8n-Automatisierungs-Service für ein betreutes Setup auf deutschen Servern an oder unseren Automatisierungs-Service, um eigene Infrastruktur gegen SaaS abzuwägen. Wenn du zuerst gemeinsam abstecken möchtest, was in deinem Fall sinnvoll ist, buche ein kostenloses Erstgespräch.

n8n Self-Hosting Anleitung: Automatisierung auf EU-Infrastruktur selbst betreiben