A few weeks ago in the monthly or weekly call I mentioned that maybe on-prem farmOS (which obviously is already a thing) is actually a good strategy to standardize around more explicitly, rather than hosting.
It adds cost (for the hardware) but reduces complexity in some ways because of security and maintenance of a centralized deployment.
I think @mstenta pointed me to NAS systems (and others have posted saying they use them). I found this as a good set of examples around NextCloud using NAS, standardized to really simplify the maintenance so they auto-update from external sources.
I also like this because maybe other open source ag solutions, like SoilStack, Open Food Network, etc. could be packaged together for use on this kind of setup. It may be a lot easier to have things on the same device that way.
I think it would be great to see more options to easily install farmOS locally on NAS devices, Raspberry Pis, etc.
The thing that has been missing from the attempts I’ve seen so far is any form of update or backup logic. It’s easy to install farmOS in a Docker container, but updating and backing up are equally essential if you plan to keep real data in it.
(Updating a Docker image is NOT the only step necessary for updating farmOS! Updating farmOS | farmOS)
So while the convenience of these kinds of deployments is a huge benefit, I worry that they don’t always consider the full lifecycle of maintaining a farmOS instance. I’ve already had to help some others fix their farmOS “app” that they installed on a NAS because these considerations were not taken into account.
The other danger we discussed in the past is that anyone can create these apps and submit them to the NAS app stores… which has the potential to cause reputational harm to farmOS if they don’t work (or worse - lose your data) because they aren’t well built/maintained. So lots of things to think about (as maintainers of the project specifically).
I’d love to break out separate discussions to talk through and tackle each of these points from a technical perspective. eg: “How can we make it so that updating a Docker image is all you need to do?” and “How can we help people who are self-hosting set up a reliable backup (and restore) strategy?”
Yes! I would love that too. We have discussions upcoming in the next 2 months where I think having fleshed out reports on those topics would help validate (or invalidate) some pathways.
There’s also an interesting set of questions about pre-configured deployments that include things like Open Food Network or SoilStack or other tools in the ecosystem… what is the value of joint deployments like that both technically, from a marketing / packaging / sales perspective (ie connecting with user values), and from a maintenance perspective.
Perhaps this is obvious, but there are a potentially very large number of combinations that could arise there… either in terms of the number of “distributions” or the number of distinct configurations (each stack on/enabled or off/disabled) to be supported. i.e. if there’s 3 software stacks there’s 8 unique combinations, 4 stacks = 16 combinations, etc. Of course 3 and 4 of those respectively are just the single stacks we’re already (nominally) supporting.
Agreed - I think the key is here to identify sets of users we want to support, and have default installs + hardware. For example, I could imagine the following:
Individual Producer.
Light hardware
Default software:
FarmOS (pre-installed for the producer type (row, veg, etc.)
Nextcloud (basic file storage)
Farm support organization.
More powerful hardware
Default software:
FarmOS (multi-farm installed w/ related modules)
Open Food Network (food hub option)
Nextcloud (file storage + organizational tools)
SoilStack (soil sampling for farm network).
Then you can standardize this around 2 deployments that you can support for a fixed period (like 4 years or something) before moving to a new version.