Node-RED 0.20.0-beta.4 released

We've just published the next beta on the way to 0.20.0.

For the background on why we're doing betas, please read the post for the previous betas:

The CHANGELOG has the full set of changes.


  • The way the runtime manages subflows has been reworked in anticipation of new features that are arriving in the very near future.

  • When you convert a selection of nodes into a Subflow, the nodes will get moved back up to the top-left corner of the subflow tab.

  • A complete set of German translations have been added to the editor

  • The quick add mode in the editor (Ctrl/Cmd-Click) has had a couple updates. It now displays a placeholder node while the dialog is open. If you use Ctrl/Cmd-Enter to confirm the node to add, it adds the node and keeps the dialog open so you can add another node. This means you can quickly add a chain of nodes entirely from the keyboard (after the initial Ctrl-Click to open the dialog).


Installing the beta

If you want to try out the beta, you will need specify node-red@next when you use npm to update. Without the @next you'll still get 0.19.5.

So on a Pi you'd do:

sudo npm install -g --unsafe-perm node-red@next

Reporting problems

If you hit any problems, please report them either as a reply on this topic, or in the #dev slack channel. Please do not post new topics to the forum regarding the beta as that could confuse users who are not using the beta.

Outstanding work

We still have a small number of issues and PRs to resolve.

Some larger PRs are starting to arrive for work that was planned for 0.21. There's a temptation to merge them sooner rather than later before 0.20.0-final is available - but we'll review them on a case-by-case basis.

We don't want to continually hold-off from 0.20.0-final because another issue or another PR is raised.

The API docs of the modules has had some more work. You can see the latest docs here: There is still, as ever, a lot more documentation needed.


I'm currently testing the beta in a docker container running on a raspberry pi 3.
The docker image was built using "node-red": "0.20.0-beta.4", in the provided package.json that comes with the node-red-docker github repository.

these are the logs when starting the container:

29 Jan 12:54:23 - [info] Node-RED version: v0.20.0-beta.4
29 Jan 12:54:23 - [info] Node.js  version: v8.1.3
29 Jan 12:54:23 - [info] Linux 4.14.27-v7+ arm LE
29 Jan 12:54:25 - [info] Loading palette nodes
29 Jan 12:54:48 - [info] Dashboard version 2.13.0 started at /ui
29 Jan 12:55:03 - [info] Settings file  : /data/settings.js
29 Jan 12:55:03 - [info] Context store  : 'default' [module=memory]
29 Jan 12:55:03 - [info] User directory : /data
29 Jan 12:55:03 - [warn] Projects disabled : set editorTheme.projects.enabled=true to enable
29 Jan 12:55:03 - [info] Flows file     : /data/flows.json

so far so good, after that I get these errors:

29 Jan 12:55:09 - [error] [ui_text:98fc9db.54eaf6] RangeError: Maximum call stack size exceeded
    at Flow.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/Flow.js:287:12)
    at Object.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/index.js:214:40)
    at Flow.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/Flow.js:301:28)
    at Object.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/index.js:214:40)
    at Flow.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/Flow.js:301:28)
    at Object.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/index.js:214:40)
    at Flow.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/Flow.js:301:28)
    at Object.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/index.js:214:40)
    at Flow.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/Flow.js:301:28)
    at Object.getNode (/usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/flows/index.js:214:40)

So this is the first thing that I've seen that didn't occur with beta-3. Node-red started and everything was fine, the dashboard was served but I didn't test further.

At first I tried to update via the palette manager the relevant node (I thought that was the dasbhoard since all the errors pointed to some ui_nodes). after succesfully updating the dashboard to 2.13.1 i restarted the container but some nodes disappeared from the mapped /data directory. upon further inspection the /data/package.json only refers to some of the nodes (which I think are the ones that I installed via the palette manager itself) the other "contrib" nodes were missing from the file system and so, they were unregistered:

29 Jan 12:59:40 - [info] Dashboard version 2.13.1 started at /ui
29 Jan 12:59:56 - [warn] Missing node modules:
29 Jan 12:59:56 - [warn]  - node-red-contrib-amazondash (0.0.1): ButtonPressed
29 Jan 12:59:56 - [warn]  - node-red-node-discovery (0.0.18): discovery, announce
29 Jan 12:59:56 - [warn]  - node-red-contrib-advanced-ping (1.2.0): adv ping
29 Jan 12:59:56 - [warn]  - node-red-contrib-freeboard (0.0.7): freeboard
29 Jan 12:59:56 - [warn]  - node-red-contrib-later (0.0.5): later
29 Jan 12:59:56 - [warn]  - node-red-contrib-mopidy (2.0.2): mopidy-out, mopidy-in, mopidy-config
29 Jan 12:59:56 - [warn]  - node-red-contrib-node-hue (0.9.1): node-hue-out, node-hue-in, node-hue-bridge
29 Jan 12:59:56 - [warn]  - node-red-node-mongodb (0.0.13): mongodb, mongodb out, mongodb in
29 Jan 12:59:56 - [warn]  - node-red-contrib-mongodb2 (0.5.5): mongodb2, mongodb2 in

