Kurzantwort: Self-Hosting ist eine Betriebsentscheidung
n8n selbst zu hosten bedeutet nicht nur, einen Container zu starten. Für einen produktiven Workflow müssen Datenbank, Verschlüsselungsschlüssel, Binärdaten, Konfiguration, Updates, Protokolle, Monitoring und Wiederherstellung als zusammenhängendes System geplant werden. n8n verschlüsselt gespeicherte Zugangsdaten mit einem eigenen Schlüssel; ohne denselben Schlüssel kann eine wiederhergestellte Datenbank ihre Credentials nicht sinnvoll nutzen Quelle 1.
Für kleine und mittlere Unternehmen ist Self-Hosting dann sinnvoll, wenn Kontrolle über Infrastruktur und Betriebsmodell den zusätzlichen Aufwand rechtfertigt. Wer keine eigene oder beauftragte Betriebsverantwortung festlegen kann, sollte n8n Cloud als Alternative ernsthaft prüfen. Eine pauschale Aussage, Self-Hosting sei günstiger, sicherer oder automatisch datenschutzkonform, wäre falsch.
n8n Cloud oder Self-Hosting?
Die Entscheidung beginnt nicht beim Serverpreis, sondern bei Zuständigkeit und Risiko.
| Prüffrage | n8n Cloud kann passen, wenn … | Self-Hosting kann passen, wenn … |
|---|---|---|
| Wer betreibt die Plattform? | das eigene Team Infrastruktur abgeben möchte | intern oder extern eine klare Betriebsrolle existiert |
| Wo liegen die Anforderungen? | Standardbetrieb und planbare Plattformleistungen genügen | Netzwerk, Deployment oder Datenflüsse besondere Vorgaben haben |
| Wer reagiert auf Störungen? | der Plattformbetrieb nicht selbst übernommen werden soll | Alarmierung, Bereitschaft und Eskalation vereinbart sind |
| Wie werden Updates getestet? | die Plattform den Basisbetrieb aktualisiert | eine Test-, Freigabe- und Rückfallroutine vorhanden ist |
| Wie wird wiederhergestellt? | Plattformfunktionen und eigener Workflow-Export ausreichen | Datenbank, Schlüssel, Dateien und Konfiguration gemeinsam gesichert werden |
Die angebundenen Systeme bleiben in beiden Varianten Teil des Datenflusses. CRM, E-Mail, Buchhaltung, KI-Dienst oder Shop können Daten außerhalb der n8n-Instanz verarbeiten. Hosting-Ort und Datenschutzbewertung sind deshalb nicht dasselbe.
Was ein vollständiges n8n-Backup umfasst
Die n8n-CLI kann Workflows und Credentials für Backup oder Migration exportieren. Diese Exporte allein ergeben jedoch noch kein vollständiges Betriebs-Backup Quelle 9. Für eine Wiederherstellung sollten mindestens die folgenden Bestandteile bewertet werden. Welche davon tatsächlich benötigt werden, hängt von Installation, Datenbank und Binärdatenmodus ab.
1. Datenbank
Die Datenbank enthält unter anderem Workflows, Ausführungsinformationen und verschlüsselte Credentials. n8n beschreibt SQLite als Standardoption und PostgreSQL als unterstützte Alternative; die Sicherungs- und Wiederherstellungsroutine muss zur gewählten Datenbank passen. Ein verteiltes Queue-Setup über SQLite wird nicht unterstützt Quelle 4, Quelle 5. Ein Snapshot ohne dokumentierte Version, Konsistenz und Restore-Verfahren ist nur eine Datei, noch kein getestetes Backup.
2. Verschlüsselungsschlüssel
n8n erzeugt beim ersten Start einen Schlüssel und speichert ihn standardmäßig im Benutzerverzeichnis. Alternativ kann N8N_ENCRYPTION_KEY gesetzt werden. In Queue Mode müssen Hauptinstanz und Worker denselben Schlüssel verwenden Quelle 1. Der Schlüssel gehört geschützt, getrennt und zugriffsbeschränkt gesichert. Er gehört weder in ein öffentliches Repository noch unverschlüsselt direkt neben die Datenbanksicherung.
3. Binärdaten
Workflows können Dateien wie PDFs, Bilder oder Anhänge verarbeiten. n8n hält Binärdaten standardmäßig im Arbeitsspeicher; bei großen Dateien kann das zu Abstürzen führen. Der Dateisystemmodus kann den Arbeitsspeicher einer einzelnen Instanz entlasten, wird aber im Queue Mode nicht unterstützt. Dort müssen Datenbankmodus oder ein zur Architektur passender gemeinsamer externer Speicher geprüft werden Quelle 8. Der aktive Modus verändert den Backup-Umfang. Vor dem Betrieb muss dokumentiert sein, wie lange Binärdaten benötigt werden und wie sie zusammen mit der Datenbank konsistent wiederhergestellt werden.
4. Betriebs- und Deployment-Konfiguration
Dazu zählen je nach Aufbau Compose- oder Deployment-Dateien, Reverse-Proxy-Konfiguration, Domain- und Webhook-Einstellungen, Datenbankparameter sowie die Liste benötigter Secrets. Geheimnisse selbst sollten über einen geeigneten Secret-Speicher verwaltet werden. Das Ziel ist eine reproduzierbare Konfiguration, ohne Zugangsdaten in der Dokumentation offenzulegen.
5. Abhängigkeiten und Versionen
Dokumentieren Sie die eingesetzte n8n-Version, Datenbankversion, Community Nodes und weitere betriebsrelevante Komponenten. Ein Restore kann scheitern, wenn Backup und Zielumgebung technisch nicht zusammenpassen. Die n8n-Dokumentation empfiehlt regelmäßige Updates und einen Test vor dem produktiven Einspielen Quelle 3.
Restore-Test: Der entscheidende Teil des Backups
Ein grünes Backup-Protokoll beweist nur, dass Daten geschrieben wurden. Es beweist nicht, dass der Geschäftsprozess wieder funktioniert. Ein Restore-Test sollte deshalb in einer isolierten Umgebung mindestens diese Schritte abdecken:
- Zielumgebung mit dokumentierter Version und Konfiguration bereitstellen.
- Datenbank und gegebenenfalls Binärdaten aus der Sicherung wiederherstellen.
- Den gesicherten Verschlüsselungsschlüssel über den vorgesehenen Secret-Weg einbinden.
- Start, Datenbankverbindung und Readiness prüfen.
- Einen ungefährlichen Test-Workflow mit kontrollierten Testdaten ausführen.
- Credentials, Webhooks, Zeitpläne und Fehlerpfade stichprobenartig prüfen.
- Dauer, Abweichungen und manuelle Schritte dokumentieren.
- Festhalten, welche Daten seit dem Sicherungszeitpunkt fehlen würden.
RPO und RTO helfen bei der Planung: Das Recovery Point Objective beschreibt, wie viel Datenverlust zeitlich akzeptabel wäre; das Recovery Time Objective beschreibt die angestrebte Wiederanlaufzeit. Beide Werte müssen aus dem konkreten Prozess kommen. Für einen täglichen Bericht gelten andere Anforderungen als für einen Workflow, der laufend Kundenanfragen verteilt.
Monitoring: Erreichbar ist nicht gleich betriebsbereit
n8n stellt für den Betrieb mehrere Endpunkte bereit. /healthz zeigt, ob die Instanz erreichbar ist, sagt laut offizieller Dokumentation aber nichts über den Datenbankstatus. /healthz/readiness berücksichtigt, ob die Datenbank verbunden und migriert ist. Der detailliertere /metrics-Endpunkt ist bei Self-Hosting verfügbar, muss jedoch aktiviert werden Quelle 2.
Ein sinnvolles Monitoring kombiniert mehrere Ebenen:
- Instanz: Erreichbarkeit und Readiness der n8n-Anwendung.
- Infrastruktur: CPU, Arbeitsspeicher, Speicherplatz, Datenbank und gegebenenfalls Redis.
- Workflow: fehlgeschlagene und ungewöhnlich lange Ausführungen, Warteschlangen und Wiederholungen.
- Geschäftsprozess: kommt das erwartete Ergebnis im Zielsystem an?
- Alarmweg: wer erhält welche Meldung und bis wann muss reagiert werden?
Ein HTTP-200-Check allein erkennt nicht, ob ein Connector keine Berechtigung mehr hat, ein Tariflimit erreicht ist oder ein Zielsystem Daten ablehnt. Für wichtige Abläufe empfiehlt sich deshalb zusätzlich ein kontrollierter End-to-End-Test mit Testdaten oder einem ungefährlichen Prüfsignal.
Ausführungsdaten bewusst begrenzen
Je nach Ausführungsvolumen kann die n8n-Datenbank stark wachsen. n8n empfiehlt, nicht benötigte Ausführungsdaten nicht dauerhaft zu speichern und alte Daten über Pruning zu begrenzen Quelle 6. Die Entscheidung ist ein Ausgleich: Für Fehlersuche und Nachvollziehbarkeit werden Informationen benötigt, gleichzeitig können Protokolle personenbezogene oder vertrauliche Inhalte enthalten.
Vor dem Start sollten deshalb vier Fragen beantwortet sein: Welche erfolgreichen Ausführungen müssen gespeichert werden? Welche Fehlerdaten werden für die Analyse benötigt? Wann werden Daten gelöscht? Wer darf Protokolle und Payloads sehen?
Updates ohne Blindflug
Die offizielle n8n-Dokumentation empfiehlt regelmäßige Aktualisierungen und einen vorherigen Test Quelle 3. Ein belastbarer Update-Ablauf kann so aussehen:
- Release Notes und mögliche Breaking Changes lesen.
- Aktuelle Sicherung erstellen und deren Status prüfen.
- Update in einer vergleichbaren Testumgebung einspielen.
- Kritische Workflows und Credentials mit Testdaten prüfen.
- Wartungsfenster und Verantwortliche festlegen.
- Produktiv aktualisieren und Readiness sowie Kernworkflows prüfen.
- Rückfallweg und Ergebnis dokumentieren.
Community Nodes, eigene Code-Schritte und externe APIs brauchen besondere Aufmerksamkeit. Auch wenn n8n selbst startet, kann eine Abhängigkeit ihr Verhalten geändert haben.
Wann Queue Mode sinnvoll wird
Queue Mode trennt die Annahme von Workflow-Ereignissen von der Ausführung durch Worker. n8n nutzt dafür eine Hauptinstanz, Redis als Warteschlange, Worker und eine gemeinsame Datenbank; der Verschlüsselungsschlüssel muss zwischen den beteiligten Instanzen übereinstimmen. Ein verteiltes Setup über SQLite und dateisystembasierte Binärdatenspeicherung werden in diesem Modus nicht unterstützt Quelle 5, Quelle 8. Das kann Skalierung und Lastverteilung unterstützen, erhöht aber die Zahl der Komponenten, die überwacht, gesichert und aktualisiert werden müssen.
Für einen kleinen Workflow-Bestand ist Queue Mode nicht automatisch die bessere Architektur. Die Entscheidung sollte an gemessener Last, Parallelität, Verfügbarkeitsziel und Betriebsfähigkeit hängen, nicht am Wunsch nach einem möglichst komplexen Setup.
Sicherheitsprüfung und Rechte
n8n bietet einen Security Audit über CLI, API oder den n8n-Node. Der Bericht kann unter anderem Risiken bei Credentials, Datenbankzugriffen, Dateisystem-Nodes, Community Nodes und Instanzeinstellungen sichtbar machen Quelle 7. Er ersetzt keine vollständige Sicherheitsprüfung, ist aber ein sinnvoller Baustein für wiederkehrende Kontrollen.
Zusätzlich sollten Credentials nach dem Minimalprinzip vergeben werden: nur die Systeme, Aktionen und Daten, die der Workflow tatsächlich benötigt. Zugänge brauchen benannte Eigentümer, einen Rotationsweg und eine dokumentierte Sperrmöglichkeit.
Betriebscheckliste für KMU
Vor dem produktiven Start sollten diese Punkte geklärt und dokumentiert sein:
- Betreiber, technische Verantwortung und Eskalationskontakt sind benannt.
- Datenbank, Binärdatenmodus und Speicherorte sind dokumentiert.
- Verschlüsselungsschlüssel und Secrets werden getrennt und geschützt verwaltet.
- Backup-Umfang, Intervall und Aufbewahrung passen zum Prozess.
- Ein Restore wurde in einer isolierten Umgebung praktisch getestet.
- RPO und RTO sind für den Geschäftsprozess festgelegt.
- Health, Readiness, Infrastruktur und Workflow-Fehler werden überwacht.
- Alarmierung hat Empfänger, Priorität und Reaktionsweg.
- Ausführungsdaten und Protokolle haben eine begründete Löschfrist.
- Updates werden geprüft, getestet und mit Rückfallweg eingespielt.
- Drittsysteme, API-Limits und manuelle Fallbacks sind dokumentiert.
- Ein kontrollierter End-to-End-Test prüft den tatsächlichen Prozess.
n8n-Betrieb für Unternehmen in Gera, Jena und Thüringen
Akuma Digital hat seinen Unternehmenssitz in Gera und begleitet Unternehmen in Gera, Jena, Thüringen und deutschlandweit. Die regionale Nähe ändert nichts an den technischen Anforderungen: Auch ein lokaler Workflow braucht klare Zuständigkeiten, Wiederherstellung und einen nachvollziehbaren Fehlerweg.
Für den kommerziellen Einstieg bündelt die Seite zur n8n-Automatisierung und Workflow-Entwicklung Beratung, Umsetzung und Betrieb. Regionale Projektwege finden Sie unter Prozessautomatisierung in Gera und Prozessautomatisierung in Jena. Was der heutige manuelle Ablauf kostet, lässt sich vorab mit dem Prozesskosten-Rechner anhand eigener Werte überschlagen.
Grenzen des Leitfadens
Die passende Architektur lässt sich nicht allein aus der Zahl der Workflows ableiten. Datenarten, Ausführungsvolumen, Verfügbarkeitsanforderungen, Schnittstellen, Teamkenntnisse und interne Vorgaben verändern den Entwurf. Dieser Leitfaden ist eine technische Orientierung, kein Sicherheitszertifikat und keine Datenschutz- oder Rechtsberatung.
Ein seriöses Angebot setzt deshalb eine Bestandsaufnahme voraus: Welche Prozesse sind kritisch, welche Systeme sind beteiligt, welche Daten fließen und wer übernimmt den Betrieb? Erst daraus entstehen ein sinnvoller Scope und überprüfbare Abnahmekriterien.
Häufige Fragen
Was muss bei n8n Self-Hosting gesichert werden?
Der genaue Umfang hängt vom Setup ab. Datenbank, Verschlüsselungsschlüssel und der gewählte Binärdatenmodus müssen gemeinsam betrachtet werden Quelle 1, Quelle 8. Workflow- und Credential-Exporte der CLI können ein Baustein sein, ersetzen aber keinen getesteten Restore der gesamten Betriebsumgebung Quelle 9.
Reicht ein Datenbank-Backup für n8n?
Nicht zwingend. Ohne den zugehörigen Verschlüsselungsschlüssel können gespeicherte Credentials nach einer Wiederherstellung unbrauchbar sein Quelle 1. Je nach Binärdatenmodus und Infrastruktur gehören außerdem Dateien oder ein gemeinsamer externer Speicher zum Restore Quelle 8.
Wie überwacht man eine selbst gehostete n8n-Instanz?
Die offizielle Dokumentation unterscheidet Erreichbarkeit über /healthz, Betriebsbereitschaft mit Datenbankprüfung über /healthz/readiness und detailliertere Metriken über /metrics. Zusätzlich sollten Workflow-Fehler, Infrastruktur und ein geschäftlicher End-to-End-Test überwacht werden Quelle 2.
Wie oft sollte n8n aktualisiert werden?
Es gibt kein für jedes Unternehmen identisches Wartungsfenster. n8n empfiehlt regelmäßige Updates und einen vorherigen Test. Release Notes, Backup, Testumgebung, Kernworkflow-Prüfung und Rückfallweg gehören in die eigene Update-Routine Quelle 3.
Wann braucht n8n Queue Mode?
Queue Mode kann bei gemessener Parallelität oder Skalierungsbedarf sinnvoll sein. Er ergänzt jedoch Hauptinstanz, Redis, Worker und gemeinsame Datenbank und erhöht damit den Betriebsaufwand. Für kleine Installationen ist er nicht automatisch erforderlich Quelle 5.
Ist n8n Self-Hosting automatisch DSGVO-konform?
Nein. Self-Hosting verändert die Kontrolle über die n8n-Instanz, bewertet aber nicht automatisch alle Datenflüsse. Angebundene CRM-, E-Mail-, KI- oder Buchhaltungssysteme, Verträge, Speicherorte, Löschfristen, Berechtigungen und Rechtsgrundlagen müssen für das konkrete Setup geprüft werden.