api-scripts VS bs

Not really specific tools for that purpose, but our api-scripts repo has a collection of examples that use the API, which could be used as a basis for building something more specific. Within the readme there is also a variety of more extensive community project, some of which may also be useful here.

You could run a script that uses the API to export all content to PDF/HTML. I have a basic example of this here in our API scripts repo.

Their Script

To add to this, some people script and cron regular exports via the API. I have a basic example script here.

Also, if it helps, we have API script examples here and there is an existing bash cli build here.

If you wanted accessible non-DB copies of your content, this is possible via a couple of options. Some users script exports of all their books. I have an example of this here in our API script examples repo. Alternatively you could write out raw content to plain files on the system via hooking into events using our logical theme system. I have an basic example of doing this for HTML format content within this blog post.

I found this this evening

Can't give too much advice in regards to Confluence, but in regards to BookStack import the REST API is probably the best best. API docs can be seen on our demo instance here. API usage examples, and community projects/scripts, can be found here if it helps. You might be able to find existing confluence to bookstack scripts. Came across this in a search but not sure how feature complete or up-to-date it is.

Also, if it helps, we have API script examples here and there is an existing bash cli build here.

A wood-fired stove, wood-fired cooking stove, a few different types of axes and a crosscut saw to provide the former with fuel from dead trees.

Oh, wait? Those are not 'boring technologies', they're just 'old technologies' - nothing boring about them.

Computer-related 'boring' technologies in daily use: the nix tool set - shell, awk, sed, perl, curl and the like plus some relatively newcomers like jq and xidel to handle web-related things. Vim in one of its guises. Instead of fighting npm and the myriad of ever-changing related tools to provide CLI tools I tend to use the former to open up APIs to those who live on the command line. All the claims of shell being unsuitable for such projects notwithstanding these tools tend to work reliably while being self-contained - a single file pulling in a single config file and sometimes a common functions file. No transpilers needed, no packers, no shitload of libraries, no nuthin' - just a few hundred lines of 'boring' shell like e.g. this BookStack* API CLI [1] I made a week and a bit ago.

Storage: MDADM and LVM hosting ext4 instead of ZFS because I like the separation of tasks and the greater flexibility over the latter.

Web: PHP because it works and performs well enough. Java when needed, also because it works and performs well enough. Pure Javascript instead of the jumble of libraries/frameworks/new-ways-of-doing-things because those all too often end up being old-unmaintained-ways-of-doing-things.

System: C over C++/Rust/Zig over Go/Nim/Crystal because it is the Lingua Franca which has stood the test of time and will probably outlive most of those mentioned languages.

Communications: SMTP/IMAP + XMPP and when needed Telegram over Slack/Teams/whatever.

Cloud? Only when I have the hardware under my own control and within reach. The server lives under the stairs, the backup server under some other stairs in another building.

Wired Ethernet over WiFi when possible.

Older hardware, usually rescued from a dumpster or something similar.

[1] https://github.com/Yetangitu/bs