copied those back from yesterday backup, the instance now is running as expected. but with updated dashboard and those nodes back on the fs, I'm still seeing those Maximum call stack size exceeded errors on start.


two problems, maximum call size exceeded, and nodes missing form fs when updating a node via the palette

Hi @juzam

The Maximum Call Stack size error will be a bug with the beta that needs fixing. The question is what about your flow has caused it.

Can you send me your flow file directly (either as a direct message here, or to

Flows file sent via email :slight_smile:


Hi, not sure if I should start a new thread for this?

I am testing Beta4 to see if Project/GIT operations are now working on windows

It didn't work :frowning: .

NOTE: I have had no luck with pushing to GIT with any version of NR is running on windows 7, windows 10, windows server 2012.

Log of 1st push attempt...

2019-02-03T12:39:04.624Z Push changes : origin/master

2019-02-03T12:39:04.959Z git -c credential.helper= push -u origin HEAD:master --porcelain
2019-02-03T12:39:25.032Z [err] bash: /dev/tty: No such device or address
2019-02-03T12:39:25.043Z [err] error: failed to execute prompt script (exit code 1)
2019-02-03T12:39:25.043Z [err] fatal: could not read Username for 'http://xxxxxxxxx': No error
2019-02-03T12:39:25.066Z rc=128

2nd attempt...

2019-02-03T12:39:48.677Z git -c credential.helper= push -u origin HEAD:master --porcelain
2019-02-03T12:39:58.956Z [err] error: cannot spawn C:\Users\xxxxxxxxx\AppData\Roaming\npm\node_modules\node-red\node_modules\@node-red\runtime\lib\storage\localfilesystem\projects\git\ No such file or directory
2019-02-03T12:40:04.120Z [err] bash: /dev/tty: No such device or address
2019-02-03T12:40:04.130Z [err] error: failed to execute prompt script (exit code 1)
2019-02-03T12:40:04.130Z [err] fatal: could not read Username for 'http://xxxxxxxxx': No error
2019-02-03T12:40:04.152Z rc=128

However, I CD to the project folder and pasted the command NR issued
git -c credential.helper= push -u origin HEAD:master --porcelain
it correctly prompted me for username and password & the push worked.

Other info,

  • node -v : v8.9.3
  • npm -v : 6.6.0
  • Node-red is running from CMD prompt
  • I used a NON admin CMD prompt for the manual GIT push

Any ideas?

Possible issue?

I created a new, vanilla installation (On Windows 10) by:

  1. Create a new folder & cd into it.
  2. npm init -y
  3. `npm install --unsafe-perm node-red@next
  4. mkdir data
  5. Start NR using: node node_modules/node-red/red.js --userDir ./data
  6. Install a node using palete manager
  7. Create a very simple flow
  8. Do a Full Deploy
  9. Stop Node-RED

Then I noticed that I should have a file ./data/settings.js (since ./data is my userDir).

However, it isn't there & has to be created manually. Though Node-RED runs without it, I'm always given the projects prompt if I reload the admin interface.

Hi @Steve-Mcl

I'm not aware Projects weren't working on Windows.

What version of git have you got? git --version

I'm not able to recreate that on my Mac - I see the settings file correctly copied over.

When NR starts, what does it log for the settings file path?

Does ./data contain anything after starting NR?

Hi Nick, the ./data folder is empty when I first start at number 5. Here is the log

λ  npm start

> nr-vntest@0.0.1 start C:\src\nr-vtest
> node node_modules/node-red/red.js --userDir ./data

Running in undefined mode
3 Feb 22:26:03 - [info]

Welcome to Node-RED

3 Feb 22:26:03 - [info] Node-RED version: v0.20.0-beta.4
3 Feb 22:26:03 - [info] Node.js  version: v8.12.0
3 Feb 22:26:03 - [info] Windows_NT 10.0.17763 x64 LE
3 Feb 22:26:04 - [info] Loading palette nodes
3 Feb 22:26:05 - [warn] rpi-gpio : Raspberry Pi specific node set inactive
3 Feb 22:26:06 - [info] Settings file  : \Users\julia\.node-red\settings.js
3 Feb 22:26:06 - [info] HTTP Static    : C:\src\nr-vtest\public
3 Feb 22:26:06 - [info] Context store  : 'default' [module=memory]
3 Feb 22:26:06 - [info] User directory : C:\src\nr-vtest\data
3 Feb 22:26:06 - [warn] No active project : using default flows file
3 Feb 22:26:06 - [info] Flows file     : C:\src\nr-vtest\data\flows_DESKTOP-M1M6R28.json
3 Feb 22:26:06 - [info] Creating new flow file
3 Feb 22:26:06 - [warn]

Your flow credentials file is encrypted using a system-generated key.

If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.

You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.

3 Feb 22:26:06 - [info] Server now running at
3 Feb 22:26:06 - [info] Starting flows
3 Feb 22:26:06 - [info] Started flows

Haha! I can see now that it has picked up the settings.js file from the default userDir location at ~/.node-red. That explains another issue that I was seeing with uibuilder which was using the uibuilder settings from that file. I hadn't noticed that previously.

I assume that it should have created a new settings.js file by copying the master from the location I was running from. Note that I don't have a copy of node-red installed globally but I do have a ~/.node-red folder - bit of an edge-case I'll admit.

Here is the file/folder structure after the first run of Node-RED (before any custom nodes installed or any flows created):


I see you are using npm start - that wasn't in your original steps to recreate. What exactly have you got in your package.json file for that?

It says at the start of the output I shared, all npm start does is run node node_modules/node-red/red.js --userDir ./data

I was hoping you'd share exactly what you have got in your package.json file for that.

Just to remove any possibility of misunderstanding or mistake on my part whilst trying to recreate.

No problem:

  "name": "nr-vntest",
  "version": "0.0.1",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node node_modules/node-red/red.js --userDir ./data",
    "inspect": "node --inspect node_modules/node-red/red.js --userDir ./data",
    "update": "npm install --unsafe-perm node-red node-red-admin",
    "check": "npm outdated",
    "check-data": "cd data && npm outdated",
    "update-data": "cd data && npm update",
    "check-master": "npm outdated",
    "update-master": "npm update",
    "admin": "node node_modules/node-red-admin/node-red-admin.js",
    "adminui": "start http://localhost:1880/red/",
    "ui": "start http://localhost:1880/ui/",
    "log": "sudo journalctl -u nrlive -f -n 0 -o cat"
  "keywords": [],
  "author": "Julian Knight (",
  "license": "Apache-2.0",
  "dependencies": {
    "node-red": "^0.20.0-beta.4"

The scripts are ones I use as standard but I only used the npm start. The effect is the same if you run the command manually.

On Server 2012 -
git version

On Windows 10 -
git version

Log from Win 10 device running NR beta2, node V10.12.0, NPM V6.4.1 ...

4 Feb 13:59:03 - [debug] git -c credential.helper= push -u origin HEAD:master --porcelain
4 Feb 13:59:05 - [debug] [err] bash: /dev/tty: No such device or address
4 Feb 13:59:05 - [debug] [err] error: failed to execute prompt script (exit code 1)
4 Feb 13:59:05 - [debug] [err] fatal: could not read Username for 'http://xxxxxxxxx': No error
4 Feb 13:59:05 - [debug] rc=128


  • git is in path (accessible from any dir)
  • bash is in path (accessible from any dir)
  • git is accessible from in bash also.

So far, from multiple machines, multiple node & NR version, different git installs, I have never gotten this to work unfortunately.

Hi, just to add to your heads up. I tried to activate a remote git today (just to contribute with your investigation). I got the same results. I was able to push the local repository only via the command line. For whatever I try from Node-RED interface I keep being asking to enter the login information for github (I am pretty sure it was correct, as well as the SSH keys).

My environment:

4 Feb 11:26:57 - [info] Node-RED version: v0.20.0-beta.3
4 Feb 11:26:57 - [info] Node.js version: v8.11.1
4 Feb 11:26:57 - [info] Windows_NT 10.0.17763 x64 LE

$ npm -v

$ git --version
git version

Thanks for the back up.

I forgot to mention I tried with SSH key also - similar results to you.

With http instead of SSH I get different (but still unsuccessful) results.

Potentially something to do with stdout / tty on windows?

Thanks @Steve-Mcl @Andrei and @TotallyInformation

I doubt I'll be able to make any progress on this without direct access to a Windows 10 machine. If anyone else is so inclined to delve into the code to help figure this out, I'd be happy to give an intro on slack to the moving pieces that are supposed to make this work.

Bit short on time to delve down to those depths right now unfortunately.

If I get some time, I'll try the same setup on a Pi to see if the same thing happens there.

I'd expect that to work; the unix-like systems are much more consistent in behaviour in how to spawn commands and the way git's credential helper stuff works. I was already aware that Window's has some quirks in this area and I thought I was handling them - but clearly not.

I decided to record a small video to show the issue. In the movie, I leave the dev tools opened to capture any eventual errors in the browser. When I try to push the local repository to github I can see that the issue starts even before I enter the username/password. Note: The issue is not particular to Chrome. Same happens on Edge and IE.

Click to watch