Self-Hosting n8n: was die Dokumentation Ihnen nicht sagt

Wenn Self-Hosting nicht mehr nach Souveränität, sondern nach Wochenend-Diensten klingt

Letzten Monat saßen wir bei einem Kunden in Stuttgart. Sechzig produktive Workflows in einer selbst gehosteten n8n-Instanz, etwa 150 Ausführungen pro Stunde, drei interne Teams als Nutzer. Die Frage am Tisch: warum die Instanz seit zwei Wochen jeden Donnerstag um 22 Uhr für sieben Minuten unreachable ist.

Wir haben drei Stunden gebraucht, um die Ursache zu finden. Es war kein n8n-Bug. Es war der Backup-Job auf dem darunterliegenden Server, der die Postgres-Instanz so stark belastete, dass die Worker-Container ihre Health Checks verloren. Steht in der Dokumentation. Irgendwo, in einem Forum-Thread aus 2024. Niemand liest das, bevor er produktiv geht.

Diese Geschichten kennen wir aus jedem Self-Hosting-Setup, das nicht von Anfang an mit Operations-Brille gebaut wurde. n8n im Self-Hosting verspricht drei Dinge: Datensouveränität, planbare Kosten, volle Kontrolle. In den ersten Wochen erfüllt es alle drei. Im zweiten Jahr stellt sich die Frage anders.

Wir betreiben seit zwei Jahren n8n im Self-Hosting, für uns selbst und für einen guten Teil unserer Kunden. In dieser Zeit haben wir gelernt, was die offizielle Dokumentation zu sanft formuliert und was die Marketing-Seiten gar nicht erwähnen. Dieser Artikel fasst zusammen, was wir Kunden sagen, bevor sie sich für Self-Hosting entscheiden.

Warum überhaupt Self-Hosting?

Drei Gründe hören wir am häufigsten, und alle drei sind legitim.

Der erste ist Datensouveränität. Wer in regulierten Branchen arbeitet, im Gesundheitswesen, in der Finanzbranche, in der öffentlichen Verwaltung, hat oft die explizite Vorgabe, dass bestimmte Daten den eigenen Verantwortungsbereich nicht verlassen dürfen. Eine SaaS-Plattform, deren Daten durch US-amerikanische Rechenzentren laufen, scheidet aus, auch wenn sie europäische Server anbietet.

Der zweite ist Kostenkontrolle. n8n Cloud rechnet pro Workflow-Ausführung, mit gestaffelten Plänen. Bei Volumen ab etwa 10.000 Ausführungen pro Monat wird die Cloud spürbar teurer als ein selbst gehosteter Server, der einmal aufgesetzt wird und dann die Inkrement-Kosten gegen null laufen lässt. Auf dem Papier.

Der dritte ist Erweiterbarkeit. Wer eigene Nodes bauen, mit internen Systemen ohne öffentliche API sprechen oder die Standard-Funktionalität anpassen will, kommt im Self-Hosting deutlich weiter als in der Cloud. Wir nutzen das selbst regelmäßig für Kunden mit Spezial-Anforderungen.

So weit die Theorie. Jetzt der Reihe nach, was in der Praxis passiert.

Realität eins: Backups sind kein Knopf

Die n8n-Dokumentation widmet dem Backup-Thema einen Abschnitt. Im Kern steht dort: nimm pg_dump, schreib es in einen S3-Bucket, fertig. Das ist technisch korrekt und betrieblich naiv.

In der Praxis stellen sich vier Fragen, die der Dokumentations-Abschnitt nicht beantwortet.

Wann backupen wir? Wenn die Instanz 24/7 läuft, gibt es kein natürliches Wartungsfenster. Backups während aktiver Workflow-Ausführungen führen entweder zu inkonsistenten Snapshots oder zu spürbarem Performance-Einbruch. Wir machen Postgres-Backups mit pg_basebackup zur Nebenzeit, plus WAL-Archivierung kontinuierlich. Das erlaubt Point-in-Time Recovery, kostet aber Speicher und eine durchdachte Retention-Strategie.

