What's new in Node-RED 5, and what to check before you upgrade?

Node-RED dropped version 5 this week, the biggest change to the editor in the project's history.

A quick reminder of what we're talking about. Node-RED is the open-source, low-code tool many of our customers use to connect machines, sensors and systems on the floor. FlowFuse is built by the core team behind Node-RED and designed for scalable  production: the same Node-RED engine underneath, wrapped in the management, version control and access you need once you run it across sites. Version 5 is a release of Node-RED itself, so it lands everywhere, whether you run it standalone or through FlowFuse.

We run both at customers every day, and on more than twenty instances in our own demo factory in Ghent, so this is a release we looked at closely. This one is mainly focused on the people who work with the tool day to day, small tweaks to improve productivity. For us, that is a sign of maturity in the product. There is a way developers like to put it: make it work, make it fast, make it pretty. Version 5 is the project arriving at that third step.

‍

What changed in the editor

Most of the editor changes pull in the same direction: less time fighting the tool, more time on the actual flow.

The sidebars, the panels on either side of the editor, now behave the same on both sides, and you can split one to keep two panels open at once. That lets you keep your debug output and your node configuration in view together, with fewer clicks between the thing you are building and the thing telling you whether it works.

‍

‍

There is a new Explorer panel, a structured overview of all your flows and nodes. It starts to matter once a project has grown across dozens of tabs and several developers. That makes a large project easier to navigate, and easier to hand over to a colleague who didn't build it.

Node-RED now ships with a dark theme in the core build in. For teams running long development sessions, a readable interface out of the box is a practical improvement rather than a cosmetic one.

‍

‍

Smaller changes that add up in Node-RED 5

A few smaller additions are the ones engineers tend to notice first.

Node documentation is now one click away in the workspace. A node with extra documentation shows a small badge you click to read it, instead of digging through menus. It makes documentation easier to reach and easier to write, often the first thing that gets skipped under time pressure.

‍

‍

The text formatting in the editor, used in node help, comments and info text, now supports the highlighted Important and Warning callouts you may know from GitHub, so notes read more clearly.

The Delay node, which controls the rate at which messages pass through, gained a burst mode: it lets messages through as they arrive until a limit is reached, then holds them until the next interval. That opens up handling patterns that were awkward to build before.

‍

A note on the debug pause button  and a limitation worth knowing

The debug panel is where messages scroll past while a flow runs, often too fast to read. Version 5 adds a pause button in its header. While paused, the panel holds still so you can read what came through, and it shows how many new messages arrived in the meantime.

There is a catch. Those new messages are counted and then dropped. So the moment you pause to study something, the data arriving during the pause is gone, and if the thing you wanted to inspect is in there, you cannot get them back.

This is the kind of detail that surfaces when you run a tool in production, not just in development. We raised it with FlowFuse directly as a feature request: buffer the paused messages rather than discard them, so they can still be inspected afterwards. It's on their radar.

‍

What it means if you run Node-RED in production: Four things to check

1. Node.js version

Version 5 requires Node.js 22.9 or later. Check what's running on each machine before you upgrade Node-RED.

2. 32-bit ARM devices

Version 5 drops support for 32-bit ARM. In practice, this means Raspberry Pi 3B and earlier will not run it. Most modern setups are unaffected, but check any older edge devices.

3. Third-party nodes

Flows and built-in nodes carry over cleanly from older versions. The thing to check is the community nodes you've added yourself. Those depend on their own Node.js compatibility. Run through your installed palette and confirm each one supports Node.js 22+.

4. Remote instances don't self-update

This is the most important point if you run Node-RED on the floor.

FlowFuse-hosted instances (managed in the cloud) upgrade automatically. Remote instances, the ones running on your own hardware, do not. Most production setups are remote instances. So that needs a plan.

Someone has to schedule the migration, verify Node.js versions, check the third-party nodes, and test before rolling it out. That's not a reason not to upgrade. The release is solid and the changes are worth having, but it doesn't happen on its own.

‍

Should you upgrade to Node-RED 5?

For most setups, yes. The editor improvements are real, the flows carry over cleanly, and Node-RED 5 flows remain compatible with older instances, so you're not locked into a one-way move.

The work is in the preparation: Node.js version, older devices, and third-party nodes. If you're running more than a handful of remote instances, that preparation is worth doing carefully rather than quickly.

If you want to know what the upgrade looks like for your specific setup, or you'd rather have us handling it, get in touch.

Practical lessons from manufacturing sites: when standalone Node-RED is enough and when you need FlowFuse

‍

‍

Many factories start with Node-RED and do great. One use case, one engineer, one site — it just works. Then a year passes. A second site gets added. A third engineer joins the team. A compliance audit lands on the desk. And suddenly, things get messy.

At Mayker, we work with both every day. We're not selling either product, we're integrators who need to make it work on the factory floor. After dozens of implementations, we've developed a clear sense of when standalone Node-RED is enough, and when FlowFuse becomes the better choice.

This is what we've learned.

‍

What does Node-RED actually do?

Node-RED is an open-source integration tool. Visual, low-code and event-driven. You connect blocks: if this, then that.

But "if this, then that" can be surprisingly powerful. Take a sensor counting products on a production line. On its own, that's just a number. But calculate the time between products, and suddenly you're detecting micro-stops. Add a threshold, and you're flagging anomalies before anyone notices. Combine it with operator data, and you know who was on shift when something went wrong.

That's what Node-RED does: it takes raw data from machines and sensors, enriches it with context, and turns it into something useful. From "a product passed" to "the line stopped for 5 seconds during operator X's shift."

