Node-RED

The path to Node-RED 5.0

2025-12-03T00:00:00+00:00

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

2025-12-01T00:00:00+00:00

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!

2025-10-28T00:00:00+00:00

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

2025-07-29T00:00:00+00:00

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

2024-06-20T00:00:00+00:00

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

2023-09-06T00:00:00+00:00

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

2023-02-23T00:00:00+00:00

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.

Version 3.0 released

2022-07-14T00:00:00+00:00

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

The Change Log has the full list of changes in this release, but here are the highlights.

Migrating from Node-RED 2.x
Editor Features
Runtime Features
Node updates
What’s next?

Migrating from Node-RED 2.x

Here are the key points you need to know when migrating to Node-RED 3.x.

Node.js 14.x or later required
Internet Explorer no longer supported
Choose if you want to enable the Stopping Flows feature
Choose if you want to disable the Runtime Diagnostics feature
Choose if you want to switch to the Monaco editor (if you haven’t already).

Editor Features

We have (finally) added a right-click context menu in the workspace. This gives you quick access to a lot of built-in actions in the editor and should help users discover more of the features available.

Picking what options should be in the menu hasn’t been a simple task. There are a lot of things that could have been included - so we had to get the right balance between having the right options there and making it too long and hard to find.

Junctions

We have introduced a new special node type called junction that can make it easier to route the wires in a flow.

Unlike the various ‘no-op’ nodes that have been published to the community to help achieve similar results, the Junctions are far more compact and less obtrusive in the flow.

When you hover over a Junction, it expands to show input and output ports. You can move the junction by dragging its body, or add a wire by click/dragging on one of its ports - just as you do with nodes.

Junctions do not appear as regular nodes in the palette or flow outline, but can be added through the quick-add dialog (Ctrl-click in the workspace) or the new Context Menu.

You can also insert a Junction into an existing wire by slicing through it with the mouse by holding alt-shift when dragging across the wire. Note that some OS might use that same combination to move the active window, so this won’t work there. We don’t yet have a way to allow the mouse actions to be customised, so users affected by that would have to use the other methods to add Junctions.

When hovering over a node name in the Debug sidebar, a new tooltip shows the full location of the node. This is useful when working with subflows, making it much easier to identify exactly which node generated the message.

Clicking on any item in the list will reveal it in the workspace.

Continuous Search

When searching for things in the editor, a new toolbar in the workspace provides options to quickly jump between the search results.

We’ve added a pair of new actions to help navigate the results:

core:search-next - shortcut: f
core:search-previous - shortcut: shift-f

We’ve also added some more predefined searches, including the ability to restrict the search to the current flow.

Default node names

The Debug, Function and Link nodes are now given unique default names when they are added to the workspace.

This capability could be added to any node, including contrib nodes, via their onadd function. We chose just this initial set as they were the ones that would most benefit from having a name applied.

A new action has also been added that will apply an appropriate default name to any selected nodes that don’t currently have a name:

core:generate-node-names

Monaco Text Editor

We added the monaco editor component as an alternative to the default ace editor a year ago in the 2.x release. It has proven to be very stable and provides a much richer user experience.

With 3.0, we have switched over to monaco as the default editor. New installs of Node-RED will pickup the change - existing installs will need to update (or remove) the codeEditor entry in their settings file.

The ultimate goal will be to remove ace entirely in the 4.0 release next year.

Remembering cursor position

The editor now tries to restore your cursor position when you reopen a node’s edit dialog. This is super handy with the Function node, amongst others, where you don’t want to have to scroll back to where you were working each time you open the edit dialog.

Accessing previous welcome tours

We introduced the Welcome Tour back in 2.1.0 and it has been updated for each release. With this release, we’ve added a way to access the tours of the previous releases in the Help sidebar:

Runtime Features

Editing stopped flows

We’ve introduced the optional ability to run Node-RED without the flows themselves running. We already had Safe Mode that achieved a similar result, but with this new feature, you can stop and start the flows directly from the editor. The runtime will remember the state of the flows so when Node-RED starts up, the flows will stay in the same started/stopped state.

This feature is not enabled by default. To enable it, you need to add the following to your settings.js file:

runtimeState: {
   enabled: true,
   ui: true
}

With that set, you get a new option in the Deploy menu:

Clicking that option will stop the flows running, but you can continue editing them and deploy changes. Whilst stopped, the Inject/Debug node buttons will be disabled.