Wohin backupen wir? S3 ist die nahe liegende Antwort, aber wer Datensouveränität wegen US-Cloud-Provider gewählt hat, kann nicht plötzlich Backups bei AWS landen. Wir nutzen je nach Kunde Hetzner Object Storage, Wasabi oder einen MinIO-Cluster im eigenen Rechenzentrum. Jede Option hat eigene Kosten, eigene Latenzen und eigene Quirks beim Restore.

Wie testen wir Restores? Ein Backup, das nie zurückgespielt wurde, ist kein Backup, sondern eine Hoffnung. Wir spielen pro Kunde mindestens einmal pro Quartal einen Restore in eine isolierte Umgebung ein und prüfen, ob die Workflows danach laufen. Das ist nicht trivial, weil Credentials verschlüsselt sind und ein Restore mit falschem Encryption Key zwar formal erfolgreich, aber funktional nutzlos ist.

Was sichern wir noch außer der Datenbank? Workflow-Definitionen, das ist klar. Aber auch Credentials, deren Verschlüsselungs-Schlüssel separat lebt. Custom Nodes, die als Datei-Mount eingebunden sind. Webhook-Endpoints mit ihren generierten URLs. Bei einer großen Instanz ist das ein Backup-Bündel aus vier oder fünf Quellen, das im Recovery-Fall in der richtigen Reihenfolge eingespielt werden muss.

Wir haben Kunden gesehen, die ein halbes Jahr produktiv liefen, bevor jemand ein Restore versucht hat. Das Restore hat nicht funktioniert. Niemand wusste, warum. Die Workflows liefen erst eine Woche später wieder, nach Rückspielen aus einer alten Export-Datei.

Realität zwei: Updates sind kein npm install

n8n veröffentlicht alle ein bis zwei Wochen ein neues Release. Bugfixes, neue Nodes, gelegentlich Breaking Changes in der Node-API. Die Versuchung ist groß, einfach automatisch zu aktualisieren. Wir tun das nie.

Drei Dinge, die uns Updates immer wieder schwer gemacht haben.

Datenbank-Migrations. Manche Releases bringen Schema-Änderungen mit. Bei kleinen Instanzen läuft die Migration in Sekunden. Bei Instanzen mit Millionen Execution-Einträgen kann ein Update zehn Minuten oder länger blockieren. Wer ohne Pflege seiner Execution-History updatet, wartet im schlimmsten Fall eine Stunde, ohne dass etwas läuft.

Breaking Changes in Custom Nodes. Wer eigene Nodes geschrieben hat, gegen eine bestimmte n8n-API, riskiert mit jedem Major-Update einen Bruch. Das ist nicht häufig, aber wenn es passiert, kostet es Tage, weil die Diagnose oft nicht offensichtlich ist. Workflows laufen weiter, geben aber falsche Werte zurück.

Node-Deprecations. n8n entfernt regelmäßig veraltete Nodes oder ändert deren Signaturen. Workflows, die produktiv laufen, scheitern dann mit Fehlermeldungen, die nicht immer auf die eigentliche Ursache hinweisen. Wir haben einen Workflow erlebt, der nach einem Update zehn Tage lang stille Fehler produzierte, weil ein Node-Output sich von String auf Number geändert hatte.

Unsere Praxis: Wir updaten auf eine Staging-Instanz, lassen dort eine Auswahl an Smoke-Test-Workflows laufen, schauen uns Release-Notes durch, prüfen Custom Nodes auf Kompatibilität und ziehen erst dann das Update für Produktion. Das kostet pro Release etwa zwei Stunden Aufwand, und es ist die Kosten wert.

Realität drei: Skalierung heißt Queue Mode

Im Default läuft n8n als einzelner Container, der gleichzeitig Webserver, Worker und Scheduler ist. Das funktioniert bis zu einer Grenze, die irgendwo zwischen 10 und 50 parallelen Executions liegt, je nachdem, wie schwer die Workflows sind und wie viel der Host hergibt.

