N8n vs. node-red
daniel-payne-keldan-systems.medium.com
daniel-payne-keldan-systems.medium.com
https://github.com/node-red/node-red/blob/master/LICENSE
https://docs.n8n.io/sustainable-use-license/
We previously looked into integrating n8n but they wanted $50k for a commercial license, which didn’t make sense for us.
The licenses may or may not be an issue depending if you are using it as is, locally, and to what extent.
The clause is if you're substantially using n8n for your solution. As long as it's partial (which it almost always is)... it's another thing.
Anyone who tries to use one workflow tool exclusively (n8n, node-red) almost always ends up needing to add other tools around it to do what n8n, node-red can't do well. For example handling more than direct AI calls.
n8n is more of a business process tool long before AI came out, and it's useful AI functionality is an addition, not the core source of the product. I see their license in terms of that since they are a more detailed competitor to zapier.
In the beginning using it for personal or small workloads helps keep costs down. When you start making money you need a supported production instance, either you're paying as an owner yourself to do it, or there is the hosted version.
Self hosting traditionally has been for enterprise, but I think startups doing it could be reflected in licenses in the future too.
node-red is great too, but is a slightly different tool.
That’s not true at all. This is the relevant part of the license:
> You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes.
It has absolutely nothing to do with substantial vs partial, it has to do with commercial vs non-commercial and internal vs external.
> In the beginning using it for personal or small workloads helps keep costs down.
If you use it for small workloads and charge money for users to do that, you will be in breach of the license. Do not do this. It doesn’t matter how big or small the workload is.
> Self hosting traditionally has been for enterprise, but I think startups doing it could be reflected in licenses in the future too.
They explicitly switched to this license because they wanted to restrict commercial use. We were a startup and they quoted us $50k for a commercial license. There’s no need to speculate about this. This is not an oversight. This is what they deliberately chose.
1. "OR" allows 3 use cases
- internal business purposes (which is commercial behind the scenes),
- non-commercial (this reads to me like if there's customer facing access to n8n, etc),
- personal use (home lab, learning, hobby projects, etc).
For me, the internal business purposes is the first and main reason I would look at it, where n8n is a tool among other tools in the stack all being used for some of their functionality.
From: "Limitations / You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. "
https://github.com/n8n-io/n8n/blob/master/LICENSE.md
2. Substantial - This feels like skinning n8n to make a product is meant to prevent. If there's an existing business solving their issues and either it's not substantially n8n, and the n8n part isn't a product, service, or module being sold, it could be OK.
This reads like if the complex functionality of your solution is being executed in connected systems external to n8n that it helps route through, the weighing of substantial is clearly outside.
"Our license restricts use to "internal business purposes".
In practice this means all use is allowed unless you are selling a product, service, or module in which the value derives entirely or substantially from n8n functionality. "
---
Small workloads - You are correct in if it was an n8n process being packed and sold, even at small workloads, it could be a licensing issue. Conversely, if the small workload wasn't a process being sold to users.
Commercial quoting - Makes sense, again. If I want to write a workflow in n8n and just skin it, i'm substantially using their software. To me, n8n can't do everything I need so I can't imagine a scenario where that I'd hit that, but absolutely other use cases could. Additionally, the commercial license seems to be for enterprise customers - maybe an option for small business/startup (headcount, or revenue) could be available. Seems reasonable enough, and have seen it with other tools.
If substantial n8n use generated that kind of profit, I'd be happily paying for it to make sure it sticks around and is supported. It's like having an entire n8n dev team to keep n8n running for less than the cost of a developer. But I'm not there.
For me, it's rare that I would rely solely on one tool that heavily. Having base inputs (especially for AI) in text form and feeding it up so different layers could be refactored to other tools over time (such as n8n's orchestration), there can be scenarios where the work is already substantially outside of n8n. At the same time, I look at tools like n8n for what they can do, using them as is, out of the box only, and not modifying them at all, because it then can receive updates.
---
It’s not. We wanted to incorporate n8n into our product. It would represent a small, non-essential part of our product. We weren't just skinning and reselling n8n as a product itself. But our users would be directly using an n8n instance hosted by us in a commercial context. I reached out to n8n and was told directly by them that the free license does not allow this and it required a $50k commercial license.
You seem to keep steering the discussion towards “they don’t really mean that”. Yes, they do. These are not unintentional restrictions. They wanted to make these restrictions so they could charge for commercial licenses, so that’s what they did. There is nothing hidden between the lines. There is nothing to figure out. Those are the restrictions.
As ever, I think each has its strengths and weaknesses, but I know which one I prefer...
In terms of 'out of the box' experience, I do agree there is space for some improved Node-RED nodes to support some of these workflows. There certainly are nodes in the community to help, but there's space for more. And that's an area I think gives Node-RED an advantage; the open source nature that allows anyone to build in the gaps of what's already there. Node-RED provides plenty of low-level building blocks to connect with pretty much anything - but having higher level abstraction nodes is needed to make it more accessible.
It's also an area we're looking at in my day job (FlowFuse CTO) where we provide a commercial platform built around Node-RED.
As a hack, I have got LangGraph working inside of a node-red flow. I will write it up as a medium article in the next few days, as it might be of help to others. It's very codey.
I think production engineers will have to master the Langchain ecosystem, when we creating mission critical AI based systems. I think node-red has good nodes in place to record decisions and data as part of an AI ethics program.
Flowise have a good set of nodes around langchain, but I bet it was a massive and expensive undertaking to build.
Also Dashboard 2 is something n8n is sorely missing and is needed to monotor live systems.
However, there is something you mention that I think is important - dashboard 2 is still missing critical functionality—for instance, I cannot set it up as the “/“ (homepage) URL in an instance (there’s a lingering bug for that for around a year now) and it is still far from being as well integrated as the original.
The bit I want to surface in this thread is that there is actually a lot that can be done with sub-flows and custom functions alone (even without added third-party modules) - I built my own library of AI/“agentic” subflows with raw HTTP request nodes and a simple convention for passing LLM context in payloads so I’m a bit biased here, but overall I find Node-RED superior in the amount of control I have over how data is handled.
(Also, I am running Node-RED in bun rather than NodeJS and it is way more efficient, although that means I can’t rely on some third-party nodes, but that is another story)
What does it mean by "n8n" lacks a UI? All it has is a UI, what use cases does the UI not handle? The writing is very poor and does not make sense at all.
However I have updated the article so it is much clearer, the UI that is missing from n8n is not WISIWIG, but a management dashboard, to be viewed once the system is live. I have added the following:
"To be clear here, I did not mean the UI that you use to create flows with, both systems are drag and drop flow creators. The issues I come across is visualizing what is going on inside of a system once it is created and up and running."
Sorry, I should have made myself clearer, I did not mean the UI that you use to create flows with, both systems are drag and drop flow creators. The issues I come across is visualizing what is going on inside of a system once it is created and up and running. I normally would like to have a dashboard showing me what is going on inside of a system. The node-red comes with Dashboard 2 ( a vue based set of components) for displaying whats going on in a live system. But I could not find a similar tool for n8n.
But then n8n has things I am missing from node-red, especially wrappers around LangGraph. I have to code those manually, in a node-red function node and it's not a simple task :(
It's a question that comes up often from low/no-code creators.
It’s used so consistently that I’m not sure if it’s just careless editing or if it’s something new I don’t know about.
The article made me check node-red so it did provided something valuable.
I see n8n as more of “citizen developer” tool (less flexibility, more built-in integrations) and Node-RED as an engineering scratchpad where you can literally build anything you want (for instance, it’s been part of my home automation setup for ages, way before Home Assistant became a thing).
I wouldn’t run _any_ of them as part of an enterprise solution, though. Security, IAM/RBAC, auditability and even general reliability would keep me up at night (even considering that Node-RED runs a surprising amount of small scale on-premises industrial automation, that’s typically in isolated networks, so I’m not factoring those in).
My personal, and my I say biased, opinion is that these tools do not deliver on the agentic promise. AI agents require a completely different approach.
I am curious what is a good tool to build agents these days? I am checking out mastra, someone at the cafe told me about Inngest.. wondering what would you use?
https://www.anthropic.com/engineering/building-effective-age...
https://github.com/dbos-inc/dbos-demo-apps/tree/main/python
DBOS is an open source library that doesn’t require an external server.
Think of that what you will but it seems some of them make a profit off of it.
So, it must work somewhat?
What is the completely different approach you are suggesting?
I know that vibe coding isn't quite there yet, but I wonder if low-code solutions like those are really saving any time at this point. What's the advantage if not velocity?
But I think it depends on how many built in integrations there are? As if you have a battle tested integration already in place may save writing a script/api.
Also junior devs could be allocated on to it.
In my limited testing, I found n8n to be heavily focused on cloud API use, from their onboarding quick tutorial to the collection of provided nodes, I found adapting them to strictly local use something of a chore.
https://docs.n8n.io/sustainable-use-license/#what-is-and-isn...
For production use, it will cost money one way or another.
I know both make for excellent all purpose digital glue but would think that’s last resort
AI native but doesn't feel production ready, I've kept encountering random bugs. I still use it over n8n for prototyping LLM pipelines quick
That's a choice. With (at least) Ollama, you can set the temperature parameter so the results will be deterministic based upon the seed value. Which you can set.
It's used for things like running test cases, but there are likely other uses too.
The thing I was trying to say (not very well) was AI is going to make mistakes.
When we had systems based on relational databases, it was possible to recreate the conditions where the mistake was made. But in a world of LLMs and rapidly changing graph databases, this is almost impossible. So we should be recording everything so we don't make the same mistake twice.
Someone said to me yesterday, "The best doctors have only killed one person." Apparently, it's a common saying in UK healthcare. But it illustrates the point.
I currently work for a bank that is hot on AI ethics; I initially thought it was a bit of HR hype. But as I come to understand the inner workings of these systems, I am thoroughly convinced "recording how decisions are made is just as important as the decisions themselves."
https://github.com/activepieces/activepieces https://github.com/kestra-io/kestra
We used Node-Red at a previous job for integrating some third party software, total disaster, from upgrading, using JSON for code reviews, to overall performance.
Its a fun toy, leave it at that.
But unfortunately it's not very clear what shortcomings of Node-Red were a problem for you.
Could you rephrase your experience, focusing on what you believe Node-Red does wrong?
Once you start to get big and complicated with node-red you will have this issue. But the rest of node-red is fantastic. It also covers a fix for git code reviews and integration with external testing frameworks.
--------------------------------------------------------
I hope this can help anybody having the same issues as I have when writing long functions in node-red editor.
Coding anything over 50 lines become difficult to work with, or trying to view multiple functions at the same time. The rest of node-red is fantastic!
----------------------------------------------------
2. Often times you end up writing code to help support node-red, you must avoid this at all costs because you end up shifting more and more into code bases, making node-red pointless.
2. Lots of sub menu "advanced" functions that you will need to use for any complex flow.
3. Observability is poor out of the box, especially if you use a service like datadog or NewRelic, we ended up using a catch all error handler that just shipped events to NewRelic.
4. Poor out of box defaults for security, mainly authentication
5. Conflict resolution sucks, you have to JSON stable stringify the changes to ensure you can deal with conflicts and conduct proper code reviews.
That's all useful feedback to us. There's always a balance to be had between putting lots of code in Function nodes and the visual complexity of doing the equivalent in pure nodes. Part of that is understanding where users are falling back to JS in a Function node - and what could the core nodes provide to avoid that necessity.
Code reviews are a common piece of feedback and something we need to help with.
In the day job (FlowFuse CTO) we're looking at how to improve the overall developer UX of Node-RED - both within node-red, but also how you manage it within a team and at scale.
If you had any more feedback on your experiences, would love to hear it.
It fixes this problem, and also fixes a problem of integrating with test tools and code coverage tools.
It's the old 80/20 rule, 80% can be done very quickly with easy to configure out of the box nodes, but it's the last 20% of functionality that takes all the time.
Dropping out to vs-code for this 20% improved my productivity a lot.
TBH I don't know how I would do a code review with n8n, i will need to do more investigation.
https://github.com/daniel-payne/functions-templates-manager
https://discourse.nodered.org/t/node-red-and-vs-code-integra...