Node-RED

The path to Node-RED 5.0

Wed, 03 Dec 2025 00:00:00 +0000

At Node-RED Con I spoke about the future roadmap of Node-RED, charting a course to the 5.0 release.

Previous major version releases have been done with the intention of aligning with Node.JS releases; as old versions reach their end-of-life, we do a major version bump of Node-RED to drop support of those versions. We haven’t been entirely successful in keeping to that schedule, and our overall release cadence has slowed down. It’s time to do something about that.

Rather than just do a 5.0 bump to update our Node.JS support, we wanted to take this opportunity to step back and reflect on what we could do to update the Node-RED user experience. The general look and feel of the editor hasn’t changed for a long time, aside from small tweaks. There are a lot of aspects of the editor that are taken for granted and often overlooked when thinking about improvements to be made.

This was one of the motivations behind the recent community survey - getting feedback from the community on what’s working and what could be improved, understanding how receptive users are to change in the Node-RED experience.

Evolution not Revolution

Building on the results of the survey, as well as our own discussions, we’ve identified four areas of focus:

Node-RED UX Modernization
Node Appearance Improvements
Functional Enchancements
Project Infrastructure Updates

If you want to follow the development work more directly, follow the Node-RED 5.0 issue on GitHub. From there you'll find links to issues for different parts of the plan - some already raised, some to follow.

Node-RED UX Modernization

The Node-RED UI hasn’t changed much over the years. Comparing a screenshot from the very early days of the project with today, you can see a clear visual connection between the two, with the overall structure of the editor largely unchanged.

When we think about the information architecture of the of the editor however, some issues start to appear. Currently, we have the palette on the left, the flows in the middle and everything else stacked up on the right-hand sidebar. The sidebar has become a catch-all space for functionality to be exposed that doesn’t fit in the main workspace.

The Info sidebar provides an overview of all of your flows - a tree-view of all flows and nodes. But we still get feedback around making it easier to navigate around flows. In our Western convention of reading left to right, it would be far more natural to have this overview on the left-hand side.

Another piece of feedback was around the Debug sidebar; a common desire to have it visible whilst working on other things in the editor. The current UX forces you to chose one sidebar at a time - hiding away things you want to keep an eye on.

There is also the question of whether the UI makes the best use of the available space. We want to maximise the space available for working the flows.

Taking all of that into account, we’ve been putting together some UI mockups to see how this could look. It’s important to stress these aren’t ‘final’ designs - but are there to give a sense of direction and prompt feedback.

The full scope of the UX modernization covers a number of areas - some more obvious than others when looking at a static screenshot.

The highlights will include:

Better information flow and navigation
More flexible sidebar arrangements; allowing the user to position them on either side of the editor, or split them vertically
Improved visual accessibility
A built-in dark theme (this one appears to generate particular excitement)

Node Appearance Improvements

We’ve separated out the apperance of the nodes themselves as its own area.

The design of the node has changed very little since the early days of the project. Over time, various additions have been made (status text below, badges above). But there are some unsatisfied requirements we want to look at.

For example, some nodes have an implicit connection to other nodes; such as the Link Call, Status or Catch nodes. But this isn’t visually represented in anyway. This makes navigating those implicit connections hard to do and breaks the developer workflow.

Another area is how to better handle more custom nodes. At Node-RED Con we saw the work being done at Fluidly to create financial workflows in their custom Node-RED application. They have created a very rich visualisation capability within the editor workspace. Whilst that’s a level of customisation quite specific to their needs, there is clearly some interesting lessons we can learn here.

We already have community nodes, such as Image Tools that provide in-editor image previews. Currently that relies on “insider information” to inject the image into the workspace. If Node-RED were to change the internal workings of how flows are drawn, that would break the node. So we want to see how we can accommodate this type of customisation in a standard way - whilst keeping some design guidelines and control in place to ensure a good user experience.

Function Enhancements

