Projects - per project settings.js

[snicho99]

Hi there,

I'm loving the projects feature, really makes it easier to collaborate on things and beats the hell out of trying to diff the flows.json file.

Big question though - how do I set per project node-red settings? Things like port listened to, whether https is required, authentication etc etc.

I've been googling and this very old design document here: https://github.com/node-red/node-red/wiki/Design:-Projects

Intimates it was the intention to include a per project settings.js (or settings.json - it's inconsistent) but it doesn't seem to be picking that up for me.

Any pointers? Or is it not a thing yet...

[TotallyInformation]

how do I set per project node-red settings?

Unfortunately, you cannot do that using projects. Projects share the same Node-RED instance including the settings.js file, useDir and installed nodes.

However, it is fairly easy to have multiple Node-RED instances instead. That gives you completely independent settings, nodes, etc.

In fact, if you look at my alternate-node-red-installer repo on GitHub, you will find something that may help.

That will create you a master folder, install node-red into it, create a userDir (data) folder in it, make sure that settings.js exists and creates a package.json file with suitable npm start scripts. It is cross-platform.

The only thing it currently doesn't do is install node.js for you and it doesn't create a systemd script (for auto-running on Linux) since it is cross-platform - one day I hope to add that as well but it is quite complex as it needs to know about user ids.

Once you have used the script twice to create node-red instances in two different master folders, you can change the settings.js to adjust the ports and any other settings you want to.

You can even have different versions of node-red running simultaneously this way - though my script doesn't cater for that itself just now. However, you can just use the script as a guide for doing your own installation.

[Steve-Mcl]

Not knocking @TotallyInformation excellent info above, but as you already have node red installed, you can very easily launch another instance.

See this post

[TotallyInformation]

I always forget that since I long ago stopped using a global install Thanks for the reminder.

Personally, I still find my method better because you get the ability to run different versions & you can back the whole thing up very easily and even move it to a different device because everything is in one place.

[snicho99]

Thanks guys

Already good with launching separate instances with different settings files.

It's kind of more that there is a bunch of things in a settings thats tied to what I think of as part of the 'project' that would be nice to just roll into the git repo and not have to worry about rolling different bits and pieces out to setup the environment. Bound port is just an example, but also things like httpNodeRoot, httpAdminRoot, adminAuth; settings in particular seem to me that you'd think of as specific to a project, rather than a particular host.

Your helper @totallinformation looks nice I'll definitely have a look at it.

I have a confession actually - that whilst we use git for the kinds of projects we have we often have all sorts of wierd stuff in the environment, I've taken to running our node-red instances inside a VM and just sharing the VMs around the dev team. Just faster for a dev to get up and running. Overhead is MASSIVE compared to just moving around flows.json etc, but who cares on a gigabit network?

[dceejay]

Well you can use ${environment variables} syntax for node properties. That may help also for things that are machine specific.

[knolleary]

It's kind of more that there is a bunch of things in a settings thats tied to what I think of as part of the 'project' that would be nice to just roll into the git repo and not have to worry about rolling different bits and pieces out to setup the environment. Bound port is just an example, but also things like httpNodeRoot, httpAdminRoot, adminAuth; settings in particular seem to me that you'd think of as specific to a project, rather than a particular host.

There is nothing stopping you adding a settings.js file to your project and telling Node-RED to use it instead of the default one via the -s command line option.

However, if you change the project you'd need to restart Node-RED to point it at the new settings file.

[snicho99]

@knolleary Yeah that's what I'm doing currently - and happy to continue to do so.

It's just given that node-red packages can be managed inside node-red... seems strange that settings can't be... Know what I mean? And that thing I googled implied it was at least on the road map - and was looking to see if it was actually implemented, of if there was a demo somewhere.

If not - all good. Very interesting to see the different way people are using the tool!

[TotallyInformation]

I have a confession actually - that whilst we use git for the kinds of projects we have we often have all sorts of wierd stuff in the environment, I've taken to running our node-red instances inside a VM and just sharing the VMs around the dev team. Just faster for a dev to get up and running. Overhead is MASSIVE compared to just moving around flows.json etc, but who cares on a gigabit network?

That is a perfectly reasonably approach when you have the resources.

Very interesting to see the different way people are using the tool!

Yes, one of many advantages to Node-RED and its use of node.js. And always nice to be reminded of all the different ways you can do things.