I’ve never installed NR “globally”. From the start I’ve been using the instructions here
https://nodered.org/docs/embedding
to embed NR in another app (which is in fact strictly node-red). One of the main advantages (in my opinion but maybe I’m missing something ?) is that I can use npm on NR juste like any other NodeJS module and so I can have as many NR versions as I want… and also NR updates are not a problem anymore …
I’m not an expert but it seems to me like a great solution. Are there any drawbacks to my approach ? Are there any disadvantages ? What am I missing if I’m not installing NR globally ?
1 Like
In my personal opinion, the only downside is the inability to run Dave’s excellent update script (if you are running on Linux). 
In truth, for beginners at least, your approach is slightly more complex to start. You do, of course, have to translate many install instructions and other help information as most will assume a standard installation.
There is one more disadvantage. You need to create your own startup command. The default installation on Linux at least (certainly on a Raspberry Pi) automatically creates a systemd startup script for you. Installed this way, you have to do that for yourself.
For myself, I’ve long run Node-RED as a standard installation (not global) on my “live” system which is on a Pi. NR is installed in a folder under the default Pi user’s home folder and the userDir for Node-RED (normally ~/.node-red
is installed in a folder called .data
under Node-RED’s folder.
This makes it very easy to back up the whole thing including Node-RED itself and all the data and modules. Something that has saved me a lot of time and heartache on the few occasions where major updates to Node-RED have caused serious issues (generally doesn’t seem to happen any more! Yay Nick & Dave!) .
The other advantages are that you can run multiple instances of Node-RED in parallel if you wish. Also, those instances can be completely different versions of Node-RED. Great if you need some flows using the latest version but have some legacy flows that don’t yet work on the latest. With the introduction of npx
, you could even run different instances using different versions of Node.JS.
The final advantage is that you are not having to use a global npm install which can introduce security issues onto your server platform. Installing locally is the “Node” way and generally always recommended except when installing a Node.JS module that provides a command line interface that you might want to use as a system command.
3 Likes
I always install Node-RED locally on my side. My workflow looks somewhat like this:
mkdir myNodeREDProject
cd myNodeREDProject
npm init (to create a package.json file)
npm install --save node-red
I then usually add a start script in the package.json file for quick tests:
{
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "node node_modules/node-red/red.js -v -u ."
}
For persistence I use pm2 to run the local copy. A typical pm2 process file would look like this:
nodered_pm2.yaml
apps:
- name: myNodeREDapp
script: ./node_modules/node-red/red.js
args: ["-v", "-u", "."]
That file lives in the myNodeREDProject folder and I would start it like this:
pm2 start nodered_pm2.yaml
I also like to hardcode the name of the flow file in settings.js
as it makes it more portable and is not dependant on the hostname.
5 Likes
Yes, similar to me except that I prefer to use systemd to control running rather than PM2, at least on a Pi. I’ve found that PM2 can be rather a resource hog and I’m running so much on my Pi2 now that it doesn’t have too much headroom.
I do use PM2 on my Windows development PC though since I don’t leave Node-RED running all the time there.
1 Like