Node red multiple instances

Gr8 Steve, could you explain the process of doing this. i would like to do this step by step and try exposing node red in multiple ports(say 4) for my needs.
Thx in advance.

assuming windows (you didnt specify)...

  • Create 4 folders...
    • c:\node-red-1880
    • c:\node-red-1881
    • c:\node-red-1882
    • c:\node-red-1883 (avoid 1883)
    • c:\node-red-1884
  • open 4 cmd windows
    • Start >> Run >> cmd >> {enter}
    • Start >> Run >> cmd >> {enter}
    • Start >> Run >> cmd >> {enter}
    • Start >> Run >> cmd >> {enter}
  • In cmd1...
    • node-red -p 1880 -u c:/node-red-1880
  • In cmd2...
    • node-red -p 1881 -u c:/node-red-1881
  • In cmd3...
    • node-red -p 1882 -u c:/node-red-1882
  • In cmd4...
    • node-red -p 1884 -u c:/node-red-1884

The 4 folders will get populated with your flows & any nodes you add via pallete


If you want to make them services - try searching in this forum for a posts mentioning NSSM



thanks, will NSSM impose security risks ?

In what way?

All it does is wrap a non service application into a service.

If necessary, set the "logon" properties in NSSM to a limited account, then node-red will run under that context.

I see no differences to running from a command line in that regard.

Thanks, will check this out ..

Hi, could you please explain how to set NSSM to run two separate instances at boot in windows 10?
I've tryed several ways without success. Till last week I just run node-red at boot with NSSM without problem, now I need to run a different node-red instance on the port 1881. By the command line it's not a problem (node-red -p 1881 -u c:/....", infact I created a dedicate folder that has been populated with it's own files as suggested on the previous posts. I even modify the settings.js file inside this folder changin the "uiPort: process.env.PORT || 1881"
But I'm not able to make this service running.
I configure it as following:
Path: C:\Users\1\AppData\Roaming\npm\node-red.cmd
Startap directory: C:\Users\1.node-red-two
Arguments --settings "C:\Users\1.node-red-two\settings.js" > "c:\temp\node-red\node-red-two.log"
for what I've understood the problems is the node-red.cmd file called inside the path.
Could someone please help me? Should I create a new path? Which files should I copy in and how modify them?
Many thanks

If you launch each instance with a different workspace using -u path you don't need to pass the port as parameter.

Just set the uiPort in each settings.js directly, and remove process.env.PORT, otherwise this will take precedence.

I use NSSM for our Windows machines for exactly that and it works like a charm.
However, I'm not launching a cmd script, but use node.exe as service executable and pass red.js -u red_workspace_path as app parameters.

1 Like

FWIW, I run multiple instances on Node-RED on a number of Linux servers, and in each case, I run the different instances under distinct userids and run Node-RED under that userid, and of course, instantiated from separate .node-red root directories each with their own settings.js file and port, of course.

This is surely not a very efficient way to do this, but it works for me and is easy to manage, in my particular cases.

1 Like

Should perhaps be an FAQ.

How can I run multiple instances of Node-RED on the same server device?

  1. Use the command line settings to point to a different userDir folder.

    node-red -u /data/userDirectory

    That lets you use different flows and configuration settings but only allows a single version of Node-RED.

  2. Install the Node-RED npm package locally rather than globally.

    This gives you not only the features from 1 but also allows you to run different versions of Node-RED in parallel. The alternate-node-red-installer shows you how to do that.

  3. Run Node-RED in a container such as the Docker container.

For running Node-RED on system startup, please see the Starting Node-RED on boot page in the docs.

1 Like

4. use nginx as a forward proxy to multiple instances running on separate ports...

I'd probably think of that as a way of hiding the dirty little secrets of my Node.js apps rather than another way of running the instances. :slight_smile:

Had you mentioned using Phusion Passenger or IISnode I might have agreed though since I think that they can both actually start up a node.js app.

Really though, even they fit into the 3 mentioned I think (though happy to be disagreed with).

BTW, had a fit of blog updates so posted this there as a Node-RED FAQ.

Which I've just noticed has the wrong URL! so while that takes you to the right place for now, it is going to change I'm afraid. I obviously failed to rename the file after copying the previous post :frowning:

Phew, Hugo to the rescue. It allows me to specify an alias in the metadata for the post that automatically will redirect you from the old URL to the new one. Hugo is one fabulous piece of software!

1 Like

Node-RED multiple instances cont.
I was wondering I do not want to have to update all of these instances of Node-RED with each upgrade on any random node update. I need to install all of the extra nodes on my first instance. How could I get the same install to run different programs with the same install and node installs?

Cannot the other program .config(s) and package.json be mentioned in the command line only? keeping the references to the installed nodes?


If they are all on the same server device, you could simply replace each node_modules folder with a soft link to a single original. You might want to make the links read-only though to prevent unfortunate incidents. Similarly, you could link the config.js file as well.

Harder if you need to work across multiple servers. Then, having your own Docker image would probably be the best approach. Otherwise, you will need to do a lot of copying over your LAN.

So, sorry to be naive, but context matters as I am confused what you mean by this.

If you have two instances of a userDir folder on the same server and run 2 instances of Node-RED - each pointing at its own userDir. Only one of those instances actually needs to be "real". The other could be a filing system alias, more commonly known in Linux as a soft link. Look up the Linux command ln (that's an ell).

In that case, both instances of Node-RED would always be identical and you would doubtless get issues as each instance tries to change things.

So instead of making the whole userDir an alias, instead make userDir/node_modules an alias. That folder contains all of the installed Node.js packages that are used by Node-RED (with the exception of those installed directly by the master Node-RED install package that is). All of the nodes that you install are contained in packages that go into that folder.

So by making node_modules an alias, it will always be identical to the "real" folder.

Now you only ever need to install nodes into 1 folder and all of the others will be identical. Of course, you will have to restart the other instances (those that point at the linked folders) when you change something.

1 Like

Windows 10 here.

shortcut? would that work the same way?

No, a shortcut wouldn't work. That is actually a special file.

However, what would work is .... a soft link :grinning_face_with_smiling_eyes:

Yes, Windows NTFS filing system has always supported soft and hard links. There are commands to create them but there is also a handy piece of software that lets you create and change them from Windows explorer as well.

In Windows you also have another option called a "Junction". This actually behaves like a "hard link" rather than a soft link and you need to be careful with it because if someone deletes the junction, it will actually delete the original folder. Soft links are safer because deleting the link only deletes the link, the original is left alone. The other advantage of soft links is that they work across filing system boundaries - e.g. from 1 physical drive to another.

"TotallyInformation" :thinking: My mind is blown. Totally awesome info. I did not know this.... I'll look into this soft-link business. it's very intriguing. but, I'll have to Google it.

Kind Regards,

Wikipedia NTFS links...
Hard Links ... share samte MFT entry in the file system.
Symbolic Links file path ref
Junction points. Directories only ref.

mklink /j <Link> <Target>

/j -- this parameter creates a Directory Junction.
<Link> -- This parameter specifies the name of the symbolic link
<Target> -- This parameter specifies the path that the new symbolic link refers to.

I've used this for many a long year - one of the first things that I install on a new Windows installation: