Node-RED

Version 5.0 released

Tue, 09 Jun 2026 00:00:00 +0000

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

Node-RED 5.0 is the biggest change to the editor experience in the history of the project. Back in our roadmap post we set out four areas of focus - modernising the UX, improving node appearance, targeted functional enhancements, and updating our project infrastructure. After a long run of beta releases - and a huge amount of community feedback along the way - we’re delighted to bring it all together in the final release.

We’ve highlighted the main changes below. As always, 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.

A modernised editor
Functional enhancements
Node and security updates
Under the hood
Full Changelog
Community

A modernised editor

The general look and feel of the editor hadn’t changed substantially in a long time. With 5.0 we’ve taken the opportunity to step back and rethink how the editor is laid out, with a focus on better information flow, more flexible use of space, and improved accessibility.

This was a big, iterative piece of work, refined through the beta releases in response to community feedback. The result is an editor that should feel familiar, but makes far better use of the space available to you.

The modernised Node-RED 5 editor

Redesigned sidebars

Previously the sidebars were a catch-all space on the right-hand side, with the available panels hidden behind a hard-to-discover drop-down menu. Both sides of the editor now share the same, more discoverable sidebar behaviour.

The biggest change is that you can now show two panels at a time by splitting a sidebar vertically. This means you can, for example, keep the Debug panel visible in the lower section while working with another panel above it - a long-requested capability.

You can rearrange panels by dragging them directly between the available positions. Each panel has a small header showing its name that you can grab to move it around the editor - to either side, or into the upper or lower section of a side.

Along the bottom are the sidebar buttons, grouped by sidebar section, and toggle buttons to open and close the sidebars in a single click.

Sidebar toolbar

The Explorer and Information sidebars

The old Info sidebar has been split into two distinct panels:

The Explorer lets you navigate your flows and nodes. In our left-to-right reading convention it’s far more natural to have this overview on the left, so it’s now the default panel in the top-left sidebar section.
The Information panel shows details on whatever you currently have selected, and is the default panel shown in the top-right.

The Explorer and Information sidebar panels

Built-in Dark theme

Node-RED finally has a built-in Dark theme. The editor automatically picks the light or dark theme based on your browser/OS preference, and you can explicitly choose one in the User Settings dialog.

Node-RED 5 dark mode theme

Alongside this, we’ve added a mechanism for theme plugins to provide multiple variants - so a third-party theme can now ship both a light and dark variant in a single package, and have the editor switch between them automatically.

Accessibility improvements

Improved accessibility has been a recurring theme throughout this work. We’ve started applying appropriate ARIA attributes across the editor, the dropdown menus are more touch-accessible and scroll when there isn’t enough vertical space, and the theme has had a number of contrast and accessibility refinements. There’s always more to do here, but Google Lighthouse is much happier with us than it was before.

Updated selection appearance

As part of the accessibility improvements, selected nodes now show as a blue halo around the node, rather than just changing the node’s border. This makes it much easier to spot what’s selected, and clashes far less with the colour of the node body.

Node selection

Updated pan and zoom

We’ve updated various pan/zoom interactions withe workspace to better align with standard behaviours seen elsewhere.

As before, you can pan with the middle-mouse button. If you don’t have one, you can now hold the spacebar and drag with the left-mouse button to achieve the same result. There’s a new ‘zoom to fit’ button in the status bar that zooms your view so all of your nodes are visible. Pinch-zoom on touch screens is also much better behaved, and shift-scroll now works consistently across browsers.

Node documentation

Node that have additional documentation added under the description tab of their edit dialog now show a badge in the workspace. Clicking on the badge will show the documentation in a pop-up.

Node documentation badge

GitHub-style alerts in Markdown

The Markdown used throughout the editor - in node help, the Comment node, info text and more - now supports GitHub-style alerts. Adding a marker such as > [!IMPORTANT] or > [!WARNING] to a blockquote renders it as a highlighted callout. The Markdown editor toolbar also gained a button to help you discover and insert them.

Markdown editor including an Information alert

Other editor updates

