Hey!
Im currently using Node-RED for automations and am considering migrating to n8n. I have custom nodes built, e.g. with node red api - some of them are written in .js/.html and some of them are sub flows. They all are packed in a nom package. I know we can create Custom nodes in n8n in TypeScript so I don’t think it’ll be a problem for the nodes that are in JS/HTML but what about nodes that are sub flows, is there a specific way of migrating them to n8n subworkflows? Some of them are complex, some of them are http requests basically etc. I am wondering if there’s an option similar to the one in Node-RED to have them all in an nom package or I should have an npm package for nodes migrated to TS and then nodes that are sub flows would be pulled into n8n instances via source control ? N8n plan → Enterprise if we decide to migrate.
And another topic, do u think there’s a way of quickly migrating the nodes/workflows from node-red to n8n without doing it manually ?
I really appreciate your help! Thanks!
Hi @oesterreicher-0417 , welcome to n8n community!
I’ve done a few migrations from Node‑RED to n8n and the mapping that works best in practice is:
– custom JS/HTML nodes → n8n custom nodes (TypeScript, shipped as an npm package)
– subflows → n8n sub‑workflows, managed as normal workflows and versioned via Git/source control rather than npm.
For the subflows: in n8n I’d create one workflow per “building block”, start it with an Execute Sub‑workflow Trigger, and call it from other flows with Execute Sub‑workflow. That gives you almost the same reusability you have in Node‑RED, but with clearer input/output contracts.
There isn’t an automated Node‑RED → n8n converter that I’m aware of, so the fastest approach I’ve seen is to:
-
port the low‑level API logic into 1 custom node package,
-
rebuild your high‑value subflows as sub‑workflows,
-
then re‑implement individual flows on top of those new building blocks.
If you’re open to sharing a small example subflow/custom node, happy to show what the 1:1 n8n equivalent would look like before you commit to the whole migration.
Thanks a lot! @nguyenthieutoan When it comes to sub-workflows I was also considering using web hook triggers for some of them and execute by another workflow triggers for other, depending on the functionality. Login building block would use a web hook for example, sql query would use when executed by another workflow trigger. The real question is the versioning (npm packages are easy of course - I’m talking about BBs that are subflows) and distribution mechanisms across n8n instances. As for custom nodes, I assume we would have a private repo on GitHub (and rpm package) with all custom nodes in one package I guess and the CI/CD pipeline would bake them into n8n’s docker images and push these images to AWS ECR for instance and then we would use ArgoCD to distribute them across pods.
Do u have any suggestions on how it would look when it comes to these node-red nodes as subworkflows ?
Thanks! It makes a lot more sense now to me, will definitely consider these
Welcome to the n8n community @Michal_12312312
This document will help you Sub-workflow conversion | n8n Docs
You’ll need to manually adjust the input/output types in the Start and Return nodes; there is limited support for AI and functions like first(), last(), and all() may need review after conversion.
And I assume it is possible to connect your n8n account/instance? To GitHub repo with subworjflows and it will pull them into n8n? It’s only available on Enterprise plan and admin account type, right? @nguyenthieutoan @tamy.santos
And is there a way to not use ArgoCD for instance? Can’t subworjflows be packaged as nodes like in nodered? What would be the best way to distribute them across instances (subworfklows that has when executed by another workflow trigger)?
Thanks in advance!
Michal, mostly yes, but not quite “Enterprise only”: n8n source control is a Business/Enterprise feature and the connection is owner/admin-configured. Treat it as workflow/environment sync, not as a package manager for sub-workflows.
For distribution, split the pieces: custom nodes for code you want versioned and installed across instances; sub-workflows for orchestration that teams may edit in n8n. The key detail is instance shape: is this one shared n8n instance with projects, or separate customer/team instances that all need the same block versions kept in sync?
We haven’t made that decision yet. Most likely, each developer would have his own instance on which he/she would develop flows.
If each developer has a separate instance, the risk is version drift. Don’t treat sub-workflows as the shared library; they’ll become local copies once people start editing them.
Keep reusable code in custom nodes, and make workflow/sub-workflow promotion explicit: dev instance → reviewed export/source-control change → shared staging/prod. Do approved flows eventually land in one central instance, or does every developer keep their own copy?
@oesterreicher-0417 to answer your question directly: yes, n8n can connect to a GitHub repo, but that’s the Source Control feature (Business/Enterprise) and it’s designed for syncing workflows between environments (dev → staging → prod), not as a package manager.
For distributing sub-workflows across instances without ArgoCD, the lightest approach I’ve used is exporting the sub-workflow JSON via the n8n API (GET /api/v1/workflows/{id}) and importing it into each target instance with a small script or a dedicated n8n workflow that calls POST /api/v1/workflows on each instance. You still version the JSON in Git, but the “deployment” is just an API call instead of a GitOps pipeline.
The key constraint @olmrqs_ops already flagged is right: once people edit a sub-workflow locally, it drifts. I’d lock the shared sub-workflow to read-only access on dev instances if you can, or at least enforce a naming convention like [SHARED] - WorkflowName so the team knows not to edit it in place.