Node-RED

Node-RED Con 2025 is coming!

Tue, 28 Oct 2025 00:00:00 +0000

Node-RED Con 2025 is just a week away! This year’s online conference will showcase how Node-RED is driving innovation across industries — from factory floors and utilities to finance and smart homes.

We’ve put together a full schedule of talks from across the community and it’s promising to be a great event.

I’ll be giving the opening keynote on the current state of the project and where we’re headed. This includes unveiling the results of our recent community survey and what plans we have for modernizing the Node-RED user experience.

I’m really looking forward to the event and I hope you’ll join the 1000+ people who have already registered to attend.

Be sure not to miss out and get registered here!

Version 4.1 released

Tue, 29 Jul 2025 00:00:00 +0000

Node-RED 4.1 is now available to install. If upgrading, please read the upgrade instructions.

The Change Log has the full list of changes in this release.

Whilst we have your attention, we’re already thinking about what comes next - and we’re running a community survey over the next couple of weeks to help shape our future roadmap. Please give us 10 minutes of your time and share your thoughts. You can take the survey here.

Update Notifications
Node Documentation icon
Managing flow dependencies
Palette Manager Updates
Other updates
Node Updates
Full Changelog
Community

Update Notifications

One of the first things you’ll see when you start 4.1 is a request to enable update notifications. This enables a notification in the editor when there is a new version of Node-RED available. This ensures you can keep up to date with the latest fixes and features. In return, Node-RED sends back anonymous usage information to the project, covering information on what version of NR is being used and type of OS. No information about your users or flows is shared. More information on what is gathered, why and how it’ll be used is available in the documentation.

Separately, it will also notify you when there are updates available for any of the nodes in your palette. This part of the notification is handled by the Palette Manager based on the node catalogues it downloads; as such, it is enabled by default.

Node Documentation icon

An often requested feature has finally made the cut; any node with documentation added in its ‘Description’ field of the edit dialog will now show the Info icon. Clicking on the icon will open up the edit dialog.

As before, when a node is selected, any content in its Description is shown in the Info sidebar

If you aren’t a fan of the icon, you can turn it off in the Editor Settings dialog.

Managing flow dependencies

Whilst Node-RED makes it super simple to share flows via its import/export dialog, a common challenge has been not knowing what additional modules need to be installed for the flow to work.

With this release, when you export a flow, it now includes meta-data of which additional modules are used by the flow.

When importing the flow, if any of the node types aren’t recognised, the editor can now use this information to let you know what needs to be installed.

Note: we chose not to automatically install the modules as it felt important that the user should be able to make that choice and not have things get installed without their knowledge.

This additional meta-data is held in a global-config node within the export. This is a node type that was introduced in Node-RED 4.0 - so you will still be able to import flows from 4.1 back to 4.0.

Palette Manager Updates

The Palette Manager has had a number of small but powerful updates.

Deprecated modules

If a node module has been deprecated by its author on npm, or flagged as such on the flow library, it will now show a deprecated badge. This will be a sign to avoid the module unless you have a very specific need to use it.

The Flow Library has been updated to also show this information on the nodes page.

Sorting nodes by downloads

By default the list of nodes available to install are now sorted by download count. That helps to prioritise the more widely used and popular nodes.

Links to node docs

We’ve added links to a node’s documentation on the Nodes tab (previously this was only on the Install tab)

Better support for Plugins

The list of installed modules now handles plugins better - particular those modules that contain a mix of plugins and nodes

When installing a node from the palette manager, it can sometimes take a while depending on where Node-RED is running and the size of the module being installed. If you close the palette manager, you then lose any feedback of the install still running.

We’ve had the Event Log view since the early days of Node-RED (menu -> view -> Event log) but I bet its something most users are unaware of.

With this release, if there is an install running in the background, a progress widget is shown in the editor footer. Clicking on it will open up the event log. Once the install completes, the widget will hide itself.

Other updates

There’s a lot of other smaller items in the changelog, a few more to highlight:

Deploying when you have a badly configured node has alway asked for confirmation. The logic behind that will now ignore nodes that are disabled - as they won’t impact the deployed flow.
A new action is available that will trigger the buttons of any selected nodes. This action (core:trigger-selected-nodes-action) can be found in the Action Menu (Ctrl-Shift-P), and can be bound to whatever keyboard shortcut you want.
Clicking outside of a Node’s edit dialog will no longer close the dialog.

Node Updates

Here’s a list of the various updates made to the individual core nodes.

Complete/Status: Fix complete node to not feedback immediately connected nodes (#5114)
Function: Add URL/URLSearchParams to Function sandbox (#5159)
Function: Add support for node: prefixed modules in function node (#5067)
Function: Add globalFunction timeout (#4985) @vasuvanka
Exec: Make encoding handling consistent between stdout and err (#5158)
Split: Let split node send original msg to complete node (#5113)
Split: Rename Split The field (#5130)
MQTT: Ensure generated mqtt clientId uses only valid chars (#5156)
HTTP In: provide access to request body as Buffer
HTTP Request: Fix the capitisation for ALPN settings in http-request (#5105)
HTTP Request: (docs) Recommend HTTPS over HTTP (#5141)
HTTP Request: Include URL query params in HTTP Digest (#5166)
Catch: Add code to error object sent by Catch node (#5081)
Debug: Improve debug display of error objects (#5079)
Debug: Improve display of loooooong message properties

Full Changelog

The full set of changes in this release can be found in the changelog

Thank you to everyone who contributed to this release - we wouldn’t be able to do it without you!

Community

As an open-source project we are reliant on the contribution of the community. We have a strong and vibrant user community, well demonstrated by the activity on the forums. It’s great to see the support the community provides each other.

If you’re interested in contributing to Node-RED, now is a good time to come over and chat with us in either the forum or slack.

Version 4.0 released

Thu, 20 Jun 2024 00:00:00 +0000

Node-RED 4.0 is now available to install. If upgrading, please read the upgrade instructions.

We’ve highlighted some of the main highlights of the release below. There have also been a large number of community contributions ranging from bug fixes, features, documentation and translations. We wouldn’t be able to do what we do without these contributions - a big thank you to everyone involved.

The Change Log has the full list of changes in this release.

Node.js 18 or later
Editor Updates
Runtime
Node Updates
Full Changelog
Community

Node.js 18 or later

Node-RED 4.0 requires at least Node.js 18. At the time of release, we recommend using Node 20 as the active LTS release that will continue receiving updates until April 2026.

Editor Updates

Auto-complete for `flow`/`global` and `env` inputs

Node-RED already has simple auto-complete on msg fields in the editor. We’ve now extended that to also work with flow/global context inputs as well as the env type for accessing environment variables.

This makes it so much easier to work with these types of properties - being sure you’re using something that exists rather than having to switch between different views in the editor to get the names right.

In the case of env vars, it also shows you where the value was set - useful when you have nested groups and subflows which might be overriding a particular value.

Customising config nodes in Subflows

This one needs a bit of explaining. Subflows are a way Node-RED lets you create a flow and add multiple reusable instances of it within your flows. For example, a subflow may connect to an MQTT broker and do some standard processing on the messages it received before sending them on. The Subflow can then expose a set of properties that can be customised for each instance. In our example, that could be the topic the MQTT node subscribes to.

However, in that example, the MQTT node’s broker configuration would be locked to the same broker config node in every instance - and that’s something we’re solving in Node-RED 4.0.

We’re making it possible to expose the choice of a configuration node in the Subflow properties - so each instance can be customised even further.

Another common use for this will be with Node-RED Dashboard - which uses config nodes to set the location of a widget. With Node-RED today, you cannot really use dashboard nodes inside subflows as you end up with multiple copies of the widgets all packed into the same group. With this update, you’ll be able to configure the subflow instance with exactly what dashboard group to place its contents into.

Timestamp formatting

The Inject node has provided the ability to inject a timestamp since the very early days of Node-RED. The value it actually sets is the number of milliseconds since epoch (aka January 1st, 1970). If you’re used to working with JavaScript, then this is a perfectly normal way to pass times around. However, it isn’t always what is needed and flows end up using a Function node to reformat it in some way.

With 4.0 we’ve added options to pick what format the timestamp is generated in at the start. Now, formatting times and dates can be a big can of worms of options. So, for this initial release, we’ve kept it simple by offering three options:

milliseconds since epoch - the existing option, just more explicitly labelled for what it is
YYYY-MM-DDTHH:mm:ss.sssZ - also known as ISO 8601
JavaScript Date Object - the standard Date object

There is scope to allow custom format strings to be set in the node - but we’ll see what the feedback is on these new options first.

Multiplayer Mode

We’ve made a number of changes to improve the user experience when multiple people have the editor open at the same time.

When enabled via the settings file, the new Multiplayer Mode lets you see when other users have the editor open and where they are - which tab they have open and whether they are editing a node.

It’s a small step forward towards a longer-term goal of having a live view of the changes other users are making.

This new mode is not enabled by default. To turn it on, you need to set editorTheme.multiplayer.enabled property to true in your settings file. We’ve added a placeholder in the default settings file, but for an existing install, you’ll need to add it yourself. You can see how/what it should look like here.

Better background deploy handling

In the same theme as the new Multiplayer Mode, we’ve also made some improvements to the existing ‘background deploy’ handling in the editor. This is where someone deploys new flows whilst you are busy working in the editor.

Previously, you would get a notification that you couldn’t ignore and would have to interrupt what you were doing to deal with. If your colleague was being particularly productive and deploying frequently, you’d get a new interruption every time.

With this release, we’ve made the notification less intrusive. It’s no longer modal, so you can carry on what you were doing without having to take any action. We’ve made it slim line so it doesn’t get in the way, and it will self-close after a short period. As with similar runtime notifications, we now also show a warning icon in the header if there has been a background deploy - as it will need dealing with eventually - clicking on that icon shows the notification so you can take action when you choose to.

Improved Diff view for moved nodes

When reviewing changes in the flows, either as a result of a background deploy, or as part of the Projects feature, we now highlight nodes that have only been moved separately to those that have had configuration changes.

When faced with a long list of changes, this will make it easier to spot changes that you care about.

Better feedback for read-only users

Previously if a user had read-only access to the editor, they could make changes and click the deploy button - only to be told at that point they cannot make changes.

With this release, the Deploy button now shows a lock icon if the current user doesn’t have permission to deploy changes. They can still make changes in the workspace, but the deploy button won’t become enabled.

New Config Node selection UI

We’ve updated the UI around config node selection to simplify the task of adding a new config node.

Feedback from new users showed some confusion on how to add a second config node when there was one already selected in the list. There is now a dedicated add button alongside the selection of existing nodes

Other updates

The Palette Manager now lists plugins you have installed alongside nodes.
The Palette sidebar now remembers how you have expanded or collapsed the different categories

Runtime

Faster deploys for large flows

We’ve swapped the library we use to clone flow configurations in the runtime. The new library is faster and uses less memory.

The gains are less noticeable in ‘typical’ flows, but for those of you with large flows, there should be an improvement.

In my testing, a config with a few hundred tabs with a few hundred nodes on each, plus some subflows went from 8 seconds to deploy down to just over 1 second.

Updated JSONata

The JSONata library is used to provide the expression types in Node-RED - a really powerful way of working with JSON objects. With this release we’ve updated to the new major release of JSONata that comes with a bunch of performance improvements.

But it also comes with a breaking change with how it gets invoked under the covers. We prepared for this in 3.1 by adding a large warning to the log if we ever spotted a node accessing it incorrectly. With this release, that warning becomes an error.

Given we didn’t hear a lot of complaints in the 3.1 release about this, either the warning went unnoticed, or it isn’t a wide-spread issue. However, this will be something to keep an eye on as you upgrade.

Other updates

The following configuration options have been added to the default settings file:
- httpAdminCookieOptions can be used to customise the options set on cookies as part of the authentication system.
- httpStaticCors can be used to set custom cross-origin resource sharing rules for the content served up via the httpStatic option
node-red --version now reports the Node-RED, node.js and os information without starting Node-RED.

Node Updates

A better CSV node

The CSV node has had a big overhaul to make it more standards compliant. It turns out CSV has a whole bunch of tricky edge cases that most users don’t hit - but if you did hit them you would be stuck.

The new node follows the RFC4180 standard and is also faster - wins all around.

Existing flows using the CSV node will stay in ‘legacy’ mode until they are modified to use the new parser.

Updated Proxy Handling

The HTTP Request node’s handling of proxies has been updated to address a number of issues and to bring better support for the various standard environment variables used to configure proxies.

Details are in the original issue and the pull request that fixed it.

Other updates

TCP node - when resetting, if no payload, stay disconnected @dceejay
HTML node: add option for collecting attributes and content (#4513)
let split node specify property to split on, and join auto join correctly (#4386)
Fix change node to return boolean if asked (#4525)
Let msg.reset reset Tcp request node connection when in stay connected mode (#4406)
Let debug node status msg length be settable via settings (#4402)
Feat: Add ability to set headers for WebSocket client (#4436)

Full Changelog

The full set of changes in this release can be found in the changelog

Thank you to everyone who contributed to this release - we wouldn’t be able to do it without you!

Community

If you’re interested in contributing to Node-RED, now is a good time to come over and chat with us in either the forum or slack.

Version 3.1 released

Wed, 06 Sep 2023 00:00:00 +0000

Node-RED 3.1 is now available to install. If upgrading, please read the upgrade instructions.

This release is a little overdue to say the least. We released the first beta back in February - thinking it would be the only one we did. But one thing lead to another and, four beta releases later, here we are finally with the full release for everyone to enjoy.

These delays have had a knock-on effect to our release plan. We’re going to shift things around a bit, but still plan to have Node-RED 4.0 released in the near future to keep up to date with Node.js versions reaching their end-of-life.

We’ll also get back to more regular maintenance releases to keep things moving.

With all that said, and without our usual accompanying video, lets dig into what 3.1 has to offer. As ever, the Change Log has the full list of changes in this release.

Editor Updates
Runtime Updates
- Individual http middleware for httpStatic routes
What’s next?

Editor Updates

Change notifications on tabs

The tab bar now shows a change icon for any tabs that contain changes. This makes it much easier to find where things have changed in your flows.

A bigger workspace

We have occasionally had requests to make the tab canvas bigger. There was even a discussion around making it infinitely large - allowing a flow to be as large as it needs to be. Whilst that’s a nice idea, for this release we’ve simply increased the size of each tab from 5000x5000 to 8000x8000.

We’d still recommend using tools like Subflows and Link nodes to help organise your flows, but at least this quick change will give you plenty more space to use if you need it.

Locking Flows

You can now lock a flow (tab in the editor) to prevent it from being modified. Whilst locked you cannot edit the nodes, add new nodes, modify the wiring… anything.

Why is that useful? You may have a ‘mission critical’ flow that you want to be super careful not to change by accident. You may want to collaborate on some flows with others, but mark some of them as ‘off limits’.

With this release anyone is able to lock and unlock flows, but it lays the ground work for a possible future where particular users may not have permission to unlock flows - allowing them to only edit the flows they are allowed to.

The options to lock/unlock flows are available in the right-click context menu - as well as a new padlock button in the Info sidebar explorer.

To make this work, we’ve modified how ‘nodes’ are managed inside the editor to prevent them being modified on locked flows. No apis have changed, but it does mean certain calls might fail if they are attempted on a locked flow. This has had a fair amount of testing across all of the core features of the editor, but 3rd party node authors are a creative bunch and it is possible someone is doing something ~~sneaky~~ unexpected with their node implementation that gets tripped up by this. So if you see any odd/inconsistent behaviour with this feature, please do let us know (and definitely have ready any error messages from the browser’s JavaScript console).

Hiding Flows

We added the ability to hide flows a couple releases ago. This was done use the ‘eye’ icon that appeared when you hovered over the tab.

We got plenty of feedback, including our own experience, that it was way too easy to accidentally click that button and make things disappear without realising it.

So for this release we’ve gotten rid of that button on the tab. Flows can still be hidden, but you do so via the context menu option when you right-click on the tab bar. You can still use the eye button in the Info sidebar explorer.

New Group User Experience

Following feedback from the community on what it was like to work with the groups feature in the editor, they have been given a big overhaul in this release.

You can now click on any node, inside or outside of a group, and interact with it directly. No more clicking multiple times to get to a node.

Because of that change, you now move a group by clicking on its border and dragging it. But what if you’ve made the border invisible? It now highlights whenever you mouse over it.

We’ve also made it possible to drag multiple nodes into a group in one go - previously we only supported dragging one node in at a time.

And in response to a particular piece of feedback, if you hold down alt whilst dragging a selection of nodes inside a group, you can drag them out of the group.

Overall, this should make for a much for intuitive user experience.

Group-level scope for the Catch/Status

The Catch/Status nodes could already be configured to handle specific nodes within a flow. They can now also be configured to handle just the nodes in the same group as them (or any nested groups).

This gives you more options for organising your flows and their error handling.

We’ve expanded the usefulness of the Context Menu added in the last release. There are now lots more commonly used options available in the menu, which also provides better options related to what you clicked on to open the menu. This includes right-clicking on the tab bar at the top of the workspace to get flow-specific options.

Adding images to node/flow descriptions

All nodes and flows have a Description tab in their edit dialog. This lets you write docs (using markdown) that gets displayed in the Info sidebar when the thing is selected.

With this release you can now drag images directly into the markdown editor and they will get inlined. This is done by base64 url encoding the image directly into the description property.

Mermaid Diagrams

We’ve also added support for Mermaid diagrams. These are diagrams that can be defined directly in the markdown and then rendered out as images when displaying in the sidebar. GitHub recently added support for them, and I’ve found them to be super-useful when documenting things when plain text isn’t quite enough.

Global Environment Variables

We’ve supported defining environment variables scoped to individual flows, subflows or groups for a while. But the only way to define an environment variable available to all flows was to do it via your settings file. That wasn’t very accessible or portable.

So with this release you can now define global env vars via the User Settings dialog:

Under the covers these get added to your flow as a new core configuration node type. That will mean importing a flow from 3.1 with global env vars into an earlier version of Node-RED will lead to an unrecognised node warning - something to be aware of.

New subflow environment variables

Within a subflow, you can now use NR_SUBFLOW_NAME NR_SUBFLOW_ID and NR_SUBFLOW_PATH to access those properties of the subflow instance node.

These join the existing NR_NODE_*/NR_FLOW_* and NR_GROUP_* equivalents.

Changes to how Environment Variables are evaluated

Environment variables are statically defined values that cannot be changed whilst the flow is running. There were some edge cases to this, such as using a JSONata expression of $now() that would get re-evaluated every time it was referenced.

Because of the need to make JSONata fully asynchronous in the future, we’ve changed how the env var evaluation is done - their values are now all generated when the flows start and not re-evaluated again.

This should not cause any changes in behaviour, unless you were relying on the $now() trick that was not an intentional behaviour.

As nodes can depend on env var values, we’ve also updated the logic around the ‘modified nodes’ and ‘modified flows’ types of deploys. Changing an env var at the flow level will now cause all of the nodes on that flow to be considered modified. This is a bit of a blunt solution for this release and we may refine it to be more selective to only the nodes that reference the changed env var - but that’s for another day.

Linking to Node Help

Every node dialog now has a help button in its footer. This will open the Help sidebar and display the… you guessed it… help for the node.

Deprecating synchronous access to JSONata

This is one for node authors rather than end users.

JSONata 2.0 was recently published and promises a lot of significant performance improvements. However it brings a major breaking change - you can no longer evaluate expressions synchronously. So we can’t upgrade to it quite yet, but we can lay some ground work for it.

Since we introduced JSONata into Node-RED, we’ve provided a set of standard APIs for nodes to use. Notably:

RED.util.evaluateNodeProperty - used to evaluate all sorts of standard types of property
RED.util.evaluateJSONataExpression - used to evaluate a prepared JSONata expression

Both of these functions accept an optional callback parameter which allows them to evaluate asynchronously - however they both also allow synchronous behaviour.

With this release we have deprecated calling evaluateJSONataExpression without a callback argument. By extension, evaluateNodeProperty will require a callback if being used with JSONata.

Using these APIs without a callback will trigger a warning in the log, along with a full stacktrace that will hopefully help identify the node that caused it.

Our intention is to update to JSONata 2.0 in Node-RED 4.0 this summer - so we want to flush out any nodes that need updating.

Improved wiring for horizontally aligned nodes

Following this discussion on the forum, we’ve made some modifications to the wiring layout logic to improve cases where wires loop back on horizontally laid out nodes.

Here is a before/after pair of screenshots:

Runtime Updates

Individual http middleware for httpStatic routes

It is now possible to configure separate middleware functions for different httpStatic configured routes.

See #4229 for the details.

What’s next?

As I mentioned at the start, this release is overdue and has pushed back the existing release plan.

With Node.js 16.x reaching its end-of-life next week, we’ll be moving forward with Node-RED 4.0 in the near future. As it stands, we strongly recommend users to be using Node 18 or 20 by now.

If you’re interested in contributing to Node-RED, now is a good time to come over and chat with us in either the forum or slack.

2023 Community Survey

Thu, 23 Feb 2023 00:00:00 +0000

Update: the results are now available here.

Back in 2019 we published the results of the 2019 Node-RED community survey. The results painted an interesting picture of the Node-RED community. We think it is time to refresh these results so we are running the survey again.

The 2023 survey is similar to the 2019. We’ve made a few tweaks, removed some questions and added some new ones. The goal is to get a better picture of who our uses are, what they do with Node-RED and to make sure we keep the project pointed in the right direction.

The survey will be open until March 31. Of course we would like to get as many respondents as possible. In 2019, we have over 800 individuals respond so hopefully we can meet this number again this year.

Once the survey has been completed, we will publish the results for the entire community to see.

The survey should take less than 10 minutes to complete. Thank you in advance for your feedback.

Update: The survey is now closed.

Node-RED

Node-RED Con 2025 is coming!

Version 4.1 released

Update Notifications

Node Documentation icon

Managing flow dependencies

Palette Manager Updates

Deprecated modules

Sorting nodes by downloads

Links to node docs

Better support for Plugins

Event log widget

Other updates

Node Updates

Full Changelog

Community

Version 4.0 released

Node.js 18 or later

Editor Updates

Auto-complete for flow/global and env inputs

Customising config nodes in Subflows

Timestamp formatting

Multiplayer Mode

Better background deploy handling

Improved Diff view for moved nodes

Better feedback for read-only users

New Config Node selection UI

Other updates

Runtime

Faster deploys for large flows

Updated JSONata

Other updates

Node Updates

A better CSV node

Updated Proxy Handling

Other updates

Full Changelog

Community

Version 3.1 released

Editor Updates

Change notifications on tabs

A bigger workspace

Locking Flows

Hiding Flows

New Group User Experience

Group-level scope for the Catch/Status

Updated Context Menu

Adding images to node/flow descriptions

Mermaid Diagrams

Global Environment Variables

New subflow environment variables

Changes to how Environment Variables are evaluated

Linking to Node Help

Deprecating synchronous access to JSONata

Improved wiring for horizontally aligned nodes

Runtime Updates

Individual http middleware for httpStatic routes

What’s next?

2023 Community Survey

Auto-complete for `flow`/`global` and `env` inputs