This is not strictly self-hosted per se, but I am looking for your guidance.
I am standing up a wiki. I want it to use available FOSS wiki frameworks, all our self-hosted loving things.
However: the probably of this becoming a moderately trafficked page are high. So I also need to consider scale (cloudflare, captcha, auth, do I use Vercel? etc.), light-weightness (this is a Wiki but not too massive), and all that jazz. This is also someone who won’t like alt-wikis and is a very layman, mainstream audience. So “wikipedia but SEO friendly/article style” is also a plus. It will be less deeply linked than Wikipedia across pages, but is still a repository for info that will be revisited for its different components for a long time.
People with experience spinning up or hosting trafficked wiki pages: what do I do?
Thanks gang.


If scale is a concern, then you want to be reducing drag as much as possible. Database lookups and edits can get expensive, so maybe just avoid them outright: DokuWiki only requires a web server with PHP. It keeps content as plain files, making it easy to serve up and to back up.
But it’s often said that perfection is when nothing can be taken away, so what if we remove PHP as well? In this case, we need the content to already be rendered HTML. And we can do that, since there’s a body of site generation packages that build from Markdown files. I found this one while randomly searching: https://codeberg.org/milofultz/swiki
At this point, it’s just a plain web server that dishes out static HTML files. Such simplicity will withstand most AI scrapers, because the cost per request is now absurdly low. And caching a static site is not particularly difficult. Indeed, if the sum total of the wiki content is small enough, it might even fit into something like Codeberg Pages, which means we’ve eliminated even the web server (though this would depart from c/selfhosted).
What seems to be missing from that swiki package – but is entirely feasible – would be to have all content in Markdown files and live in a Git repo, and the Git history itself is used as the Wiki history. This means your pages would retain the classic wiki change log, so that it can all be generated from a Git repo that’s small enough to keep on a floppy disk.
Simplify, then add lightness.
Shorter version: instead of wiki software, use a static site generated from a git repo. It’s a valid approach. I think emacswiki may have once worked that way. Note that Gitit uses git for version management, so among other things you can copy your whole wiki with git clone. But it also has a built in web editor instead of just relying on git push.