When the flows are stopped, the menu shows a start option instead:

Diagnostic Report

We’ve added a new admin endpoint that returns information about the runtime and the system its running on. This can be used to quickly gather information when reporting an issue.

Within the editor you can see the information it returns by running the ‘Show System Info’ action.

We have taken care to ensure this does not return anything sensitive. In some cases it will indicate if a particular setting is set, but not what value it has been set to.

We realise that not everyone will want to have this exposed depending on how they use Node-RED. For that reason, the endpoint can be disabled by adding the following to settings.js:

diagnostics: {
    enabled: false
}

Multiple static folders

The runtime has long-supported the ability to serve a folder of static content as part of its HTTP handling. Useful for providing static resources to webpages and the like.

With this release you can now specify multiple folders to serve from and, more importantly, to specify the http path each folder should be served from.

See #3542 for details on how it can be used.

Node updates

Dynamic Link Call node

We added the Link Call node in Node-RED 2.1. It lets you create a flow that calls out to a Link In node and get a response back. The main limitation was you had to hardcode what Link In node you wanted it to call.

With this release you can now use msg.target to set the name of the Link In node it should call.

Environment Variables in the Template node

The Template node can now access environment variables using the syntax:

My favourite colour is {{env.COLOUR}}.

Debug node message count

The Debug node has a new option to report how many messages it has received in its status output.

Predefined HTTP Request headers

The HTTP Request node now allows you to set request headers in the node’s edit dialog - rather than having to always pass them in as message properties.

What’s next?

As happened with 2.0, we’ve overrun our plan for getting 3.0 released in April. But the series of beta releases we have been doing have really helped improve the overall quality of this release.

The main challenge has always been getting enough time and attention dedicated to keep the release cadence going.

Our next scheduled main release will be 3.1 in late October/November. As ever, we have a healthy backlog of items to keep us busy - but ultimately it depends very much on the feedback from the 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 2.x is now in maintenance mode - we won’t be added any new features to it, but we will do maintenance releases with fixes as needed. In fact, we’ll have a long overdue 2.2.3 release in the next couple of weeks.

Introducing the Node Scorecard

2022-01-31T00:00:00+00:00

Last year we asked the community what frustrations they were experiencing as both users and creators of 3rd party nodes. One of the common themes was that it was hard to judge the quality of a node just from looking at its page on the Flow Library.

Based on that feedback, we’re now introducing Node Scorecards.

The scorecard provides a summary of a Node across a range of things such as whether it follows our naming guidelines, does it have a valid license applied and does it clash with other packages in the library.

When we first introduced the Flow Library, we chose not to act as gatekeepers to what can be shared, beyond some very basic checks on the nodes. The scorecard doesn’t change that, but it does help start to highlight where a node may need some additional work to meet the recommended best practices.

We’ve been running the tool against new submissions to the Flow Library for a couple months now so there are scorecards for many of the recently updated nodes. You’ll now see a link to ‘View scorecard’ in the sidebar of a node’s page on the library, along with a summary of the scorecard.

Click through gives you a more detailed view of the scorecard - listing out all of the checks made. You can find out more about the purpose of each check by clicking on the i link on the right hand side.

Changing our recommended naming convention

As part of the work to improve the overall quality of the Flow Library, we’re making a change to our naming guidelines for node modules.

Previously, we asked that if a module’s name started with node-red-, that it use node-red-contrib- to distinguish it from modules maintained by the core project.

We now recommend that newly published modules use a scoped name - such as @myScope/node-red-sample. That can be your own user scope, or an organisation scope.

If you use a scoped name, there are no further requirements on the name. You could use @myScope/node-red-sample or just @myScope/sample - although having node-red in the name does help to associate the module with the project.

If you are forking an existing package to provide a fix, you can keep the same name but released under your own scope. But please keep in mind, forking should always be a last resort if the original maintainer is not responsive to your contributions.

We won’t be asking anyone to republish their existing modules under this new naming convention, but the scorecard will flag up any newly added modules that don’t follow this new convention from today.

Node Developers

The tool underlying the scorecard is node-red-dev - a new command-line tool that developers can run locally against their own code to check for any possible issues before publishing to npm. Many of the checks are quick and easy to fix - much better to do so before sharing with the community.

You can run the tool either against a path on your local machine or against a package already published to npm using the appropriate flags, and you’ll get the results in the console

The Future