There are some fairly targetted functional enhancements we also want to look at. They are a bit more open ended at this stage, but will build on the changes described above.

The main area here is looking at the debugging experience in the editor. The existing Debug sidebar is the backbone of figuring out what’s happening in your flows; but there is plenty of room for improvement, as evident from the many threads in the forum with questions, complaints and suggestions.

We will be working on a plan for how debugging can be made much easier. What lands in Node-RED 5.0 remains to be seen, but we should see some incremental improvements coming soon.

In terms of Node.js support, we’ll continue to support the current and active releases. The Node-RED 5.0 docker images we provide will be based on Node 24.

Project Infrastructure Updates

When we talk about modernizing the Node-RED experience, this isn’t just about the end-user experience. As an Open-Source project, we rely on developers contributing their time to make all of these plans a reality. We need to make it as easy as possible for new developers to contribute. With that in mind, there are various project infrastructure updates we want to make.

Apply standard linting to the code base
Move to npm workspaces for the repository structure. When we setup the current repository structure, containing multiple npm packages, there wasn’t a good solution available to manage everything. So we created our own structure and scripts to manage it. This has worked pretty solidly, but things have moved on and we want to re-evaluate. If there’s a good standard solution for this today, we want to consider moving to it so new contributors don’t have to learn “our way” of doing things.
Replace our task runner with a modern alternative. This is the tool that manages the development environment, runs tests, creates release and many other tasks. It does its job, but it hasn’t updated for a number of years. There are many alternatives available - so we’ll be evaluating the right tool to move to.
Improve our release process; automate more things to make the releases quick to do whilst ensuring a secure and trusted process.

Next Steps

We want to move quite quickly on this plan to get to a stable Node-RED 5.0 release early in the new year. Given the scope of changes being proposed, as with previous major releases, we’ll be publishing regular beta releases of Node-RED 5.0. That’ll start this week, with refreshes as updates are made. We really want to get community feedback along the way.

With this focus on getting to Node-RED 5.0, we will consider Node-RED 4.x in maintenance mode - it will continue to receive fixes for bugs and security related updates, but any new feature will target Node-RED 5.0.

If you want to follow the development work, this is the top-level planning item. From there you’ll find links to issues for different parts of the plan - some already raised, some to follow.

This is an exciting step for the Node-RED project; laying the ground work and refreshing the UX for the future.

Modernization Survey Results

Mon, 01 Dec 2025 00:00:00 +0000

Earlier this year, we ran a community survey with a focus on how we could modernize the Node-RED user experience. We revealed some of the results at Node-RED Con, but now we wanted to share the full set of results with you.

If you want to go ahead and dive into the survey results completely unbiased, you can go ahead and view them on this page: Node-RED Community Survey. We invite you to share your thoughts in this blogpost.

Focusing in on userbase segments

For this blogpost, we want to stay relatively high level and do a kind of retrospective if you will. We will zoom in specifically on the differences between our userbase segments, meaning; everyone who responded, hobbyists, and people using Node-RED in bigger production environments (henceforth called “production-users”). The differences between those are interesting and let us know where to put focus for different use cases.

To start off with, we can look at the level of programming experience and how that differs between the segments.

We can see that the level of comfort with code is balanced differently for people using Node-RED in bigger production environments which is no surprise. It is important to keep in mind though going forward.

In the end, the goal is to improve Node-RED together, so it can further enhance us all and make true on its potential. Whether growth comes from professional use, where Node-RED development can get a boost due to funding, or hobbyists use, where growth through community contributions means a widening of applications and usefulness. Both are important.

What is working well

Node-RED is famous for its visual node based workflow, which comes as no surprise that it is the most beloved feature across all segments. Where it gets interesting is where most value is placed across segments. The general userbase and hobbyists value the ease of working with Node-RED and its versatility, where the production-users value Node-RED especially for prototyping, connectivity, efficiency, and debugging capabilities.

