16 Apr 2026 · 5 min read
Everyone argues about Node-RED's editor. The file is the point.
node-red · integration · edge · architecture · ot · mqtt · open-source
Somewhere in your plant, a Node-RED instance is doing something important. It moves production counts into a database, or drags a stubborn Modbus device into MQTT, or sends a report nobody has questioned in two years.
One person set it up. It has been running fine.
The question in the back of your mind is whether that's a problem. Not whether Node-RED works — it's been working. Whether you built something real, or a liability that happens to be running.
What it actually is
Plenty of good control engineers have never opened it. Here it is in one paragraph.
You open Node-RED in a browser. You drag small boxes onto a canvas and draw wires between them. Each box does one job: read a Modbus register, scale the number, check a limit, publish to MQTT. A message goes in at the left and travels along the wires. Each box can change it, then passes it on. You press Deploy and it runs until you stop it.
ONE FLOW · READ A FLOWMETER, SCALE IT, PUBLISH IT
If you have ever drawn a function block diagram in a PLC, you already know this. Same idea — blocks wired together, left to right — pointed at moving data rather than at controlling a process.
That's the whole model. If it looks familiar, it should — anyone who has drawn a function block diagram already thinks this way. Boxes, wires, one job each. Node-RED points that same idea at moving data instead of controlling a process.
What it replaced
Every plant has an integration tier, whether anyone calls it that or not. It sits between the control system and everything that wants its data — the ERP, the historian, the quality database, the monthly return.
Before Node-RED it looked like this:
THE INTEGRATION TIER · WHAT IT LOOKED LIKE BEFORE
- The scheduled taska VB script on a Windows box, run by a user account nobody can identify
- The spreadsheetan Excel macro someone opens every Monday to make the report happen
- The servicea bespoke C# Windows service; source last seen on a laptop that was replaced
- The vendor connectorlicensed per tag, per protocol, renewed annually, does one thing
- The database joba stored procedure with business logic in it, discovered during an outage
Five artefacts, five failure modes, five people who used to understand them. Each was reasonable the day it was written. None of them can be reviewed.
Each one was sensible when it was written. Together they became a problem: five things to fix, five places to look, five people who have left.
It speaks everything
One instance handles the protocols in your plant and the systems above it, in the same flow.
ONE RUNTIME · EVERY PROTOCOL IN YOUR PLANT
The alternative is not one good tool. It is a different vendor’s connector for each line on the left, each with its own licence and its own service to keep alive.
It's also small. It runs on a Raspberry Pi, a fanless panel PC, or a container on something you already own. Some vendors now ship it as a supported feature — Opto 22's groov EPIC and groov RIO include it, and Siemens' IOT2050 runs it. That matters more than it sounds. It's the difference between a tool one engineer likes and a tool your OEM will discuss on a support call.
Now the actual point
Everyone argues about the canvas. The canvas is just a picture of a file.
What sits on disk is flows.json — plain text listing every box, every wire,
every setting. The editor draws it. It isn't the thing, any more than a P&ID is
the piping.
That matters because text can go in git. Node-RED has this built in, and once your integration logic is in a repository you get four things you never had:
- Review — a second person sees the change before it runs
- History — who changed that scaling, and when
- Rebuild — the dead edge node comes back from the repo, not from a backup and a prayer
- Fleet — twenty sites updated by editing one file
AUTHORED IN PLACE · click Deploy
- CHANGE HAPPENS · in a browser, on the live instance
- REVIEWED BY · nobody
- RECORDED AS · nothing — the previous version is gone
- ROLLBACK · remember what it was and retype it
- TWENTY SITES · twenty sessions, and site 14 gets missed
MANAGED AS A FILE · same editor
- CHANGE HAPPENS · in the editor, then committed as a file
- REVIEWED BY · a second person, before it runs
- RECORDED AS · a commit — who, when, what, why
- ROLLBACK · check out the previous commit, restart
- TWENTY SITES · one merge, one pipeline, all twenty
Nobody has to stop using the visual editor. Build the flow by dragging boxes, then ship it through review. The editor becomes a drawing tool. The file becomes the truth.
That's the strongest case for Node-RED in a plant, and it's rarely the one you hear. It isn't a beginner's tool professionals put up with. It's the only common piece of plant integration whose logic is text you can read.
Where it breaks
Now the other half. I'd rather tell you than let you find out on a Tuesday.
WHERE IT BREAKS · FOUR TO MANAGE, ONE TO OBEY
Two people can't edit one flow
The file lists nodes in machine order, with generated IDs and canvas positions. Move a box and the file changes. Two edits at once make a mess no human can untangle.
GIVE EACH FLOW ONE OWNER
The Deploy button is a back door
Open the browser, change a thing, click Deploy. That is the whole appeal, and it undoes every reason you put the flow in git.
MAKE PRODUCTION EDITORS READ-ONLY
Everything shares one thread
One slow function node stalls every other flow on that instance. The symptom is 'it all went slow at once'.
KEEP FUNCTION NODES SMALL
Logins are thin
Basic passwords and not much else. No real roles, no approval step, no audit trail your compliance officer would accept.
ADD A LAYER, OR ADD PROCESS
It is not a control layer
No deterministic scan, no watchdog, no real-time guarantee. Brilliant for watching a process. Wrong for closing a loop, interlocking a motor, or anything with a safety case.
THIS ONE IS NOT A JUDGEMENT CALL
The last card is the one to take seriously. Everything else on that list is something you manage with a bit of discipline. That one isn't.
Where it belongs
WHERE NODE-RED BELONGS IN THE STACK
consumers of plant data — fine — but it isn't the only option
protocol translation, buffering, routing, transformation — this is the job
supervision, alarming, operator interface — adjacent — talk to it, don't replace it
deterministic scan, interlocks, SIL loops — never
The bottom row is the only one that is not a judgement call. Reading from the control layer is the whole point; writing to it deserves a rate limit and an owner.
Read simply: Node-RED lives in the integration tier. Reading from the control layer is the whole job. Writing back to it needs a rate limit and a named owner.
The gap has a company in it
Look at those five cards again and most of them say the same thing. Node-RED runs one instance beautifully and says nothing about running four hundred.
That's what FlowFuse is for. The interesting part is who built it: Nick O'Leary, who co-created Node-RED at IBM, started it in 2021, with Zeger-Jan van de Weg joining as CEO in 2022. The project's own author built the commercial layer. Nobody arrived afterwards to monetise something popular.
NODE-RED · APACHE 2.0, OPENJS FOUNDATION
yours, permanently, at no cost
- The runtime and the editor
- Every protocol node — Modbus, OPC UA, S7, MQTT
- Flows as JSON on disk
- Projects — git built in
- Basic auth on the editor
FLOWFUSE · OPEN CORE, PAID TIERS
the operational layer, when one instance becomes four hundred
- Roles — who edits vs who only watches
- SSO against your directory
- DevOps pipelines — dev → test → production
- Snapshots and one-click rollback
- Fleet view across hundreds of remote instances
It's open-core, so be clear-eyed. The governance features are the paid ones. But look at where the line falls — everything that moves plant data is on the left. If you walk away from FlowFuse later you lose process, not production. That is a much better trade than industrial software usually offers.
And nobody can take it away
This is the part almost nobody checks, and it matters most.
Node-RED is Apache 2.0. The copyright sits with the OpenJS Foundation — not a vendor, not a startup, not whoever buys that startup. IBM built it in 2013 and gave it to the foundation world in 2016. There is no licence server, no seat count, and no company able to reprice the thing your integration tier stands on.
Read that next to what happened to VMware. The lesson there wasn't about hypervisors. It was that the quiet layers under a plant are supplier relationships, and suppliers change hands. So ask it of everything: if this company were bought tomorrow, what could the new owner do to me?
For Node-RED the answer is: not much. FlowFuse could change its pricing tomorrow and your flows would keep running, because the runtime isn't theirs.
The short version
Node-RED, currently on 4.1 with a 5.0 on the roadmap, got two things right that most industrial software gets wrong. Its logic is a file you can read. And its licence is held by a foundation, not a vendor.
Neither shows up in a demo. Both decide whether the thing is still maintainable in ten years.
So it's worth asking of everything else in your plant. Where does the logic live, can somebody else read it — and who owns the terms it runs on?
Running Node-RED somewhere important? I'd like to hear what broke and what didn't. Reply by email.
Keep reading