Wer mehr braucht, schaltet auf Queue Mode um. Das heißt: ein Webserver-Container für die UI und Webhooks, ein oder mehrere Worker-Container für die Ausführung, eine Redis-Instanz als Queue. Klingt nach Standard-Architektur, ist es auch, aber die Implementierung enthält eine ganze Reihe Fußangeln.

Erste Fußangel: Webhook-Reaktionen. In Single-Mode reagiert n8n unmittelbar auf einen eingehenden Webhook. In Queue Mode wird der Webhook empfangen, ein Job in Redis eingestellt, und der Worker führt ihn aus, bevor er antwortet. Das funktioniert für die meisten Fälle, kann aber zu Timeouts führen, wenn der Worker gerade voll ausgelastet ist oder der Workflow lange läuft.

Zweite Fußangel: Sticky Sessions. Die UI braucht für bestimmte Aktionen Konsistenz zwischen Requests. Wer hinter einen Load Balancer geht, muss Sticky Sessions konfigurieren oder erleben, dass der Workflow-Editor regelmäßig falsche Zustände zeigt.

Dritte Fußangel: Worker-Skalierung. Mehr Worker bedeuten mehr Throughput, aber auch mehr Datenbankverbindungen. Wir haben eine Instanz erlebt, die unter Last in das Connection-Pool-Limit gelaufen ist, weil pro Worker ein Pool aufgemacht wurde, und der Postgres-Server irgendwann einfach keine neuen Verbindungen mehr annahm. Die Workflows haben dann mit vollständig verwirrenden Fehlermeldungen abgebrochen.

Vierte Fußangel: Redis-Persistenz. Im Default speichert Redis Queue-Daten in-memory. Crasht Redis, sind alle nicht-abgearbeiteten Jobs weg. Wer das nicht will, konfiguriert AOF-Persistenz, was Performance kostet, oder nutzt einen Managed-Redis-Service, was Kosten und einen weiteren externen Provider bedeutet.

Wir setzen Queue Mode bei Kunden mit über 1.000 Ausführungen pro Stunde ein. Für alles darunter ist Single-Mode der Pflegeaufwand wert nicht, und der Performance-Gewinn ist marginal.

Realität vier: Monitoring ist kein Add-on

n8n hat keine eingebaute Alerting-Funktion auf Plattform-Ebene. Es gibt eine Workflow-Übersicht und Execution-Logs, das war's. Wer wissen will, ob die Plattform selbst läuft, ob ein Workflow seit drei Tagen stillsteht oder ob die Datenbankverbindung zu thrashen anfängt, braucht eigene Monitoring-Infrastruktur.

Wir setzen pro produktiver Instanz vier Monitoring-Ebenen auf.

Erste Ebene: Liveness der Container. Wir prüfen alle zwei Minuten, ob der Webserver und alle Worker antworten. Tools dafür: Prometheus mit Blackbox Exporter, Uptime Kuma, oder Healthchecks.io für einen externen Heartbeat.

Zweite Ebene: Datenbank-Gesundheit. Postgres-Verbindungen, Query-Latenz, Replikations-Lag, freier Speicher. Hier nutzen wir den Standard-Postgres-Exporter und Grafana-Dashboards.

Dritte Ebene: Workflow-Erfolgsraten. n8n schreibt jede Execution in die Datenbank, mit Status. Wir bauen eine simple Query, die Fehlerquoten pro Workflow ausgibt, und alarmieren, wenn ein Workflow innerhalb einer Stunde mehr Fehler als Erfolge produziert.

Vierte Ebene: Externe Heartbeats für kritische Workflows. Workflows, die einmal pro Tag laufen sollen, schicken am Ende einen Ping an einen externen Monitor. Bleibt der Ping aus, schlägt der Alarm. Das fängt den Fall ab, in dem n8n technisch läuft, der Workflow aber aus irgendeinem Grund nicht startet.

Diese vier Ebenen einmal sauber aufzusetzen, sind etwa zwei Tage Aufwand. Wer sie weglässt, fliegt blind. Wir hatten einen Kunden, dessen tägliche Datenexporte zwei Wochen lang fehlschlugen, ohne dass es jemand bemerkte. Erst als der CFO nach dem Monatsabschluss fragte, fiel auf, dass keine Daten ankamen. Ursache: ein abgelaufenes API-Token. Hätte ein einfacher Heartbeat-Alarm sofort gezeigt.

