n8n Cloud oder Self-Hosting

n8n Cloud oder Self-Hosting

0:00 Selbst hosten heißt nicht, n8n zu installieren. Die Installation ist an einem Nachmittag erledigt, mit Docker sogar schneller. Selbst hosten heißt, n8n zu betreiben — mit Sicherung, Aktualisierung, Bereitschaft und einem Menschen, der sich zuständig fühlt. Diese Unterscheidung ist der Kern dieses Moduls. Wir haben die Entscheidung im ersten Modul kurz gestreift; jetzt, nach fünf Tagen, können Sie sie viel besser treffen — denn Sie wissen inzwischen, was alles an dieser Instanz hängt.

n8n Cloud oder Self-Hosting

0:30 Wir bleiben am sechsten Tag. Zuerst die Entscheidung selbst — mit den Kriterien, die die Dokumentation dafür anbietet. Dann die Installation mit Docker und die vier Dinge, die vor dem ersten Start feststehen müssen. Danach Sicherung und Wiederherstellung, und zwar mit Betonung auf dem zweiten Teil. Und zum Schluss die Aktualisierung — insbesondere der Sprung auf n8n 2.0, der kein gewöhnliches Update ist.

Die Entscheidung

0:55 Fangen wir mit der Wahl an. Zwei Fragen, und die zweite hängt an der ersten — so zerlegt es die Dokumentation, und das ist eine brauchbare Struktur. Erstens: Betreibt n8n die Infrastruktur, oder tut das Ihr eigenes Haus? Zweitens: Welcher Plan beziehungsweise welche Edition bringt die benötigten Funktionen mit? Und dann ein Satz, der in Diskussionen hilft: Beide Wege sind für den produktiven Einsatz vorgesehen. Es gibt hier also kein Profi-Lager und kein Anfänger-Lager.

1:25 Das ist wichtig, weil die Debatte gern moralisch geführt wird — als sei Selbst- hosting das Ernsthaftere. Ist es nicht. Es ist eine andere Verteilung von Kontrolle und Aufwand, und welche passt, entscheidet Ihre Lage. Fünf Situationen aus der Dokumentation, und man sieht die Logik sofort: Alles, was mit Schnelligkeit und fehlenden Technikressourcen zu tun hat, führt zur Cloud.

1:49 Alles, was mit Kontrolle und Anpassung zu tun hat, führt zum Selbsthosting. Die letzte Zeile ist die ehrlichste: Wer n8n kostenlos betreiben will, hostet selbst, mit der Community Edition. Das ist ein legitimer Grund — nur sollte man dabei wissen, dass die Kosten nicht verschwinden, sondern die Form wechseln. Und die Fußzeile räumt mit einem verbreiteten Irrtum auf: Enterprise-Funktionen gibt es auf beiden Wegen.

2:13 Vier Punkte, und drei davon sind Arbeit. Installation und Konfiguration liegen im eigenen Haus. Wartung, Aktualisierung und Skalierung ebenfalls. Der Verschlüsselungsschlüssel und die Sicherung sind eigene Verantwortung — und nach dem letzten Modul wissen Sie, was daran hängt. Und dann der vierte Punkt, der für viele Häuser den Ausschlag gibt: Dafür entscheiden Sie selbst, wo die Daten liegen und wann aktualisiert wird. Gerade das Wann ist unterschätzt.

2:41 In der Cloud aktualisiert n8n nach Ihrem eingestellten Takt; selbst gehostet entscheiden Sie es vollständig. Der erste Punkt ist die Rechnung, die nicht aufgeht: Selbst gehostet wird wegen der Kosten, und der Betriebsaufwand kommt obendrauf. Rechnen Sie ehrlich — mit Arbeitszeit. Der zweite ist der verschenkte Gewinn aus Modul eins: Die Community Edition wird betrieben, ohne sie zu registrieren.

3:05 Der dritte ist ein Planungsfehler: Ein Enterprise-Merkmal wird eingeplant, das die Edition nicht hat; prüfen Sie das vor dem Entwurf, nicht danach. Und der vierte ist der, der im Ernstfall zählt: Niemand ist benannt, der die Instanz im Störungsfall betreut.

Installation mit Docker

3:21 Jetzt zur Installation. Und der Titel führt bewusst etwas in die Irre: Der Betrieb beginnt nicht beim Container-Start, sondern bei vier Entscheidungen, die davor fallen müssen. Vier Punkte. Wo liegt die Datenbank, und wie wird sie gesichert? Unter welcher öffentlichen Adresse sind Webhooks erreichbar — das ist die Produktions-URL aus Modul vier, jetzt als Betriebsfrage.