It's free, flexible, and great for prototyping. For a single use case or proof of concept, it's excellent.

‍

What is FlowFuse  and how does it relate to Node-RED?

FlowFuse is built by the initial core team behind Node-RED, but designed for production environments. Same Node-RED engine underneath, but wrapped in everything you need when you're no longer prototyping:

• Version control: see who changed what, when, and roll back if needed
• Role-based access: operator X can view dashboards, engineer Y can edit flows, manager Z approves deployments
• Central management: one overview of all your instances across sites
• Audit trails: essential for NIS2 and other compliance requirements
• Fleet deployment: update dozens of instances at once instead of one by one

Think of it this way: Node-RED is the engine. FlowFuse is the garage, the maintenance schedule, and the fleet manager,  all in one.

Node-RED and FlowFuse in practice: four use cases

We've implemented both tools across different customers and situations. Sometimes FlowFuse was the obvious choice, sometimes standalone Node-RED still does the job.

‍

Detecting micro-stops with FlowFuse across 7 sites

A food producer wanted better visibility into their packaging lines. Sensors were already counting products, but the raw numbers didn't tell them much.

We designed a standardized flow that calculates the time between products passing. If that gap exceeds a threshold, it's flagged as a micro-stop. We enrich each anomaly with timestamp, production batch, and operator on shift,  turning a simple count into an actionable insight.

This now runs across 7 sites worldwide: Belgium, Thailand, the US, and more. Same code, developed once, deployed centrally. When we improve the logic, it rolls out everywhere. With standalone Node-RED on each site, we'd be managing 7 separate versions with no guarantee they're in sync. FlowFuse made central deployment and version control possible.

‍

Multi-site harvest workflow with FlowFuse

Harvest season at a vegetable processor means two months of trucks arriving non-stop. Farmers want to dump their load and get back to the field, fast.

We built an operator app on the weighbridge. The farmer enters their ID, the system captures weight and license plate automatically, and assigns a silo based on product type and available capacity. What used to be chaos — trucks waiting, wrong silos, lost paperwork — became a structured flow.

This app runs on three sites. Updating one means updating all three. With standalone Node-RED, that's three manual interventions and three chances for version drift. With FlowFuse, we deploy once and push to all locations. We see at a glance that all three run identical code  and when harvest season ends, we know exactly what version ran where.

‍

Energy monitoring across sites with FlowFuse

A vegetable processor operates two freezer warehouses, each with its own energy bill but no way to compare consumption patterns or spot inefficiencies across sites.

We stream energy data from both locations to a central FlowFuse instance in the cloud, where it's aggregated and visualised. The insight that emerged: running freezers at -13°C costs nearly twice as much as -12°C. For most products, that one degree doesn't affect quality  but it cuts the energy bill significantly.

You could run a standalone Node-RED instance in the cloud for this. But then you're back to manual management: no central overview of what's running where, version control or SSO. FlowFuse gives us a managed environment where cloud instances and edge devices are visible and controllable from one dashboard.

‍

ERP-to-machine integration with Node-RED

At one food processor, Node-RED handles the translation between ERP and machines. Purchase orders come in, get translated into production instructions, and the line runs.

They're not using FlowFuse here. Why? They have a dedicated IT/OT person who manages all instances. One person, full overview, no handovers.

It works  but it's fragile. That knowledge sits in one head. When that person is on holiday, nobody touches the system. When they leave, there's a problem. We see this pattern often: Node-RED works fine until it doesn't, and by then migration becomes urgent rather than planned.

‍

Signs your Node-RED setup is reaching its limits

Over time, we've noticed a few recurring situations that push teams towards FlowFuse:

"Who changed this?" At one customer, this question comes up every single day. Someone modified something, something stopped working, and there's no trace. In standalone Node-RED, there's no version control, no audit trail, no way to look back three months and see what happened. With FlowFuse, every change is logged: who, what, when.

Overwriting each other's work Multiple people working on the same flows. Someone deploys, someone else was also editing. Work gone. In Node-RED, you can't even see that someone else is online. We've seen this happen daily at manufacturing clients. With FlowFuse, you see each other's cursors in real-time, and deployments require approval.

Manual updates across sites One building materials company ran Node-RED on over 100 sites worldwide. Every software change had to be executed manually — a hundred times. That's not scalable. With FlowFuse, you deploy to development, test, approve, and roll out to all production instances in one action.

Access through jumpservers and RDP Excuse us for going a little technical here. At one customer, engineers needed a jumpserver and RDP session before they could even reach their Node-RED instances. Key users couldn't access anything without IT support. FlowFuse offers SSO integration and browser-based access — the right people get to the right instances directly.

We've seen this go wrong firsthand. At one customer, two sites were running different Node-RED flow versions for months, different alarm thresholds and nobody was aware. It caused significant inconsistency in quality comparisons across plants. The kind of problem that's invisible until it does real damage.

‍

Node-RED vs FlowFuse: when to choose what

Our rule of thumb:

• One instance, one person, one goal? Standalone Node-RED is fine.
• Multiple people, multiple sites, or compliance requirements? FlowFuse saves you time and frustration.
• Not sure how many instances you'll have in a year? Start with Node-RED, but standardise from day one with consistent naming conventions, units and topic structures. That makes a future migration to FlowFuse straightforward rather than a rebuild.

‍

See it yourself

In our demo factory in Ghent, FlowFuse runs on 20+ instances. If you want to see what this looks like when it's actually running, you're welcome to pay us a visit.

Let us know!

‍