Search navigation now appears in a popover rather than expanding the status bar, so the status widgets no longer shuffle around as you step through results (#5744).
The default palette categories now have description tooltips, and custom categories can provide their own descriptions via a theme plugin or node (#5769).
Some missing core actions and keyboard shortcuts have been added and tidied up - including shortcuts to show the Palette (ctrl-g p) and Explorer (ctrl-g e) panels, and an action to toggle the Debug sidebar’s pause state (#5777).

Functional enhancements

Pausing debug output

A long-requested feature: you can now pause the Debug sidebar using a toggle button in its header. While paused, the panel stops scrolling and any new messages received are dropped.

Pausing debug output

Calling Link nodes from the Function node

It’s now possible to call a Link node from the middle of a Function node and wait for a response to be sent back. For example, if you’d built a flow wrapped in Link nodes to handle database queries, you could call it from code with:

const { payload: data } = await node.linkcall('query-database', { query: "SELECT * FROM T1" })

The new API is exposed as node.linkcall. You pass it the name, or id, of the link in node to call along with the message to send it.

Fully details of the api are available in the Function node documentation.

Sorted node selection lists

The Link, Complete, Catch and Status nodes all present a list of other nodes to select from in their edit dialog. Previously this list was shown in the order the nodes were added to the workspace. It’s now sorted alphabetically by label, making it much easier to find the node you’re after.

Delay node burst mode

The Delay node’s rate-limiting mode has always spread incoming messages out evenly to the configured rate. It can now also be put into burst mode, where it lets messages through at whatever rate they arrive until the limit is reached - at which point it blocks them until the start of the next time interval.

Node and security updates

More TLS options

The TLS configuration node and several core nodes have gained more flexible options for securing connections:

TLS certificates and keys can now be supplied from a PFX/P12 file (#4907).
Certificates and keys can be loaded from environment variables (#5376).
The HTTP Request node can now set the TLS SNI server name (#5667).

Hardened authentication

We’ve made a couple of changes to tighten up the editor’s authentication:

OAuth logins now use a token-exchange pattern (#5657).
The default admin CORS rules have been removed (#5652).

Other updates

The Monaco code editor used by the Function node has been updated to the latest release (#5508).
New credentials files are now created next to the flows file, rather than in the user directory (#4951).
The WebSocket client now only connects when it needs to (#5533).
The touch radial menu has been replaced with the standard context menu for a more consistent experience (#5614).

Under the hood

Node.js 24

Node-RED 5.0 requires a minimum of Node.js 22.9.0 to run - it will not run anything earlier.

However, keeping in mind the Node.js support scheduled, we recommend using Node.js 24, and this is what our Docker images are based on.

As the Node.js project no longer create 32bit ARM (arm/v7) based images, we are no longer able to support running on older Raspberry Pis (3b or earlier) as they cannot run the required 64bit OS.

Bundling npm

Previously, Node-RED relied on npm being installed and on the path for the palette manager to work. With this release, npm is now an explicit dependency of Node-RED. This gives us more control over how it’s used and closes some potential security issues.

Modernised developer setup

For contributors to the core code base, we’ve migrated away from the grunt task runner in favour of custom npm scripts. Grunt was the right choice 13 years ago, but the world has moved on - and now, so have we. This lets us drop a lot of unmaintained devDependencies from the project.

We’ve also moved off the long-dormant jshint to eslint. At this stage we’re not applying any new linting rules, but it lays the groundwork to do so in the near future.

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.

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 Enhancements
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

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

Version 5.0 released

A modernised editor

Redesigned sidebars

The Explorer and Information sidebars

Built-in Dark theme

Accessibility improvements

Updated selection appearance

Updated pan and zoom

Node documentation

GitHub-style alerts in Markdown

Other editor updates

Functional enhancements

Pausing debug output

Calling Link nodes from the Function node

Sorted node selection lists

Delay node burst mode

Node and security updates

More TLS options

Hardened authentication

Other updates

Under the hood

Node.js 24

Bundling npm

Modernised developer setup

Full Changelog

Community

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