3:43 Welcher Verschlüsselungsschlüssel gilt, und wo wird er aufbewahrt? Und welche Zeitzone führt die Instanz — sonst gilt New York, der Stolperstein aus Modul zwei. Sie sehen: Alle vier sind uns in diesem Seminar schon begegnet, und alle vier sind später mühsam zu ändern. Deshalb gehören sie an den Anfang. Fünf Schritte, und der fünfte ist eine Mahnung. Legen Sie die Datenbank fest und lagern Sie sie dauerhaft — nicht im Container, sonst ist sie beim nächsten Neustart weg.

4:13 Setzen Sie den Verschlüsselungsschlüssel und sichern Sie ihn getrennt. Stellen Sie einen Reverse Proxy mit TLS davor und konfigurieren Sie die öffentliche Webhook-Adresse. Setzen Sie die Umgebungsvariablen für Zeitzone, Bausteine und Sicherheit bewusst — inklusive des SSRF-Schutzes aus dem letzten Modul. Und erst danach legen Sie den ersten Workflow an. Ein praktischer Hinweis: Sensible Werte lassen sich aus einer Datei lesen statt aus der Variable.

4:40 Der erste Punkt ist der teuerste: Der Schlüssel liegt nur im Container und ist beim Neuaufbau verloren. Damit sind alle Credentials unbrauchbar, und Sie richten jede Anbindung neu ein. Der zweite ist der häufigste Anfangsfehler: Die Webhook-Adresse zeigt auf localhost, und die Gegenseite erreicht nichts. Der dritte ist der Reverse-Proxy-Fall, den wir bei MCP schon hatten — er entfernt Header, die n8n braucht.

5:04 Und der vierte ist die vergessene Persistenz: Die Datenbank liegt im Container-Dateisystem und verschwindet mit ihm.

Sichern und wiederherstellen

5:12 Kommen wir zur Sicherung. Und zur wichtigsten Regel dabei: Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung. Sie ist eine Vermutung. Vier Bestandteile, und der zweite wird am häufigsten vergessen. Die Datenbank mit Workflows, Credentials, Ausführungen und Data Tables. Der Verschlüsselungsschlüssel — ohne ihn sind die verschlüsselten Credentials unbrauchbar; das ist die zentrale Erkenntnis des letzten Moduls.

5:39 Die Umgebungsvariablen und die Konfiguration des Reverse Proxy; auch die sind Teil Ihres Systems, auch wenn sie woanders liegen. Und Binärdaten, sofern sie außerhalb der Datenbank abgelegt sind. Prüfen Sie diese Liste gegen Ihr tatsächliches Sicherungskonzept — oft fehlen zwei davon. Fünf Schritte, und einer davon ist eine Sicherheitsmaßnahme, an die man nicht sofort denkt. Setzen Sie eine zweite Umgebung auf, getrennt von der produktiven.

6:06 Spielen Sie Sicherung und Schlüssel dort ein. Prüfen Sie, ob Credentials entschlüsselt werden und Workflows starten. Und jetzt der wichtige vierte Schritt: Passen Sie die Webhook-Adressen der Testumgebung an, damit nichts nach außen wirkt. Ohne das löst Ihre Wiederherstellung echte Vorgänge in angebundenen Systemen aus — Sie spielen eine Sicherung ein und lösen damit hundert Bestellungen aus.

6:29 Und zuletzt: Messen Sie die benötigte Zeit. Der erste Punkt ist der Klassiker: Gesichert wird die Datenbank, aber nicht der Schlüssel. Der zweite ist der eben beschriebene Unfall: Die Wiederherstellung startet die Workflows und ruft echte Systeme auf. Der dritte ist eine Selbsttäuschung mit System: Die Sicherung läuft, aber niemand prüft, ob sie lesbar ist — ein grünes Häkchen im Backup-Werkzeug ist keine Prüfung.

6:53 Und der vierte betrifft die Planung: Die Wiederherstellungszeit ist unbekannt und wird im Ernstfall geschätzt. Dann steht der Betrieb, und niemand kann sagen, wie lange noch.

Updates und Migration auf 2.x

7:03 Zum Abschluss die Aktualisierung. Und der Sprung auf 2.0 verdient besondere Aufmerksamkeit, denn er ist kein Patch — er bringt Brüche mit, die Bestand betreffen. Der Migrationsbericht zeigt, wie viele Ihrer Workflows mit n8n 2.0 kompatibel sind, und ordnet die Befunde nach Schweregrad. Critical heißt: vor dem Umstieg beheben, sonst scheitern Workflows. Medium heißt: mögliche Nebenwirkungen. Low heißt: Abkündigung ohne Bruch.

7:31 Das ist eine sehr brauchbare Aufbereitung — Sie bekommen keine Liste von Änderungen, sondern eine Liste Ihrer betroffenen Workflows. Einsehbar ist der Bericht nur für globale Admins. Und mein Rat: Öffnen Sie ihn, bevor Sie den Termin planen, nicht danach. Fünf Brüche, und die erste Zeile ist die, die ein Projekt aufhalten kann: MySQL und MariaDB werden nicht mehr unterstützt — wer sie einsetzt, muss vorher auf PostgreSQL oder SQLite wechseln.