This is the first step in improving the quality of our node ecosystem, over time we will add more checks to the scorecard. It doesn’t currently examine the code of a node, but that is certainly something that could be explored.

There’s also a lot more that node-red-dev could do for Node Developers beyond the scorecard check. For example, using it to bootstrap development of a new node module, with all of the best practices pre-applied.

If that’s something you’re interested in contributing to, please do come talk to us in the forum.

Version 2.2 released

2022-01-27T00:00:00+00:00

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

The Change Log has the full list of changes in this release, but here are the highlights.

Highlights
Node Updates
What’s next?

Highlights

Search History

The main search dialog now keeps a history of your searches. This makes it easy to repeatedly search for the same thing.

Remembering zoom/position

Under the View section of the main settings dialog, there are a pair of options to get the editor to remember the zoom level of the workspace, as well as the scroll position of individual tabs.

This is helpful if you prefer to have the workspace zoomed in - you don’t have to reset it every time you reload the editor.

Aligning nodes

With snap-to-grid enabled, nodes with hidden labels (for example, link nodes) can now be aligned on either their left or right edge. This will make it easier to get everything to line up in the workspace

Detaching nodes

You can now delete a node from the middle of a flow and have the wiring automatically repair itself in the background.

This is done by holding the Ctrl (or Cmd) key when you press delete.

You can also detach a node from the flow without deleting it:

We haven’t assigned a default shortcut for that, but you can assign one yourself in the Keyboard pane of the Settings dialog. The action is called core:detach-selected-nodes.

Selecting multiple wires

You can also select multiple wires by ctrl-clicking on them.

When you select multiple nodes, we also highlight any wires between them. This can make it easier to follow a flow once you have selected it.

Slicing wires

We’ve added the ability to remove wires by slicing through them. You do this by holding the ctrl (or cmd) key, then dragging the mouse with the right-hand button pressed:

Subflow Output labels

If you have set output labels for a subflow template (via the Appearance tab of its edit dialog), the editor will now display those labels whilst you are editing the subflow template.

Predefined Environment Variables

We have added a number of predefined Environment Variables that provide access to information about the node, group and flow at the point they are evaluated.

NR_NODE_ID - the ID of the node
NR_NODE_NAME - the Name of the node
NR_NODE_PATH - the Path of the node - this is a new concept that we’ll explain below.
NR_GROUP_ID - the ID of the containing group
NR_GROUP_NAME - the Name of the containing group
NR_FLOW_ID - the ID of the flow the node is on
NR_FLOW_NAME - the Name of the flow the node is on

The guide for using Environment Variables in your flow is available here.

For example, in a Function node, you can do:

const functionName = env.get("NR_NODE_NAME")
const flowName = env.get("NR_FLOW_NAME")
msg.payload = `I was sent by Function '${functionName}', on flow '${flowName}'`
return msg

Node Paths

This is a new internal property of Nodes we’ve added that helps identify where exactly any node is within the overall flows.

The following may sound a bit abstract, and it’s something most users can skip over. But it can be useful when creating your own subflow modules with custom logging messages inside.

If a NodeA is on Flow1, it will have a path of Flow1/NodeA.

That isn’t very interesting, but it gets more interesting when dealing with subflows and, in particular, nested subflows.

When we create an instance of a subflow, all of the nodes in the subflow are given randonly generated ids. If that node logs an error, you see the generated ID, not the ‘true’ id as appears in the editor. It gets harder when you have nested subflows because you need to be able to identify which instance of the node, in which instance of the subflow to go looking for.

The path property can solve that by providing the ids of the top-level flow and each subflow instance to identify exactly where the node is.

This property is exposed in the following ways:

For node authors, it is available as this._path on the node object.
Inside the Function node, it is exposed as node.path.
It is also available as the environment variable NR_NODE_PATH when evaluated by a node.

Node Updates

The JSON node will now attempt to parse Buffer objects if they contain a valid string
The TCP Client nodes support TLS connections
The WebSocket client node now lets you specify a sub-protocol to connect with

What’s next?

Next on the release plan is Node-RED 3.0, scheduled for the end of April.

This coincides with Node.js 12 reaching its end of life.

As ever, if there are any particular features you’re interested in, now is a great time to jump into the forum to share your feedback.

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

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

Version 3.0 released

Migrating from Node-RED 2.x

Editor Features

Context Menu

Junctions

Debug Path Tooltip

Continuous Search

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