Node-RED

Version 4.0 released

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

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

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

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

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

Node.js 18 or later

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

Editor Updates

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

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

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

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

Customising config nodes in Subflows

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

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

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

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

Timestamp formatting

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

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

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

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

Multiplayer Mode

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

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

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

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

Better background deploy handling

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

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

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

Improved Diff view for moved nodes

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

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

Better feedback for read-only users

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

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

New Config Node selection UI

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

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

Other updates

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

Runtime

Faster deploys for large flows

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

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

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

Updated JSONata

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

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

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

Other updates

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

Node Updates

A better CSV node

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

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

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

Updated Proxy Handling

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

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

Other updates

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

Full Changelog

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

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

Community

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 3.1 released

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

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

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

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

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

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

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

Editor Updates

Change notifications on tabs

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

A bigger workspace

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

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

Locking Flows

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

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

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

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

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

Hiding Flows

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

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

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

New Group User Experience

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

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

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

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

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

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

Group-level scope for the Catch/Status

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

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

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

Adding images to node/flow descriptions

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

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

Mermaid Diagrams

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

Global Environment Variables

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

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

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

New subflow environment variables

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

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

Changes to how Environment Variables are evaluated

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

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

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

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

Linking to Node Help

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

Deprecating synchronous access to JSONata

This is one for node authors rather than end users.

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

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

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

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

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

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

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

Improved wiring for horizontally aligned nodes

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

Here is a before/after pair of screenshots:

Runtime Updates

Individual http middleware for httpStatic routes

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

See #4229 for the details.

What’s next?

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

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

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

2023 Community Survey

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

Update: the results are now available here.

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

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

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

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

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

Update: The survey is now closed.

Version 3.0 released

Thu, 14 Jul 2022 00:00:00 +0000

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

Mon, 31 Jan 2022 00:00:00 +0000

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.

Node-RED

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

Default node names

Monaco Text Editor

Remembering cursor position

Accessing previous welcome tours

Runtime Features

Editing stopped flows

Diagnostic Report

Multiple static folders

Node updates

Dynamic Link Call node

Environment Variables in the Template node

Debug node message count

Predefined HTTP Request headers

What’s next?

Introducing the Node Scorecard

Changing our recommended naming convention

Node Developers

The Future

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