8:01 Das ist keine Nachmittagsarbeit. Pyodide entfällt, Python-Skripte müssen auf natives Python umgestellt werden; das kennen Sie aus Modul acht. Der Start-Baustein entfällt. Binärdaten im Speicher entfallen — Sie wählen Dateisystem, Datenbank oder S3. Und Aktivieren heißt jetzt Veröffentlichen. Die Fußzeile nennt noch vier ganz entfallene Bausteine, weil die dahinterliegenden Dienste eingestellt wurden.

8:27 Vier Voreinstellungen, die sich mit n8n 2 gedreht haben. Task Runner sind nun standardmäßig eingeschaltet — das ist die Grundlage für natives Python. Der Zugriff auf Umgebungsvariablen im Code-Baustein ist standardmäßig gesperrt; das ist ein Sicherheitsgewinn und zugleich ein möglicher Bruch, wenn ein Skript darauf zugreift.

8:46 Execute Command und Local File Trigger sind abgeschaltet. Und in der Cloud steuern Release-Track, Aktualisierungstakt und Wartungsfenster den Zeitpunkt — dort können Sie also wählen, ob Sie früh oder erprobt fahren wollen. Der erste Punkt ist der vermeidbarste: Aktualisiert wird, ohne den Migrationsbericht geöffnet zu haben.

9:05 Der zweite ist der Datenbankfall, und er ist schmerzhaft: Die Datenbank ist MySQL, und das fällt erst beim Start der neuen Version auf. Der dritte ist eine Folge der neuen Voreinstellung: Ein Code-Baustein liest eine Umgebungsvariable, die nun gesperrt ist. Und der vierte ist eine Entscheidung, die man bewusst treffen sollte: In der Cloud steht der Track auf Beta, obwohl der Prozess geschäftskritisch ist.

9:29 Für kritische Lasten empfiehlt n8n ausdrücklich Stable.

Übung

9:33 Jetzt schreiben Sie auf, was den Betrieb von Kesselwerk trägt. Kein Aufbau, sondern eine Checkliste — und die ist im Ernstfall mehr wert als jede Konfiguration. Kesselwerk betreibt die Produktionsinstanz selbst, auf einem eigenen Server hinter einem Reverse Proxy. Der Störungsmelder ist von außen erreichbar, die Fachdatenbank liegt im eigenen Netz.

9:54 Das ist eine typische mittelständische Aufstellung — und sie enthält alle Zutaten, die wir besprochen haben: öffentliche Webhook-Adresse, interner Dienst, eigener Betrieb. Und jetzt steht der Sprung auf die nächste Hauptversion an. Das ist der Moment, in dem sich zeigt, ob der Betrieb aufgeschrieben ist oder nur gelebt wird.

10:13 Das Lernziel: die Betriebspflichten einer selbst gehosteten Instanz vollständig benennen und in eine prüfbare Liste bringen. Vollständig und prüfbar — beides. Erfolgreich sind Sie, wenn die Checkliste Persistenz, Schlüssel, Webhook-Adresse, Sicherung und Wiederherstellung abdeckt und der Versionssprung Testlauf, Abbruchkriterium und Rückweg hat.

10:33 Wer früh fertig ist, ergänzt, was sich ändert, wenn dieselbe Instanz in die Cloud zöge. Das ist eine gute Übung, weil sie sichtbar macht, welche Punkte Ihrer Liste Betriebsaufwand sind — und welche bleiben, egal wo Sie hosten. Fünfzig Minuten, fünf Schritte. Listen Sie die Bestandteile einer vollständigen Sicherung auf — die vier von vorhin, und prüfen Sie, ob Ihnen noch etwas einfällt.

10:57 Beschreiben Sie den Wiederherstellungsweg samt Anpassung der Webhook-Adressen. Halten Sie den Ablauf des Versionssprungs in Schritten fest. Ordnen Sie den Migrationsbericht in diesen Ablauf ein — an welcher Stelle wird er geöffnet? Und benennen Sie Abbruchkriterium und Rückweg. Schreiben Sie es wirklich auf; eine Checkliste im Kopf ist nachts um drei nicht verfügbar.

11:19 Vier Fallen. Erstens, und es ist der Klassiker dieses Moduls: Die Liste nennt „Datenbank sichern", aber nicht den Verschlüsselungsschlüssel. Zweitens: Der Testlauf findet auf derselben Maschine statt — dann testen Sie nicht die Wiederherstellung, sondern das Kopieren. Drittens: Das Abbruchkriterium lautet „wenn es nicht läuft"; das ist kein Kriterium, sondern eine Stimmung. Formulieren Sie etwas Prüfbares — eine Zeit, eine Fehlerzahl.

11:46 Und viertens: Die Checkliste entsteht, wird aber nicht datiert und nie wieder angefasst. Setzen Sie ein Datum darunter und einen Termin in den Kalender.