I saw this comment on r/selfhosted last week:
“Trilium hits a wall on multi-user since storage assumes one author per node. Wiki.js gets you there but the Postgres + Node stack is overkill for a team of 5. LeafWiki splitting the difference — markdown on disk + SQLite + single Go binary — is the combo I’ve wanted for years.”
The comment captures one kind of comparison well, but it leaves out where DokuWiki fits. That matters, because DokuWiki is still one of the most obvious answers when someone says “I want a self-hosted wiki backed by files, no database.”
It has been that answer for a long time, and for good reason.
The honest comparison
DokuWiki stores content as plain text files. So does LeafWiki. Neither uses Postgres. Neither requires Redis. Both run on a single server. Both need a reverse proxy in front for TLS termination if you are exposing them to the internet — that part is the same.
So what actually differs?
The markup. DokuWiki uses its own wiki syntax. It is not Markdown. There is a Markdown plugin, and it works, but it is still a plugin rather than the default. If most of your existing workflow already lives in Markdown, LeafWiki will usually feel more natural. If your team already knows DokuWiki syntax, that advantage matters less.
The stack. DokuWiki is PHP. That is not a problem if you already run PHP somewhere. But if you do not, you are setting up PHP, configuring a web server to serve it, and keeping both updated. LeafWiki is a single Go binary that you run directly or via Docker, so the operational model is simpler. That simplicity is intentional — a self-hosted wiki shouldn’t need an ops team.
The editor. DokuWiki’s editor is functional. LeafWiki has a live split-view preview, Ctrl+V image paste, search and replace, and a table of contents. If you spend a lot of time writing internal docs, those small workflow details can make the editing experience feel smoother.
The maturity gap. DokuWiki has been in production for twenty years. It has a large plugin ecosystem, a well-understood permission model with granular ACLs, and a long tail of edge cases already handled. LeafWiki is still much newer. If you need that level of maturity today, DokuWiki is the safer choice.
Who should pick what
The honest answer: it depends almost entirely on whether you are migrating or starting fresh.
If you have a DokuWiki with years of content and a team that knows the syntax, the switching cost is real. The plugin ecosystem, the granular ACLs, the maturity — those things exist and they matter. Migration is doable, but it is not free.
If you are starting from scratch in 2026, the tradeoffs look a bit different. Standard Markdown means your content fits more naturally into other tooling your team may already use. A single binary means setup is straightforward. And an editor with live preview and Ctrl+V image paste can make day-to-day writing more comfortable.
LeafWiki is also more explicitly shaped around documentation. The tree-based structure works well when pages have a clear parent-child relationship: runbooks, internal guides, product docs, onboarding material, or technical notes that need to stay organized over time. That kind of hierarchy is not automatically better for every team, but it can be a better fit when your docs benefit from an intentional structure rather than a flatter collection of pages.
DokuWiki solved a real problem, and it still does. LeafWiki is closer to what I wanted for a smaller self-hosted wiki with a more modern writing flow, but that does not make it a universal replacement.
For some teams, DokuWiki will still be the better fit. For others, LeafWiki may be the simpler place to start.
Try the LeafWiki demo or check the GitHub repo.
If you find LeafWiki useful, consider sponsoring the project — it helps keep development going.