I may be more than slightly biased but I really like the fact that this could install multiple instances of Node-RED on a system. 
Given that all of my installs use local, not global installs.
In my opinion, local installs are always better and fit better with standard Node.js approaches as well. Their potential downside is that they might appear slightly more complex to a beginner. But here, that is completely nulled by having a good installer.
Our installation procedure (in case of Windows deployments) includes some additional manual steps:
We have a few additional manual steps (installation of custom-developed nodes, connectivity & security settings etc.) but these are proprietary.
Any idea, why the Node-RED docu propose the opposite way of action?
@knolleary I think we need some background info here...
History?
That's the way it started - from even before my time with Node-RED (is it really over 10 years now! OMG!!!). It was something I raised early on but the general opinion was that it was easier to install as a global for people with no experience. I disagree, but that's just my own opinion. You trade off having to create a location to install node-red vs not needing to do that but not knowing where the heck it did go if you ever need to know. To be fair, you don't often really need to know. But if you do, then a global install is more complex. Then there is the sudo vs non-sudo (or Windows equivalent) which often causes confusion and then problems if you get it wrong. When installing locally, this is rarely an issue that even occurs to people.
However, either way works - so not really worth worrying over.
Yes history. Two original reasons. First if you installed nodejs locally then it didnāt auto create the correct start command in the path so you couldnāt just type node-red and have it run. And second when packaging up as a deb file for installing on Pi, they should install to /usr space (which is global) and not /home. Messing with /home is a no no.
Status update:
Collect NR version data
Detect 'global' NR installation
Verify 'known' custom path installations (bookkeeping in Registry)
Add new installation configuration to installation setup
Add existing NR installation (currently unknown) to installation setup
Remove installation from setup
Give a name to an installation
Configure installation (port, autostart, ...)
Looks like a first version could be 'ready' within the next one or two weeks ... to stress test the UI. It's becoming a quite complex beast...
Is it really worth including versions 1 and 2 ? Do they still work latest node18 ?
Indeed... 1.x is no longer maintained. We should not be encouraging new installs of it.
The installer pulls this data from npm.
This is what npm tells us:
This gives the impression that 1.x still is in maintenance - and in fact it is installed numerous times per week!
While I fully agree to remove it from the installer: Wouldn't it as well make sense to remove any tags from v1.x ... or change it's tag to sth like v1-OBSOLETE ?
There are users who are 'stuck' on 1.x, despite it not being maintained. I doubt there are users who look at that list and, given a free choice, go for 1.x.
But the main point here is any new installer we provide should really only list the active release - 3.x.
If we get any requests for supporting older versions, we can revisit.
It's becoming a quite complex beast...
The goal here needs to be simplicity for the user. The more options you provide, the harder it is to use. I appreciate your comment may be more about what is going on under the covers than what it shows the user... but less is definitely more.
As a separate comment, we can get this into the node-red org on github this week and figure out what else is needed for an initial release. Would be great to 'launch' this with Node-RED 3.1 in the next couple of weeks.
Status Update:
UI Test candidate is available
You may download the installer from the Assets of its repository.
There's one issue that will immediately jump up your screen: Windows is complaining that this software is not signed. This calls for a code signing certificate - if we really intend to put it into the Node-RED ecosystem.
May the discussion be started... 
Very Nice! @ralphwetzel 
My only comment maybe is to have the port be intelligently set, 188x;
But only if you donāt select upgrade ā¦
and avoid port 1883 
(or at least warn it is "Usually reserved for MQTT")
So yes on balance maybe donāt add this feature for version 1
I wish it was always on in windows. The automatic setting method in CMD is cumbersome.
Status update:
First Beta candidate available
npm rebuild
Status update:
Second Beta candidate: Feature complete
npm rebuildSome technical details - for information as well as for discussion.
userDir for the global installation is (default). userDir for the non-global installations is their installation directory.Next steps:
@TotallyInformation Which (additional) 'approaches' concerning the autostart topic did you have in mind?
Well, on Linux, only systemd is considered which is reasonable since that covers probably 90% or more of installations.
Windows is a bit more complex because you have two basic methods. Either turning your app into a service or creating an entry in the Task Scheduler. Both have consequences and options.
At the least, users will need to know what startup approach has been used.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarksā¢ or registeredĀ® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy