Hey!
Ich nutze derzeit Node-RED für Automationen und überlege, zu n8n zu migrieren. Ich habe Custom Building Blocks gebaut, z.B. mit der Node Red API - einige sind in .js/.html geschrieben und einige sind Sub-Flows. Sie sind alle in einem npm-Paket verpackt. Ich weiß, dass wir Custom Nodes in n8n in TypeScript erstellen können, also denke ich nicht, dass es ein Problem für die Nodes in JS/HTML sein wird, aber was ist mit Nodes, die Sub-Flows sind? Gibt es eine spezifische Möglichkeit, sie zu n8n Subworkflows zu migrieren? Einige davon sind komplex, manche sind im Grunde nur HTTP-Anfragen usw. Ich frage mich, ob es eine ähnliche Option wie in Node-RED gibt, um sie alle in einem npm-Paket zu haben, oder ob ich ein npm-Paket für Nodes haben sollte, die zu TS migriert wurden, und dann würden Nodes, die Sub-Flows sind, über Versionskontrolle in n8n-Instanzen eingezogen werden? N8n-Plan → Enterprise, falls wir uns zur Migration entschließen.
Und noch ein anderes Thema: Denkst du, es gibt eine Möglichkeit, die Nodes/Workflows schnell von Node-RED zu n8n zu migrieren, ohne es manuell zu tun?
Ich schätze deine Hilfe sehr! Danke!
Hallo @Michal_12312312, willkommen in der n8n Community!
Ich habe schon ein paar Migrationen von Node‑RED zu n8n gemacht und die Zuordnung, die in der Praxis am besten funktioniert, ist:
– benutzerdefinierte JS/HTML-Knoten -
Nodes (TypeScript, versandt als npm-Paket)
– Subflows -
n8n-Sub‑Workflows, verwaltet als normale Workflows und versioniert über Git/Versionskontrolle statt npm.
Für die Subflows: In n8n würde ich pro „Baustein
Danke dir! @nguyenthieutoan Bezüglich Sub-Workflows habe ich auch überlegt, Web-Hook-Trigger für einige von ihnen zu verwenden und sie durch andere Workflow-Trigger auszuführen, je nach Funktionalität. Der Login Building Block würde zum Beispiel einen Web-Hook verwenden, die SQL-Abfrage würde bei der Ausführung durch einen anderen Workflow-Trigger verwendet werden. Die eigentliche Frage ist die Versionierung (npm-Pakete sind natürlich einfach – ich spreche von BBs, die Sub-Flows sind) und die Verteilungsmechanismen über n8n-Instanzen. Bei benutzerdefinierten Knoten gehe ich davon aus, dass wir ein privates Repository auf GitHub (und rpm-Paket) mit allen benutzerdefinierten Knoten in einem Paket hätten, und die CI/CD-Pipeline würde diese in n8n’s Docker-Images einbinden und diese Images zum Beispiel zu AWS ECR pushen, und dann würden wir ArgoCD verwenden, um sie über Pods zu verteilen.
Hast du irgendwelche Vorschläge, wie das aussehen würde, wenn es um diese node-red-Knoten als Sub-Workflows geht?
Danke! Das ist jetzt für mich viel verständlicher, werde diese Punkte definitiv berücksichtigen
Willkommen in der n8n-Community @Michal_12312312
dieses Dokument wird dir helfen Sub-workflow conversion | n8n Docs
Du musst die Ein-/Ausgabetypen in den Knoten Start und Return manuell anpassen; die Unterstützung für KI ist begrenzt und Funktionen wie first( ), last( ) und all( ) müssen möglicherweise nach der Konvertierung überprüft werden.
Und ich nehme an, es ist möglich, dein n8n-Konto/deine Instanz mit einem GitHub-Repo mit Subworkflows zu verbinden und diese werden in n8n eingezogen? Das ist nur im Enterprise-Plan und beim Admin-Kontotyp verfügbar, richtig? @nguyenthieutoan @tamy.santos
Und gibt es eine Möglichkeit, ArgoCD nicht zu nutzen? Können Subworkflows nicht wie in Node-RED als Nodes verpackt werden? Was wäre der beste Weg, um sie über Instanzen zu verteilen (Subworkflows, die durch die Ausführung eines anderen Workflows ausgelöst werden)?
Danke schon mal im Voraus!
Michal, meistens ja, aber nicht ganz „nur Enterprise-Version
Wir haben diese Entscheidung noch nicht getroffen. Höchstwahrscheinlich würde jeder Entwickler seine eigene Instanz haben, auf der er/sie Flows entwickeln würde.
Wenn jedes Entwicklerteam eine separate Instanz hat, besteht das Risiko von Version Drift. Behandle Sub-Workflows nicht als gemeinsame Bibliothek; sie werden zu lokalen Kopien, sobald Leute anfangen, sie zu bearbeiten.
Halte wiederverwendbaren Code in benutzerdefinierten Knoten, und mache die Workflow-/Sub-Workflow-Promotion explizit: dev instance → überprüfter Export/Source-Control-Änderung → gemeinsames Staging/Prod. Landen genehmigte Flows schließlich in einer zentralen Instanz, oder behält jeder Entwickler seine eigene Kopie?
@oesterreicher-0417 um deine Frage direkt zu beantworten: ja, n8n kann sich mit einem GitHub-Repository verbinden, aber das ist das Source Control Feature (Business/Enterprise) und es ist dafür ausgelegt, Workflows zwischen Umgebungen zu synchronisieren (dev → staging → prod), nicht als Package Manager.
Für die Verteilung von Sub-Workflows über Instanzen hinweg ohne ArgoCD ist der leichteste Ansatz, den ich verwendet habe, das Exportieren des Sub-Workflow JSON über die n8n API (GET /api/v1/workflows/{id}) und das Importieren in jede Zielinstanz mit einem kleinen Script oder einem dedizierten n8n Workflow, der POST /api/v1/workflows auf jeder Instanz aufruft. Du versionierst das JSON immer noch in Git, aber das “Deployment” ist einfach nur ein API-Aufruf statt einer GitOps-Pipeline.
Die wichtige Einschränkung, die @olmrqs_ops bereits erwähnt hat, ist richtig: Sobald Leute einen Sub-Workflow lokal bearbeiten, driftet er ab. Ich würde den gemeinsamen Sub-Workflow auf Dev-Instanzen auf Lesezugriff sperren, wenn möglich, oder zumindest eine Namenskonvention wie [SHARED] - WorkflowName durchsetzen, damit das Team weiß, nicht es nicht direkt zu bearbeiten.