Self-hosted wikis shouldn’t need an ops team · LeafWiki<br>Blog ·<br>21 May 2026<br>Self-hosted wikis shouldn’t need an ops team

I like self-hosting.<br>But I do not self-host a wiki because I enjoy operating a wiki.<br>That distinction matters.<br>The wiki is not the point<br>A wiki is usually not the system you want to operate. It is not the core product. It is not the part users pay for, and it is usually not the reason someone starts self-hosting.<br>It is the tool where knowledge is stored that would otherwise get lost: runbooks, incident notes, architecture decisions, deployment steps, backup procedures, operational assumptions, and all the small details that otherwise end up in Slack, tickets, or someone’s head.<br>A wiki should be boring and easy to operate.<br>If I need a wiki to document how backups work, I do not want to first write a backup procedure for that exact wiki. And I definitely do not want to learn the hard way that my wiki data lived in a database I did not back up properly.<br>A wiki should just work. And my data should remain usable and readable even without the software.<br>A documentation tool should reduce operational risk, not become a new source of it.<br>Self-hosted does not mean operating yet another system<br>Self-hosted is often understood as if users wanted to operate software just for the sake of operating software. In practice, it is usually about something else: control, privacy, durability, cost, independence, compliance, or simply keeping your data close to you.<br>It is about ownership.<br>Not about patching yet another database, understanding yet another migration path, auditing yet another plugin system, or building yet another backup strategy that only works as long as the application itself is healthy.<br>For a wiki, this distinction matters.<br>The value of a wiki is not the application. The value is the knowledge inside it.<br>If the application disappears, the knowledge should still remain useful.<br>Markdown as a storage format is an operational decision<br>That is why the storage format matters.<br>For a self-hosted wiki, Markdown is not just a pleasant writing format. Markdown is an operational decision.<br>Markdown files are boring in the best possible way. They can be opened in any editor. They can live in Git. They can be backed up with normal file backups. They can be searched with grep, copied with rsync, and rendered by many different tools. And they are still understandable years later without the original application running.<br>This changes the failure mode.<br>If the wiki breaks, the documentation is not gone. If the application disappears, the content is not trapped. If the server dies, the most important part of recovery is getting the files back.<br>I have nothing against databases. Many systems need them, and many teams operate them well. But for a small wiki, I think the question is fair: does the knowledge itself really need to disappear into application-specific state?<br>Of course, Markdown does not make all operational work disappear. Self-hosted is never magic. You still need deployment, authentication, updates, backups, and monitoring if the wiki matters to your team.<br>But the important question is: how much specialized knowledge does the wiki itself require?<br>A small engineering team, a homelab user, or a self-hoster should not need to understand the internal data model of their wiki just to trust their own documentation. Nobody should need an ops team for the tool that is supposed to help them do ops better.<br>Portability keeps getting more valuable<br>Text-based formats have another advantage: they are easy to index, summarize, transform, diff, and move into other systems. The less knowledge is hidden in application-specific state, the easier it becomes to reuse.<br>That does not mean Markdown is perfect.<br>Markdown is not a database. It does not automatically solve permissions, collaboration, search, diagrams, attachments, or publishing. A good wiki still needs a good interface on top.<br>But the interface should not own the knowledge.<br>The wiki should be a layer on top of the documentation, not the prison it lives in.<br>Fewer moving parts, more trust<br>For small teams and self-hosters, this model makes the most sense to me: Markdown as the storage format, a simple web interface on top, as few moving parts as possible, and data that remains useful even if the tool disappears.<br>Self-hosted should mean: I control my data.<br>Not: I inherited another production system.<br>A wiki should make knowledge easier to preserve, not harder to operate.<br>At the end of the day, I do not want to operate a wiki.<br>I want documentation I can trust.<br>LeafWiki is currently pre-1.0<br>I am building LeafWiki with exactly this motivation: a self-hosted wiki with Markdown as the storage format, a simple interface on top, and as little operational baggage as possible.<br>LeafWiki is still in an early phase. If you want to try the idea or give feedback:<br>Demo: demo.leafwiki.com<br>GitHub: github.com/perber/leafwiki

← All posts