Moving on, we can see that the community and ecosystem, especially sharing flows is especially important for hobbyists. Meanwhile, the effectiveness of Node-RED to get from idea to production through ease of use, ease of debugging, and deployment simplicity is valued more on the production-users side. Dashboards seem to be equally valued across segments.

The open-source aspect is valued more by the community than the production-users segment. Not surprising, but something where I do think we are going to see a change in the years to come. Open-source will continue to become more and more important, also for companies using software. The community is ahead of the curve in this one, as is Node-RED.

Production-users value the stability that Node-RED and its development methodology brings. This is something we are looking into formalising more. We expect this to become an increasingly important factor going forwards due to an increasing AI influence.

Lastly, we want to highlight a more subtle data point: “resistance to change”. Which is surprisingly low across all segments, though we need to take into account all things that Node-RED does well! The Node-RED community is an especially supportive one.

What is not working as well

The most striking difference is version control and diffing; it frustrates 42% of production-users compared to just 23% of hobbyists. This makes sense when you consider teams working on the same flows and needing to track changes over time. Similarly, managing large or complex flows (32% vs 20%) and understanding performance impact (28% vs 15%) are significantly bigger pain points in production environments.

On the flip side, we can see that mobile and tablet usability frustrates hobbyists more (26%) than production-users (16%), which suggests more varied device usage. The same goes for UI navigation and management where hobbyists seem more frustrated with this at 22% while production-users only at 5%. Debugging flows is the top frustration for hobbyists at 27%, while production-users seem more comfortable here at 20%, likely due to their higher programming experience levels. For hobbyists, this points at problems getting acquainted with Node-RED, both when starting out and when starting to use Node-RED for more use cases. Even for production-users it is a point of attention.

One thing that stands out across all segments: the lack of UI customisation and concerns about community/custom node availability both sit around 21-24% - these are universal pain points regardless of how you use Node-RED.

Moving on to what holds back production adoption. This section will naturally focus more on production-users, plus some results here, for hobbyists, must be taken with a grain of salt.

We can see that version control appears again as the #1 blocker with 40% for production-users versus only 16% for hobbyists. This might also point at that Node-RED might not be informing well enough about what upgrade paths there are in the community for more advanced use cases. FlowFuse being the main one, where they extend Node-RED for enterprises, and already solve for this pain point.

We continue to see a clear pattern of enterprise concerns emerging for production-users: uncertainty about third-party node quality and security (32%), lack of monitoring and management tools (28%), limited enterprise security features (25%), and compliance/auditing concerns (18%). These are areas where hobbyists show significantly less concern, which makes sense given the different stakes involved. The exception being “third-party node quality and security” which is a theme we are sure to improve upon as soon as possible.

Furthermore, management skepticism about viability affects 20% of production-users. Meaning one in five face internal resistance to adopting Node-RED. The perception of Node-RED as “a hobby tool, not professional” affects 11% of production-users. Collaboration and team features are also notably more important for production-users (19%) than hobbyists (7%), highlighting the need for better multi-user workflows and an expectation of modern user workflows.

This question reveals something important about satisfaction levels across segments. Hobbyists are considerably more satisfied - 28% said “nothing” would draw them away, compared to only 10% of production-users. This gap tells us that while Node-RED serves hobbyists better, there is more work to do, especially for production use cases.

Production-users are significantly more concerned about performance and technical issues (26% vs 10%), security and safety concerns (13% vs 5%), and community/ecosystem sustainability (13% vs 8%). Meanwhile, superior alternative platforms would draw away 16% of production-users versus 13% of hobbyists - competition is felt more strongly in the enterprise space.

One thing that remains consistent across all segments: licensing and pricing concerns sit at 23-27%. This reflects the strong value our community places on Node-RED’s open-source nature. It is important to note here that Node-RED is owned by the OpenJS foundation which protects it from a lot of pitfalls of profit driven projects or projects that can be bought out. It is a move we have seen across the industry with the open home foundation and the react foundation. We can improve on making sure this is as apparent as possible.

