We do have a generic version control appliance; or GitLab either of which could serve the purpose, but they are more designed for code, rather than documents so I don't think they are an ideal solution to your woes. Having said that, if you wrote your policy docs in reStructuredText then they can be easily rendered in pretty html. But that's probably a job for more of a techy type person rather than an office admin...

There are quite a few open source doc managers floating about online but I have no recommendations and you'd need to install them yourself.

Thanks for the server request. I have added it to our issue tracker as a "feature request".

Although it's well worth noting that unfortunately, we have a rather large backlog of requested new appliances and we're a relatively small team, with a number of competing priorities. Currently I'm primarily focused on developing our next major release; v16.0 which is based on Debian 10/Buster. There is no ETA yet but hopefully it will be ready soon.

Currently, the only way to push this forward, would be for someone within the community (perhaps you?!) to develop the build code. Whilst it does require some Linux know-how, I'd be more than happy to provide coaching and assistance in developing that if you or anyone else is interested.

I've never tried to set it up myself, but on face value, it appears fairly straight forward... The only thing that jumps out at me is that in the dependencies section (I looked at Ubuntu, which should be near enough for our purposes), it suggests installing 'python-dev', 'python-pip' and 'python-setuptools'. But it then goes on to explicitly create a python3 virtual env?! I assume that they actually mean the python3 versions of those packages. I.e. 'python3-dev', 'python3-pip' and 'python3-setuptools'.

As for creating a new TurnKey appliance, our build tools are bundled into an appliance of their own, called TKLDev. There is a fair bit of documentation, both here on the website and within the docs section of the GitHub TKLDev build code repo.

If you plan to have a crack at creating a new appliance, I would recommend that you have a bit of a read through that. In essence, it's actually fairly straight forward (although as per always, the devil is in the detail). Essentially appliance build code consists of a Makefile; which specifies common makefiles to use, trying to keep to the DRY (don't repeat yourself) philosophy. A plan; containing the package to install (again leverages common plans). Then conf scripts (generally bash/shell script or scripts in the conf.d dir) and overlay files (i.e. files laid over the top of the existing filesystem. At build time, packages are installed first (from both common and specific plans), then overlay files applied (common first, then local) and finally conf scripts (as per overlays).

I'm happy to assist further if you end up having a go. Although, if you're struggling to get it installed and running, then building an appliance will not make it any easier! As a general rule, documenting a stand alone install is usually the first step I take to building an appliance.

One last thing I should note though, is that the documentation talks about "the sandbox" and "root.sandbox". Unfortunately as of v14.2, that is currently broken and doesn't work as described in the docs. As we don't use it internally (it was added to make things easier for external developers) it hasn't got the priority it probably deserves, but hopefully we'll circle back to that, and fix it up at some stage...