Self-Hosted zu Cloud: Wann der Wechsel bei n8n sinnvoll ist

Der Wechsel von einer selbst gehosteten n8n-Instanz zur n8n Cloud lohnt sich vor allem dann, wenn der Aufwand für Server, Updates und Backups den Nutzen einer vollständig kontrollierten Umgebung übersteigt. Dabei wandert allerdings nicht alles automatisch mit: Unverifizierte Community-Nodes und selbst gebaute Nodes laufen laut n8n-Dokumentation nur self-hosted, Ausführungen sind je nach Cloud-Tarif zahlenmäßig gedeckelt, und Zugangsdaten müssen nach dem Umzug manuell neu angelegt werden, weil exportierte Workflow-Dateien nur Namen und IDs von Credentials enthalten, nicht deren Werte. Wer diese Punkte vorher kennt, vermeidet böse Überraschungen nach der Migration. Stand: Juli 2026.

Wann sich der Wechsel zur Cloud lohnt

Bei self-hosted n8n tragen Sie laut n8n selbst die volle Verantwortung: Sie stellen die Infrastruktur bereit, verwalten sie und sind für Updates, Sicherheitspatches und Backups zuständig. Die n8n Cloud kehrt dieses Verhältnis um. Sie ist laut der offiziellen Übersicht zu den Nutzungsoptionen vollständig verwaltet, ein Setup ist nicht nötig, und n8n übernimmt Wartung und Betrieb. Für Teams ohne eigene IT-Kapazität oder mit wenig Zeit für Serverpflege ist das ein echter Vorteil. Der Preis dafür: Sie geben einen Teil der Kontrolle ab, die Sie sich beim Self-Hosting bewusst erarbeitet haben, und zahlen ein laufendes Abo statt reiner Infrastrukturkosten.

Was beim Umzug nicht automatisch mitkommt

Der größte Unterschied betrifft Nodes. Auf der n8n Cloud lassen sich laut Dokumentation zur Installation von Community-Nodes nur verifizierte Community-Nodes über das Node-Panel installieren. Unverifizierte Nodes und die Installation über npm sind ausschließlich self-hosted möglich. Wer also eigene oder seltene Nodes im Einsatz hat, muss vor dem Umzug prüfen, ob diese Nodes verifiziert sind, denn sonst fallen sie in der Cloud ersatzlos weg.

• Nodes: Nur verifizierte Community-Nodes laufen in der Cloud, npm-Installationen und selbst gebaute Nodes bleiben self-hosted.
• Zugangsdaten: Exportierte Workflow-JSONs enthalten laut Export- und Import-Dokumentation nur Namen und IDs von Credentials, nicht deren Werte. Nach dem Import müssen Sie alle Zugangsdaten manuell neu hinterlegen.
• Konfiguration: Feinsteuerung über Umgebungsvariablen, die self-hosted die Basis der Konfiguration bildet, ist in der Cloud nur eingeschränkt möglich, da die Instanz verwaltet wird.

Ausführungslimits und Ressourcen im Vergleich

Self-hosted ist die Zahl der Ausführungen praktisch nur durch Ihre eigene Serverhardware begrenzt. In der Cloud gelten feste Kontingente je Tarif. Der Starter-Tarif umfasst laut n8n-Preisliste 2.500 Ausführungen im Monat bei 5 gleichzeitigen Läufen, der Pro-Tarif 10.000 Ausführungen bei 20 gleichzeitigen Läufen, der Business-Tarif 40.000 Ausführungen sowie zusätzlich SSO, SAML, LDAP und Git-basierte Umgebungen. Auch die Speicherung der Ausführungsprotokolle ist gedeckelt: Nach Angaben im Cloud-Datenmanagement speichert der Starter-Tarif maximal 2.500 Ausführungen mit 7 Tagen Aufbewahrung, Pro bis zu 25.000 mit 30 Tagen, Enterprise bis zu 50.000 mit unbegrenzter Aufbewahrung. Ab 85 Prozent Speicherauslastung kann n8n ältere Ausführungsdaten automatisch bereinigen. Auch der Arbeitsspeicher ist gestaffelt, von 320 MiB im Starter- und Testtarif bis 4.096 MiB in Enterprise, während Sie sich self-hosted die Servergröße selbst aussuchen.

Was für die Migration konkret zu tun ist

Workflows lassen sich als JSON exportieren und in die Cloud-Instanz importieren. Bevor Sie das tun, lohnt sich eine kurze Bestandsaufnahme: Welche Nodes sind im Einsatz, und sind alle davon in der Cloud als verifiziert gelistet. Danach werden die Credentials in der neuen Umgebung von Hand angelegt, da die exportierten Dateien wie beschrieben keine Geheimnisse enthalten. Wer bisher über Umgebungsvariablen oder eigene Datenbankeinstellungen gearbeitet hat, sollte diese Konfiguration vor dem Umzug dokumentieren, weil sie in der verwalteten Cloud-Umgebung nicht in gleicher Form existiert. Für Teams, die den Umzug technisch sauber und mit klarer Priorisierung planen wollen, bietet sich eine n8n-Beratung an, die vorab prüft, welche Workflows unverändert laufen und wo Anpassungen nötig sind.

Häufige Fragen zu Self-Hosted zu Cloud Migration bei n8n

Laufen alle self-hosted Workflows unverändert in der Cloud?

Nur wenn alle verwendeten Nodes zu den verifizierten Community-Nodes zählen oder n8n-Standardnodes sind. Workflows mit unverifizierten oder selbst gebauten Nodes müssen vor dem Umzug angepasst oder ersetzt werden, weil diese laut n8n-Dokumentation in der Cloud nicht installierbar sind.

Was passiert mit meinen Zugangsdaten beim Umzug?

Sie müssen neu angelegt werden. Der Workflow-Export enthält nur Namen und IDs der Credentials, keine Passwörter, Tokens oder Schlüssel. Das ist aus Sicherheitssicht sinnvoll, bedeutet aber manuellen Aufwand nach dem Import.

Kann ich später wieder zurück auf Self-Hosted wechseln?

Grundsätzlich lassen sich Workflows wieder exportieren und in eine self-hosted Instanz importieren. Cloud-spezifische Einschränkungen fallen dann weg, dafür übernehmen Sie wieder die volle Verantwortung für Betrieb, Updates und Backups.

Wie viele Ausführungen sind im günstigsten Cloud-Tarif enthalten?

Der Starter-Tarif bietet laut aktueller Preisliste 2.500 Ausführungen im Monat bei maximal 5 gleichzeitigen Läufen. Wer mehr braucht, muss auf Pro oder Business wechseln oder bleibt self-hosted, wo die Grenze von der eigenen Serverhardware abhängt.