Realität fünf: Sicherheit braucht eine Architektur, keine Checkliste

Self-Hosting heißt: Sie sind verantwortlich für die Sicherheit der Plattform. Nicht nur für die Konfiguration, sondern auch für das Netzwerk, das Betriebssystem, die TLS-Zertifikate, die Zugriffskontrolle, die Audit-Logs.

Drei Bereiche, in denen wir in Audits regelmäßig Lücken finden.

Erstens, Webhook-Endpoints. Jeder Webhook in n8n ist im Default öffentlich erreichbar. Wer keine Authentifizierung konfiguriert, kann von jedem im Internet getriggert werden. Wir haben Instanzen gesehen, deren Webhooks im Logfile von Bots regelmäßig probiert wurden. Manche dieser Webhook-Triggern führen zu E-Mail-Versand, zu CRM-Einträgen, zu Slack-Nachrichten. Ein Angreifer braucht nur die URL.

Zweitens, Credentials-Encryption. n8n verschlüsselt Credentials mit einem Encryption Key, der im Default in der Container-Environment-Variable liegt. Wer den Container mit dem falschen Recht ausstattet oder das Image in eine geteilte Registry pusht, riskiert, dass der Key in Container-Layern oder in Logs landet. Wir trennen den Encryption Key in einen externen Secret-Manager und mounten ihn pro Container neu.

Drittens, Database-Zugang. Wer von außerhalb des Stacks auf die Postgres-Datenbank zugreifen kann, kann nicht nur Workflows lesen, sondern auch Credentials in ihrem verschlüsselten Zustand exportieren. Mit dem Encryption Key sind sie dann trivial entschlüsselbar. Wir sperren die Datenbank konsequent ins interne Netz, ohne Public-Interface.

Diese drei Punkte sind in jeder Sicherheits-Checkliste für Webanwendungen Standard. Im Self-Hosting tauchen sie regelmäßig auf, weil Teams die Installation per Quick-Start gemacht haben und die Härtung später nachholen wollen. Später kommt selten.

Die versteckte Kostenrechnung

Auf der Marketing-Seite sieht Self-Hosting nach Quasi-Null-Kosten aus. Ein VPS für 30 Euro im Monat, eine Postgres-Instanz, fertig. Die echte Kostenrechnung sieht anders aus.

Wir kalkulieren bei Kunden inzwischen so: Infrastruktur ist etwa ein Viertel der Gesamtkosten. Backup-Infrastruktur und Object Storage ein weiteres Viertel. Monitoring-Stack ein weiteres Viertel. Pflege-Aufwand, also Updates, Restores, Incident Response, das letzte Viertel.

Bei einem kleinen Setup mit etwa 5.000 Ausführungen pro Monat, das einmalig aufgesetzt und dann selten angefasst wird, kostet Self-Hosting realistisch 200 bis 300 Euro im Monat, davon vielleicht 60 Euro Infrastruktur. Der Rest ist anteiliger Operations-Aufwand, der bei Self-Hosting immer existiert, ob er gezahlt oder geschluckt wird.

Bei einem großen Setup mit 50.000 Ausführungen pro Monat, mit Queue Mode, Backups und ordentlichem Monitoring, kommen wir auf 800 bis 1.500 Euro im Monat. Davon sind 200 bis 400 Euro reine Infrastruktur, der Rest ist Operations.

Im Vergleich rechnet n8n Cloud im Pro-Plan etwa 50 Euro für 10.000 Ausführungen, im Business-Plan 600 Euro für 100.000 Ausführungen. Für viele unserer Kunden ist die Cloud-Rechnung am Ende nicht teurer als das, was Self-Hosting realistisch kostet, wenn man die Operations ehrlich einrechnet.