What we should focus on

Though this section can feel a bit duplicative considering the previous section, we think it is important to see how more directed questions unveil additional information or validate previous points.

Better dashboard creation tools tops the list for hobbyists and is also important for production users. This aligns with UI customisation needs. Production-users’ needs are confirmed again with version control and diffing (28%) and enhanced debugging (28%). Where it gets interesting is AI-powered assistance in-app: production-users want this at 27% compared to hobbyists at 16%. This suggests production-users see more potential for AI to help with complex flow development. To reinforce this: hobbyists put a lot of value on the documentation and help system which indicates a bigger reliance at traditional support tooling.

We can see that better performance with large flows is significantly more important for production-users (26%) than hobbyists (10%), which aligns with the frustrations we saw earlier. Mobile and tablet interface improvements matter more to hobbyists (23% vs 11%), again reflecting their more varied usage contexts.

One thing that stands out: improved collaboration features are twice as important for production-users (14%) compared to hobbyists (7%), reinforcing the need for better team workflows in enterprise settings.

UI/UX and visual improvements clearly lead across all segments at around 40%. This is a strong signal that modernizing the interface should be a priority. AI integration and LLM support comes second at 25-28% across segments, showing the community’s interest in keeping Node-RED current with modern technology trends regardless of current biases.

Performance and scalability shows a surprising pattern: hobbyists care more (11%) than production-users (7%). This might indicate that production-users have already found workarounds or are using extended solutions like FlowFuse for their scaling needs. Home users will often be more reliant on single instances, indicating also at the need for better understanding of Node-RED instance capacity-usage.

Dashboard enhancement shows the starkest contrast: 23% for hobbyists versus only 5% for production-users. This suggests hobbyists rely more heavily on Node-RED’s built-in dashboard capabilities, while production environments likely use external visualization tools.

Configuration and settings management is notably more important for production-users (18% vs 4%), as is core architecture and language support (16% vs not in top results for hobbyists). These point toward needs for better deployment configuration and TypeScript/ESM modernization in enterprise contexts.

This open-ended question brings everything together and reinforces what we have learned already. Other than that, Hobbyists are more satisfied overall: 21% said “nothing/no changes” compared to only 9% of production-users. The focus on debugging and development tools remains high across both segments (22% and 16%), suggesting this is a universal improvement area that would benefit everyone.

Including the community

We have worked hard at figuring out a comprehensive way to let you in on all the information gathered. We are curious about the interesting community takes and initiatives that might surface as a result from it.

For your information:

The results follow the same order as the survey
It has a filterable “Table of Contents” to be found in the right sidebar
Any result is filterable, even survey questions with qualitative answers
There are quick filters in the left sidebar to change segments easily

It is important to us that not only we can derive conclusions, and instead we would much rather see an active discussion pop-up from it to collectively discuss conclusions coming from a diverse set of perspectives.

Dive into the survey results on this page: Node-RED Community Survey. We invite you to share your thoughts in this blogpost.

Gratitude and staying in contact

We want to thank everyone that contributed to the survey. We think the amount of input we have received was simply astonishing and of great value.

Alongside the forum and GitHub, the community survey invited participants to share their contact information so we can reach out more directly in the future when we want to gather feedback from particular groups of the community. This will be an invaluable resource for the continued development of the project.

If you'd like to join this group, you can join the over-200 people who have already signed up [here](https://tally.so/r/7RXl0L).

You can see here how the user segments signed up originally with the survey:

Thank you for your support and engagement. We are looking forward to improving Node-RED together.

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.

Node-RED

The path to Node-RED 5.0

Evolution not Revolution

Node-RED UX Modernization

Node Appearance Improvements

Function Enhancements

Project Infrastructure Updates

Next Steps

Modernization Survey Results

Focusing in on userbase segments

What is working well

What is not working as well

What we should focus on

Including the community

Gratitude and staying in contact

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

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