Wer n8n selbst betreibt und mit npm installiert hat, kann nicht einfach auf Version 3 aktualisieren. In den Breaking Changes zu 3.0 schreibt n8n, dass Self-Hosting ein Docker-basiertes Deployment verlangt. Ein lauffähiges npm-Paket gibt es mit 3.0 nicht mehr. Wer schon mit Docker betreibt, muss nichts wechseln. Alle anderen brauchen einen Umzug, bevor sie das nächste grosse Update machen können.

Ich habe mein n8n am 22. September in einen Container gezogen. Das sind 42 Workflows, davon 32 produktiv, darunter tägliche Video- und Bildpipelines. Hier steht, wo der Aufwand wirklich lag und worauf du bei deinem Team achten solltest.

Die Workflows sind selten das Problem

Bevor ich irgendetwas am Server angefasst habe, habe ich alle 42 Workflows gegen die Liste der Änderungen in 3.0 geprüft. n8n bringt dafür einen eigenen Migration Report mit. Das Ergebnis: Kein einziger Workflow war betroffen.

Kaputt geht beim Umzug nicht die Logik, sondern die Umgebung. Zwölf meiner Workflows rufen Programme auf, die auf dem Server installiert sind, etwa für Video- und Bildbearbeitung. Auf einem normalen Server ist das unsichtbar, weil die Programme einfach da sind. Im Container fehlt jedes einzelne davon.

Das offizielle Image ist bewusst abgespeckt

n8n liefert sein Docker-Image gehärtet aus, also auf das Nötigste reduziert und ohne die Möglichkeit, nachträglich Software zu installieren. Aus Sicherheitssicht ist das richtig. Für jeden, der in seinen Workflows mehr macht als API-Aufrufe, heisst das aber: Ein eigenes Image muss her.

Das habe ich gebaut, und es hat seinen Preis. Das Image ist ein Viertel grösser, und ein Teil der Härtung ist wieder aufgehoben. Sauberer wäre ein eigener Dienst für die Bildbearbeitung, den n8n übers Netz aufruft. Dafür hätte ich zwölf Workflows umbauen müssen, deshalb habe ich das bewusst verschoben. Das ist eine Architekturentscheidung, die du mit deinem Team treffen solltest, bevor ihr baut, und nicht danach.

Dazu kommt Pflegeaufwand. Bei jedem n8n-Update muss jemand prüfen, ob das eigene Image noch zur neuen Basis passt.

Erst umziehen, dann aktualisieren

Der wichtigste Entscheid war, Umzug und Update zu trennen. Ich bin mit genau der Version in den Container gezogen, die vorher lief. So blieb die Datenbank unverändert, und der Weg zurück war jederzeit offen. Das Rollback-Skript lag bereit, bevor die alte Installation entfernt wurde.

Ein Update auf eine neue Version verändert die Datenbank dagegen dauerhaft. Danach kommt man nur über ein Backup zurück. Wer Umzug und Update an einem Tag macht, verdoppelt das Risiko und hat keinen sauberen Rückweg.

Eine Falle betrifft jedes Monitoring: Der Health-Check von n8n meldet grün, lange bevor die Workflows tatsächlich laufen. Gemessen habe ich 17 Sekunden bis zum grünen Health-Check und rund eine Minute, bis alle Workflows aktiv waren. Wer sich auf den Health-Check verlässt, meldet zu früh Erfolg.

Was 3.0 sonst noch ändert

Einige Standardwerte ändern sich mit 3.0, und mindestens einer davon kann produktive Abläufe stoppen. Die maximale Laufzeit eines Code-Schritts sinkt von fünf Minuten auf eine. Meine Video-Renderings dauern länger und wären reihenweise abgebrochen. Ich habe den alten Wert deshalb vorab fest eingestellt. Zwei weitere Umstellungen habe ich ebenfalls noch unter Version 2 erledigt, damit das eigentliche Update nur noch das Update ist.

Wie Updates jetzt laufen

Seit dem Umzug habe ich dreimal aktualisiert, immer nach demselben Ablauf:

  1. Backup ziehen, inklusive des Schlüssels, mit dem n8n alle gespeicherten Zugangsdaten verschlüsselt. Ohne diesen Schlüssel ist das Backup wertlos, und liegt das Backup auf demselben Server, ist es keins.
  2. Prüfen, ob das eigene Image zur neuen n8n-Version passt.
  3. Bauen und testen, ausserhalb der Produktion. Dabei teste ich, ob die Werkzeuge ihre Arbeit wirklich erledigen, und nicht nur, ob sie starten.
  4. Ausrollen.
  5. Aufräumen. Die vorherige Version bleibt, bis die ersten geplanten Läufe auf der neuen durch sind.

Ein Update ist damit kein Projekt mehr, sondern ein Ablauf, den jeder im Team wiederholen kann.

Fünf Fragen an dein Team

  • Läuft unser n8n über npm oder schon in Docker?
  • Hat jemand den Migration Report geöffnet, und was meldet er?
  • Welche Programme rufen unsere Workflows auf, die im offiziellen Image fehlen?
  • Ziehen wir zuerst um und aktualisieren erst danach?
  • Haben wir ein Backup mit Schlüssel, das nicht auf demselben Server liegt?

Wenn du dabei Unterstützung willst, buch unten einen Termin.