Most wiki tools start simple and grow into platforms. Plugins, databases, configuration systems, and workflow engines accumulate. Before long, you are managing the documentation tool instead of writing documentation.
LeafWiki takes a narrower view.
The constraints
LeafWiki is built around a small set of deliberate constraints:
Markdown on disk. Your content is plain .md files. There is no proprietary storage format. You can move, backup, or version-control your data however you like.
No external database. LeafWiki uses SQLite internally and does not require you to run or manage a separate database service. One binary, one data directory.
Explicit structure. The tree is not inferred from tags, recency, or AI suggestions. You decide how things are organized, and it stays that way.
Self-hosted by design. LeafWiki is built to run on a server you control. Single binary, Docker image, low resource usage. No SaaS required.
What this rules out
These constraints are intentional. They also rule out certain things.
LeafWiki is not suitable for teams that need real-time collaborative editing. It does not have approval workflows or fine-grained permissions. It is not trying to replace Confluence or Notion.
If you need those things, a different tool will serve you better. LeafWiki is for the use case where you want a structured, fast, self-hosted wiki without the weight of a larger platform.
Where it is useful
Personal technical notes. Team runbooks. Project documentation. Internal guides that need structure but not a platform to go with them.
The core is stable. Full-text search, a Markdown editor with live preview, keyboard shortcuts, image uploads, Mermaid diagrams, backlinks, role-based access.
The next priorities are lightweight organization features such as tags and properties. Development is iterative, shaped by how people actually use the tool.
If that sounds useful, try the demo or view the source on GitHub.