BookStack vs Outline vs Wiki.js: Which Self-Hosted Wiki for Your Homelab?
A self-hosted wiki comparison for homelabs: BookStack, Outline, and Wiki.js, judged on what they actually cost you in dependencies, RAM, and setup time.
Documentation is the hole in almost every homelab I’ve seen, including mine. You build the thing, you get it working, and the knowledge of how it works lives in three places: your head, your shell history, and a comment in a compose file you’ll never find again. Then you don’t touch that service for eight months, something breaks, and you’re reverse engineering your own setup at 11pm.
What I actually use right now is not a wiki. It’s a folder of plain markdown files synced across machines with Syncthing. That works better than people expect, and for a long time it was fine. Where it stops being fine is search across a couple hundred notes, sharing anything with another person, and pasting a screenshot without thinking about where the image file goes.
So this is the evaluation I did before deciding whether to move, and what I’d stand up if I did. Three names come up constantly for this: BookStack, Outline, and Wiki.js. They look interchangeable in a screenshot. They are not, and the difference that matters most isn’t the editor.
The three in one line each
- BookStack: a PHP app that organizes everything into shelves, books, chapters, and pages. Opinionated structure, plain setup.
- Outline: a Notion-style knowledge base with real-time collaborative editing and the best-looking interface of the three.
- Wiki.js: a Node app with more editors, more auth modules, and more configuration surface than either of the others.
All three are free, open source, and run in Docker. That’s where the similarity ends.
The real cost is dependencies, not RAM
The thing nobody puts in the comparison table is what each app drags in behind it. On a budget homelab, where you’re likely running a mini PC with 16GB and a service count that keeps creeping up, this is the number that actually decides things.
| BookStack | Outline | Wiki.js | |
|---|---|---|---|
| App runtime | PHP | Node.js | Node.js |
| Database required | MySQL / MariaDB | PostgreSQL | PostgreSQL (also supports MySQL, MariaDB, SQLite) |
| Also requires | Nothing else | Redis, plus an external auth provider | Nothing else |
| Containers to run | 2 | 3 plus your identity provider | 2 (or 1 with SQLite) |
| Built in local login | Yes | No | Yes |
That Outline row is the single most important line in this article, so I’ll say it plainly: self-hosted Outline has no built-in username and password login. You must wire it to an external authentication provider, whether that’s Google, Slack, Azure, or a generic OIDC provider you run yourself. If you already have an identity provider, that’s a shrug. If you don’t, “install a wiki” quietly became “install an identity provider, then install a wiki,” and you’ve turned a twenty minute job into a weekend. That’s a fine trade if SSO was on your list anyway, and I’ve written up the Authelia route if you want to go there deliberately. It’s a bad surprise if you just wanted somewhere to write down how your VLANs are configured.
Wiki.js with SQLite is the other end of that spectrum. One container, one file, no database server. It’s not what I’d pick for something I intend to keep for years, but it’s a genuinely useful way to try the thing before you commit a Postgres instance to it.
BookStack: the structure is the product
BookStack makes a choice most wikis refuse to make. Content goes into a fixed hierarchy: shelves hold books, books hold chapters, chapters hold pages. You don’t get to invent your own organizational scheme, and there’s no infinite nesting.
That sounds like a limitation and it is one, and it’s also the reason I’d hand BookStack to someone who has never kept documentation before. A blank wiki with unlimited freedom is exactly how you end up with forty orphaned pages and no idea what’s current. BookStack’s structure means the decision of where a page goes is already mostly made for you. “Networking” is a book, “VLAN setup” is a chapter, and the page about your switch config goes inside it.
It runs on PHP with a MariaDB or MySQL backend, which puts it out of step with the rest of a typical homelab stack if everything else you run is on Postgres. In practice that’s one more container and one more thing to include in your backup routine, not an actual problem. The editor does both WYSIWYG and markdown, search covers page content out of the box, and permissions go down to the individual page if you ever need to share part of the wiki with someone without opening all of it.
The knock on BookStack is that it looks like documentation software from a company, not a personal knowledge tool. If you want something that feels like Notion, this isn’t it. If you want a place where the docs are organized whether or not you’re feeling disciplined, this is the one.
Outline: the polish is real and so is the tax
Outline is the nicest of the three to actually write in. Real-time collaborative editing, a clean interface, keyboard-driven navigation, markdown under the hood so you’re not locked into a proprietary format. If you’ve used Notion and wanted that without the subscription or the cloud, Outline is the closest self-hosted answer.
The cost is the stack. Postgres, Redis, the app itself, and the authentication provider problem above. Recent versions let you keep uploaded files on local disk instead of requiring S3-compatible object storage, which removed one of the older headaches, but you should confirm the storage configuration before you start pasting screenshots into pages you care about.
There’s also a design assumption worth naming. Outline is built for teams. Collaborative editing, comments, and shared workspaces are the center of the product. In a homelab where the user count is one, you’re paying the operational cost of a team tool to get an interface you like. That can absolutely be worth it. Just be honest with yourself that you’re buying the writing experience, not the collaboration features.
Wiki.js: flexible, with a caveat you should know
Wiki.js gives you the most options. Multiple editors including markdown, WYSIWYG, AsciiDoc, and raw HTML. A long list of authentication modules. A genuinely deep admin UI. And the feature I find most interesting for a homelab: it can sync content to a Git repository, so your documentation exists as real files with real version history somewhere other than a database blob.
That Git sync is the argument for Wiki.js over the other two. It’s the same instinct that makes me prefer plain text config I can diff over a database I have to remember to export, and it means the wiki’s content survives the wiki. If the app breaks or you decide to move, your pages are markdown files in a repo, not a Postgres dump you now have to parse.
The caveat: Wiki.js 2.x is the stable line, and the 3.0 rewrite has been in development for a long stretch while 2.x has seen relatively quiet maintenance. That isn’t abandonment and 2.x works fine today, but it is the kind of thing you want to check the current state of before committing years of notes to it. Look at the repository’s recent activity yourself rather than taking my word or anyone else’s.
Side by side
| BookStack | Outline | Wiki.js | |
|---|---|---|---|
| Best for | Structured docs you’ll actually maintain | The nicest writing experience | Flexibility and Git-backed content |
| Setup difficulty | Easy | Hard without existing SSO | Easy to moderate |
| Organization model | Fixed hierarchy | Free-form nested docs | Free-form page tree |
| Editors | WYSIWYG and markdown | Markdown-based rich editor | Markdown, WYSIWYG, AsciiDoc, HTML |
| Content portability | Export per page or book | Markdown export | Native Git sync |
| Multi-user story | Role and page-level permissions | Built for teams | Extensive auth modules |
| Runs on one small container | No, needs a DB | No, needs Postgres and Redis | Yes, with SQLite |
What I’d actually run
For a homelab, BookStack. Not because it’s the most capable, because it’s the one whose cost matches the job. Two containers, local login that works on day one, search that finds things, and a structure that keeps a personal wiki from turning into a junk drawer. When the whole point is documenting infrastructure so future-you can fix it, “boring and organized” beats “beautiful and free-form.”
Pick Wiki.js instead if the Git sync genuinely matters to you, or if you want to test the idea of a wiki at all with a single SQLite container before you commit anything. Pick Outline only if you already run an identity provider, or you’ve decided you want one. Coming to Outline cold and discovering the auth requirement halfway through is the most common way this goes badly.
All three are a fine addition to a starter self-hosted stack, and none of them will move the needle on your power bill. This is a category where you’re spending setup time and a few hundred megabytes of RAM, not money, which is unusual and worth taking advantage of.
Before you stand one up
Two things, both boring, both the reason people lose their wiki.
Put it behind your reverse proxy rather than an exposed port. All three of these have web interfaces and login pages, and a wiki full of your infrastructure documentation is close to the worst possible thing to leave reachable from the open internet. Nginx Proxy Manager plus Tailscale is the setup I’d use, and it’s the same pattern I apply to everything else on my stack.
And back up the database, not the container. This is where wikis differ from most of what you self-host. Your content lives in Postgres or MariaDB, not in a volume full of readable files you could piece back together in an emergency. A container snapshot without a database dump is not a backup. If you’re new to running database-backed services in Docker, the compose basics guide covers how the volumes fit together before you start writing things you can’t afford to lose.