Self-Hosting lohnt sich finanziell vor allem, wenn drei Bedingungen erfüllt sind: Sie betreiben es bereits für andere Workloads (Postgres, Redis, Monitoring sind schon da), Sie haben hohe Volumen über 50.000 Ausführungen pro Monat, oder Datensouveränität ist nicht verhandelbar.

Wann wir Self-Hosting empfehlen

Bei Kunden, die unter 5.000 Workflow-Ausführungen pro Monat brauchen und keine harten Datensouveränitäts-Vorgaben haben, empfehlen wir n8n Cloud. Die Rechnung kommt billiger, das Wochenende bleibt frei.

Bei Kunden mit harten regulatorischen Anforderungen, etwa in der Gesundheitsversorgung, im Finanzbereich oder in der öffentlichen Verwaltung, empfehlen wir Self-Hosting. Hier zählt nicht der Preis, sondern die Kontrolle.

Bei Kunden mit eigenen IT-Teams und vorhandener Operations-Reife, etwa wenn schon ein internes Monitoring-Stack, ein Backup-System und ein Patch-Management existieren, ist Self-Hosting ein guter Hebel, um Plattform-Kosten zu drücken und gleichzeitig technische Tiefe aufzubauen.

Bei Kunden ohne IT-Operations-Erfahrung raten wir fast immer ab. Self-Hosting ist nicht eine Plattform, sondern ein Stack, und ein Stack braucht jemanden, der ihn pflegt. Wer das nicht hat, kauft sich später teurer ein, entweder über Beratung oder über Ausfälle.

Drei Fragen vor jeder Self-Hosting-Entscheidung

Bevor wir mit einem Kunden in die Installation gehen, beantworten wir drei Fragen.

Erstens: Wer ist verantwortlich, wenn die Instanz um zwei Uhr morgens nicht mehr läuft? Wenn die Antwort "wir schauen morgens danach" lautet, ist das eine bewusste Entscheidung über die SLA. Wenn die Antwort "wir wissen es nicht" lautet, ist Self-Hosting der falsche Weg.

Zweitens: Welche Workflows brauchen die Plattform wirklich dringend? Ein Self-Hosting-Setup ist gerechtfertigt, wenn der Schaden eines Ausfalls hoch ist. Wenn die Workflows eine Stunde liegen können ohne reale Folgen, ist die Cloud meist die billigere Lösung.

Drittens: Wer testet das Restore? Ein Backup ohne erfolgreichen Test ist Aberglaube. Wer kein Quartal-Restore plant, hat keinen Disaster-Recovery-Plan, sondern eine Hoffnung.

Wenn alle drei Antworten klar sind, gehen wir in die Architektur. Wenn nicht, gehen wir in die Beratung zurück.

Was wir nach zwei Jahren denken

Self-Hosting n8n ist nicht schwer, aber es ist anhaltend aufwändig. Die Installation ist eine Sache von Stunden. Der Betrieb ist eine Sache von Jahren, mit kontinuierlicher Pflege, regelmäßigen Updates, gelegentlichen Incidents und einem Monitoring-Stack, der mitwächst.

Wir betreiben es weiter, weil wir die Erfahrung, die Infrastruktur und die Routine haben. Wir empfehlen es nur dann, wenn der Kunde dieselbe Reife mitbringt oder bereit ist, sie aufzubauen.

Die ehrliche Sicht auf Self-Hosting ist nicht eine ideologische Frage zwischen Open Source und Vendor Lock-in. Es ist eine Frage von Kosten, Verantwortung und Betriebsreife. Wer das verstanden hat, kann eine fundierte Entscheidung treffen. Wer Self-Hosting wählt, weil die Cloud-Rechnung schmerzt, sollte zweimal nachrechnen.

Falls Sie unsicher sind, ob Self-Hosting für Ihren Stack die richtige Entscheidung ist, oder ob Ihr aktuelles Setup operativ tragfähig läuft, lohnt sich ein Blick in unseren kostenlosen Automations-Check. Wir schauen uns Ihr Setup gemeinsam an, prüfen die fünf Realitäten und sagen Ihnen ehrlich, ob Sie operativ schon dort sind, wo Self-Hosting sich rechnet.