Hi There,
Just want to announce that FlowHub.org is now available in a local-first, no-GitHub required solution.
Background:
FlowHub.org provides visual change management (aka version control) on top of GitHub. FlowHub Local (aka FlowHubⓁ) is a local-first server for the FlowHub.org nodes, replacing the GitHub requirement.
FlowHubⓁ provides a local gitstore for managing change made to flows, locally, no internet connection is required. FlowHubⓁ is used in conjunction with the FlowHub.org nodes but provides a local gitstore, replacing GitHub.
Installation:
FlowHubⓁ has a client-server architecture with both client and server being installed in Node-RED instances. The client and server are both Node-RED node packages that can be installed into any Node-RED instance.
More in the installation guide (pdf).
Purpose:
Integrated Visual Change Management in Node-RED.
Basically it's now possible to install a flow inside a Node-RED instance that interfaces between Node-RED and git, and allows for versioning of flow tabs. Also flow code can be shared across multiple instances of Node-RED by installing the FlowHub client into Node-RED and pointing it at the FlowHubⓁ installation.
Also included is a Webiliser that presents any flow in a web page for downloading older revisions of flow code and comparing older revisions of flow code:
This is probably interesting for those companies/individuals that have an extensive collection of flows that are shared across multiple instance of Node-RED. Also those that need to maintain such flows and setups.
FlowHubⓁ is dogfood technology: I maintain it using FlowHubⓁ:
Nice work, Gregorius.
What I find particularly interesting here is the combination of local versioning with a visual comparison of individual flows/tabs, rather than treating the whole Node-RED project as a single block.
My own Node-RED setup has grown quite large over the years and is constantly being modified and extended, so keeping track of what changed, when it changed, and being able to compare or restore a specific flow can become increasingly useful.
For that kind of environment, having the history stored locally and being able to inspect changes visually looks much more practical than digging through raw JSON diffs.
I can definitely see this becoming useful in larger, continuously evolving Node-RED installations.
Thank you for your kind feedback, much appreciated 
If you do try it out (or if anyone else does), feedback/questions much welcomed. At this stage, it's very much centred around my way of working but I'd like to expand that out (if possible) to support others workflows.
This came naturally to me because I started to treat flow tabs as the smallest unit of code in Node-RED. I found subflows not as useful, perhaps because they could just as well be implemented as flow tabs with using link nodes.
On the other hand, managing many smaller flows does require discipline and organisation. So this might well not be an approach that is a simple as "one click buy"©. As I describe somewhere in the documentation, I have multiple stores with multiple flows so that when I push a flow, I sometimes end up with the wrong store or sometimes flows are duplicated across multiple stores!
The idea behind multiple stores is to be able to work with projects with each project having its own set of flows. This provides a second layer of grouping, besides using square brackets in flow names (which is the grouping within a store). Btw think of "store" as being a repository at GitHub, FlowHub allows using multiple of repositories as storage inside of NR.
Definitely and this was my main reason for creating this. There is a difftool built into Node-RED (when flows get saved by a different instance of NR than the one being used it can be used to review the changes) but that is based on columns and texts. I found that to be sub-optimal for something that is inherently visual, so I wanted something more visual.
Ideally something like MacOS time machine would be the goal 
In my case, I think the potential confusion around multiple stores would probably not be an issue, as I have a single Node-RED project and my main interest would be to save and version individual flows as I modify them. For example, if I change my irrigation flow, I would want to save a revision of that flow; if the same change also affects another flow such as sensors, I would simply save a revision of that one as well. What I would be particularly interested in evaluating is the resource impact. My home automation system runs on a Raspberry Pi 4 with 4 GB of RAM and already hosts a fairly large Node-RED installation, so I would be curious to know whether you have any indicative figures for the additional RAM usage when FlowHub Local is idle, as well as the typical disk growth over time as revisions accumulate. The disk usage probably would not concern me too much, but the runtime overhead is something I would definitely want to understand before adding it to the system.
There is a caching layer that maintains some flow state for the gitstore flow. This is only done for the default store (i.e. in the settings there is one git directory/store that is marked as default). The caching layer is somewhat redundant when using a local installation (I added it for a github backend so that not all commits have to be retrieved, all the time.)
The cache is used to generate the listing of flows in the pull tab, e.g.:
that list is generated by incrementally going through all commits in a repository and checking commit messages (contents of a store is not based on disk rather on commit messages). Doing this every time when the "refresh flow list"-button is prohibitive for a GitHub backed repository, hence the caching layer.
For the local installation, this caching is still done but, as I said, only for the default store. Using any other store and this listing is generated on the fly - since retrieving all commits for a local repository is zero time overhead, even for largish repositories (1000+ commits).
This implies that RAM usage peaks when interacting with the store and not while it's idling. I haven't done any measurements since the amount of RAM is heavily depended on commit count and size of flows being committed - these also pass through NR when committing. Also there is a diff generation operation (when doing the compare) where two versions of the flow are both held in memory. Again, it all depends on flow size.
I'm running FlowHubⓁ on a macbook and it's definitely not the docker container using the most memory!
EDIT:
I would not recommend running the store on the same server as the production Node-RED. Both from a performance and logical PoV - having a different NR installation acting as a store is definitely much better. In the case of a edge Raspberry, installing this on a local machine (i.e. the machine that edits the flows on the raspberry) would be a better approach. After all, starting up a NR on a local machine isn't difficult.
EXactly, indeed, I was just thinking the same (since I do have macbook as my main workstation)
Will this work with gitea?
Yes it should since Gitea is just a view on top of a git repository. The git repository created with FlowHubⓁ can be pushed to a gitea host, i.e. the gitea repository can be configured as a remote on the repo managed by FlowHubⓁ.
FlowHubⓁ interacts directly with the .git directory, i.e. the git database so there isn't anything checked out inside the directory.
