Best practice for installation of node-red and custom node

Hello guys,

I'll need your help today because I'm new in node app and node red and I have two big questions about how to correctly structure and where installed stuff that's I can't solve alone...

First : I've seen one topic about which is better between an local or global installation but I'm still asking myself about it, if someone have any argument for any side ?

Second : In my project I have a lot of custom node but I still don't where is the best place to install them : In /.nodeRed or in node-red folder of the npm node-modules or directly in node-modules of npm. Now i've installed all my custom node in node-red -> node-modules.

I'm working on a window computer
Thanks for any response in advance,

Maurice

I prefer having everything as local as possible.

See this post: Multiple node red instances

That has the advantage of running multiple instances with different node sets and possibly different versions of Node-RED.

As for your second question:
Install all custom nodes in your workspace (where the flows.json is stored, .node-red by default) and setup this workspace as NodeJS project with a package.json (npm init). That way you can keep track of your dependencies.

I'd also recommend versioning each workspace as Git repo.

Hi Maurice, welcome to the forum.

Well as a proponent of local installs, I will try to put both sides in balance. I will also add a 3rd option just for fun.

Which of these is "best" for you will depend on your knowledge, willingness to learn, desire or need to gain maximum flexibility and so on. Only you can work that out. :wink: It should also be noted that you should be able to mix and max these approaches if you really want to (though I can't say that I would personally recommend that).

Global Install

  • This is the standard and therefore arguably by far the easiest installation.
  • It is good for people who are not overly familiar with their OS's filing system or how node.js and npm work and who don't want to be bothered to find out (that is not a criticism by the way).
  • It allows for multiple instances to be run if needed but all instances must use the same version of Node-RED.
  • It doesn't "pollute" your home folder with the node-red and many other required node.js modules.
  • It is standard and most tutorials and explanations assume that this is the way it is installed.
  • It makes the node-red command global so you can run it from anywhere.

Local Install

  • This is a more "node.js way" of installing - global installations being good for exposing global commands but may sometimes be less secure.
  • It is a more self-contained installation. Everything can be in 1 place under a single folder structure. This makes it easier to back-up everything together. But it doesn't force you to work this way, you can keep your userDir folder separate if you like.
  • It allows you to run different instances of Node-RED using different versions. Good for testing major Node-RED upgrades and for testing custom nodes or flows against different versions.
  • You are in control. You know where everything is because you chose to put it there.
  • You control access to all files and folders and so this can be a more flexible installation. You could also have different instances of node-red on the same device with different folder/file access levels. Possible development and test instances on the same device.
  • A good way to create a more portable installation of Node-RED since the whole folder structure can be easily copied/archived, etc.
  • It is my personal belief that this is also the best approach for people who want to learn how Node.js and/or Node-RED works. But then again, maybe that's just my warped mind!

Containerised Install

  • Uses either Docker or snap to containerise the installation.
  • Isolates Node-RED from the host OS.
  • Allow running multiple, independent instances of Node-RED, possible using different versions.

Adds significant hidden complexity however and requires good knowledge of the container technology to isolate and fix issues. Also likely to have higher resource requirements than running separate instances in other ways.

Experience from the forum suggests that a decent knowledge of Docker/snap is recommended.


There is some additional information that I wrote in a recent blog post:

3 Likes

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.