I've no idea how this works, and am taking a guess that github is the IDEAL thing to use for version management.
I am going through a horrible piece of the learning curve and seeing the problems with how I made code.
I write code in function blocks with the mechanics and eye candy all together.
Recent events have shown me the increasing problem doing things this way.
If I have 3 (probably 6) machines that all need a "base line" my way is not nice.
I need to write it with the structure of two parts:
the mechanics and the eye candy as two separate parts.
Not in function blocks as I have been.
So anyway, from the early days, I would have to sit down for HOURS rolling out updates to all instances on the same machine - let alone machines.
Subflows did make life a LOT EASIER.
But there is a problem with them too..... Version tracking.
For now I make myself add the date to the description when I'm editing the node/subflow.
Then I look for the latest dated one and propagate it to the other machines.
But I not familiar with any ..... options to do that.
I'd prefer to keep things in house and not via github.
(Nothing against it/them. For now I'd like to keep control of where things are.)
So if I want to get busy tidying up subflows, I can do a MASTER one; save it, then it gets sent out to all devices using it.
I know that is nothing like how things really work. But for simplicity.....
Are there any programs/systems that allow this? Locally on the local network?
Did you know that FlowFuse exists? There are of course other solutions, but FF allows you to easily manage multiple NR instances in addition to creating versioning.
I'm not sure, but I am don't seem to get my head around how it works.
That is: How it .... connects..... Nah.
Vocab() is rebooting.
It is "conceptual only" to me at this stage.
I have never really dealt with this sort of thing ever in my life.
I get the bigger picture of it, but not in a practical way - if you know what I mean.
(Which I'm guessing you don't. No offence)
So I am not understanding how I would use it.
I don't really have anyone to talk to about it either.
So it is somewhat confusing for me.
Have you thought about having another instance of Node-RED that runs your common flows? Effectively, that instance would be like an API server. You can use MQTT, HTTP (REST API), websockets or one of several other means of intercommunication.
TBH I would probably take a look at your whole setup, you recently posted about how you are using various Rpi servers, which made me think you could probably just use 1 for everything, which would make managing things a lot easier
I still haven't got around to getting a second NR running on THIS machine. (My main computer/NUC)
So with that idea, I could make/update subflows and the like and then have it roll out any new ones to the remote machines....
Hmmm..... interesting.
Steve,
As a base line there are 3 ras pies always on.
Yes, that is sort of an artefact from when I first started and it was a version 1 RasPi.
I couldn't put too much load on it.
As time went on I added the second and WAY down the track added the third.
So why don't I put them all on one machine - say a RasPi 4 or 5?
Well, couple of things:
RasPi 4/5 are not exactly cheap.
But more so.....
Points of failure.
This way if one dies the others pull the weight.
Not that they take over, but there are machines left that can tell me there is a problem.
If I have all 3 on one machine and it fails..... There's not way of knowing until things really don't work.
Maybe not really needed, but it is something in which I am interested and am learning (especially recently) the benefits and (what's the opposite of benefit?) of this method.
I also have a bit of a headache 
