Node-RED: a low-code runtime for event-driven applications

What Node-RED is for, and who ends up using it

Node-RED describes itself as low-code programming for event-driven applications. The unit of work is a flow: a graph of nodes connected by wires, edited in a browser, where each node receives a message object, does something to it, and passes it on. That model suits problems where the hard part is not the algorithm but the plumbing. A temperature reading arrives on an MQTT topic, gets scaled, is compared against a threshold, triggers an HTTP POST, and updates a gauge on a dashboard. In a general-purpose language that is four libraries and a scheduler. In Node-RED it is four nodes and three wires.

The people who get the most out of it are not usually application developers. They are engineers who own a device or a process and need a small amount of logic attached to it: someone instrumenting a building, someone bridging a PLC to a database, someone who wants their home automation to react to a sensor without writing a service. The JavaScript function node exists for the cases where the built-in nodes run out, but a flow that is mostly function nodes has given up the reason to use Node-RED at all.

The project is a project of the OpenJS Foundation and is licensed under Apache-2.0. It is written in JavaScript and runs on Node.js, which is the constraint that shapes everything else: if your target device cannot run a current Node.js runtime, Node-RED is not the tool for that device.

How a flow actually runs: messages, the runtime and the editor

The repository is a monorepo. The top level holds the build scripts, the test directory, and a packages directory where the runtime and the editor client live as separate packages. The start script points at packages/node_modules/node-red/red.js, which is the process you launch. That process serves two things on the same port: the runtime that executes flows, and the editor that lets you build them.

Data moves as messages. A node emits a JavaScript object, conventionally with a payload property, and every node downstream sees that object. Nodes can also hold state across messages, which is how a delay node or a rate limiter works. The runtime keeps the deployed flow in memory and persists it, so a restart does not lose the graph.

The editor is a client-side application. When you click deploy, the editor sends the flow definition to the runtime, which swaps in the new version. That is the mechanism behind the project's central trade-off: the running system and the thing you edit are the same system. There is no compile step between the graph you see and the code that executes, which makes iteration fast and makes it easy to change production by accident.

Installing Node-RED with npm and running a first flow

The README gives a three-step quick start. The install is global, and the unsafe-perm flag is there because the install runs lifecycle scripts as part of fetching dependencies.

sudo npm install -g --unsafe-perm node-red
node-red

After the second command the process logs its startup and begins listening. Open http://localhost:1880 in a browser and the editor loads. The README points at https://nodered.org/docs/getting-started/ for the full instructions, and notes that more documentation lives at https://nodered.org/docs, with a forum at discourse.nodered.org and a Slack workspace linked from the site.

If you would rather run the code from git, the README documents that path as well: clone the repository, run npm ci to install dependencies, npm run build to build, and npm start to run.

git clone https://github.com/node-red/node-red.git
cd node-red
npm ci
npm run build
npm start

For a first flow, drag an inject node and a debug node onto the canvas and wire them together. The inject node fires a message on demand; the debug node prints the message to the sidebar panel. Deploy, then click the inject button. A message object appears in the debug pane, which confirms the runtime is executing the graph. From there the useful next step is an MQTT input node pointed at a broker, because that is the shape most real Node-RED work takes.

Where Node-RED breaks down

The most common complaint is the one the design invites: a flow is a program, but it is stored as JSON and edited in a browser. You can put a flow under version control, and the project ships a flows file, but a diff of that file is a diff of node positions and property objects. Reviewing a change to a function node means reading a string inside a JSON blob. Teams that require pull requests on logic changes will find this uncomfortable, and there is no way to make the editor give you a normal source file.

Error handling is the second weak point. Nodes have a catch mechanism and a status indicator, but a failing branch can be silent for a long time if nobody wired a catch node to it. In a service you would get a stack trace in a log aggregator; here you get a red triangle on a node in a browser tab that nobody has open.

Scaling is the third. The runtime is a single Node.js process holding the flow graph. Running several copies means each copy has its own state, so any node that accumulates data behaves differently across instances. For a single edge device or a small internal service this does not matter. For a system that needs horizontal scaling with shared state, Node-RED is the wrong layer, and the correct move is to keep the flow as an edge adapter and put the stateful logic behind an API.

Node-RED compared with n8n

The comparison people search for is node red vs n8n, and the difference is in what each one assumes about the runtime. Node-RED runs on Node.js and embeds a JavaScript function node, so the escape hatch from the visual layer is code that shares the process and can reach anything the runtime can reach. n8n is also a visual workflow tool, but it is oriented toward integrating SaaS APIs and running as a hosted or self-hosted service with a database backing it.

The practical consequence is where each one feels natural. If your inputs are MQTT topics, serial ports, GPIO pins and local network devices, Node-RED's node set and its single-process model fit the shape of the problem. If your inputs are webhooks from third-party services and your outputs are records in a workflow queue, a tool built around that pattern will need less custom work. Neither is a strict upgrade of the other, and the choice usually follows from whether the system lives at the edge or in the cloud.

Maintenance, releases and what the licence covers

The repository is not archived and the last push was on 2026-09-18, three days before this was written. Recent releases include 4.1.15 and 5.0.7, both labelled maintenance releases, plus 5.0.6 shortly before. The presence of a 4.1.x line alongside 5.0.x means there is more than one supported branch, so the first upgrade question is which line you are on rather than whether a newer version exists.

The package.json at the repository root carries version 5.0.7, which is the monorepo version rather than necessarily the version of the package you installed from npm. The test script runs build, verify-deps, lint and coverage in sequence, and there are separate targets for core tests and node tests. That is a reasonable signal about how changes are validated, but it says nothing about whether the custom nodes you depend on are tested at all. Custom nodes come from the Node-RED Library at flows.nodered.org, and each one is a separate npm package with its own maintenance status. A flow is only as maintainable as its least maintained node.

On licensing: the project is under Apache-2.0, which permits commercial use and modification and includes a patent grant. That covers the core. It does not automatically cover every node you install from the library, since those are separate packages under their own licences. Checking the licence of each custom node before shipping is a normal dependency review, not a Node-RED-specific problem.

Editorial conclusion

Adopt Node-RED when the problem is glue: reading an MQTT topic, transforming a payload, calling an HTTP endpoint, and pushing a value to a dashboard. Skip it when the logic needs typed interfaces, code review at the function level, or a build pipeline that treats each service as a versioned artifact, because flows are edited in a browser and stored as JSON rather than compiled. Before committing, verify three things: that the runtime version you install matches the release line you intend to support, that the npm packages for any custom nodes are present and maintained, and that your deployment stores flows somewhere you can diff and restore. The project itself is a project of the OpenJS Foundation under Apache-2.0, so the licence question is settled; the operational question is not.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. node-red/node-red on GitHub
3. Project website
4. README
5. Releases