Why a dedicated wiki beats a folder of markdown files

The honest baseline alternative is a folder of markdown files in a git repo, and for a single operator who’s disciplined about committing, that’s a legitimate choice with zero infrastructure cost. What a dedicated wiki buys you is full-text search across everything you’ve written (actually useful once you’re past a few dozen pages and can’t remember which one has the fiber modem’s admin password hint), a web UI that’s editable from a phone without opening a text editor and running git commands, and a structure (books, chapters, nested pages) that keeps growing content from turning into one enormous flat list. None of that matters at ten pages. It matters a lot at a hundred, which most working homelabs quietly cross within a year or two of serious documentation.

BookStack: structured, simple, and built for exactly this

BookStack organizes everything into a strict hierarchy: Shelves contain Books, Books contain Chapters, Chapters contain Pages. That rigidity is the whole pitch. Unlike a flat wiki where organization is whatever convention you impose on yourself, BookStack forces a consistent structure from day one, which for infrastructure documentation (one Book per major system: Proxmox, Networking, Media Stack, Backups) tends to map naturally onto how a homelab is actually organized. Pages support a WYSIWYG editor or raw markdown, your choice per page, and it has a genuinely good built-in diagramming tool (via draw.io/diagrams.net integration) for drawing network topology without leaving the page.

Permissions are role- and hierarchy-based and can get fairly granular (a Shelf, Book, Chapter, or individual Page can each have its own viewer/editor roles), which matters if anyone else in the house gets an account and you don’t want them able to edit the backup runbook. BookStack is a single PHP/MySQL application, straightforward to run in Docker, and has stayed remarkably stable in both its UI and its data model for years, which matters for a tool you’re trusting with infrastructure knowledge you don’t want to re-migrate every time the project pivots.

Wiki.js: flexible structure, more moving parts, modern editor

Wiki.js takes a looser approach: pages exist in a flat or nested tree you define yourself, not a forced Shelf/Book/Chapter hierarchy, which gives more freedom but also more room to end up with an inconsistent structure if you’re not deliberate about it. Where it clearly wins is the editing experience: a modern, Notion-adjacent block editor alongside markdown and a few other source formats, live collaborative editing, and a theming system that’s noticeably more polished out of the box than BookStack’s.

The tradeoff shows up in the stack underneath it. Wiki.js needs Node.js and a database (SQLite, MySQL/MariaDB, or Postgres), and historically has been a step heavier to run and occasionally more disruptive across major version upgrades than BookStack’s slower, steadier release cadence. It also supports pulling content from and syncing to a git repository as a storage backend, which is a genuinely useful feature if you want the “flat markdown files in git” workflow’s portability without giving up the wiki’s search and web UI on top of it. If that git-sync feature is the reason you’re looking at Wiki.js, it’s worth the extra setup weight; if not, it’s one more thing that can need attention during an upgrade.

Outline: built for teams, overkill for one operator but worth knowing

Outline is the odd one out here because it’s genuinely built for a team’s internal knowledge base first, homelab documentation second. It has the most refined editor of the three, strong full-text search, and a document-centric model (documents live in Collections, can be nested under each other, support real-time collaborative editing) that reads more like Notion or Confluence than a classic wiki. It also wants more from its environment: Postgres, Redis, and S3-compatible object storage for attachments are effectively required, not optional, and it leans on OAuth-based login (Google, Slack, generic OIDC) rather than a simple built-in username/password scheme by default.

For a single-operator homelab, that’s a meaningfully heavier footprint for features (real-time multi-cursor editing, team permission structures) that mostly go unused. Outline earns its place on this list because if you’re already running the other pieces it wants (an existing Postgres instance, MinIO for S3-compatible storage, an OIDC provider like Authentik from the SSO article on this site) the marginal cost drops a lot, and the editor quality is the best of the three. It’s the right pick if more than one or two people are going to be actively writing documentation, not just reading it.

Comparing the practical dimensions

Structure model: BookStack forces a Shelf/Book/Chapter/Page hierarchy, which imposes order automatically. Wiki.js and Outline both use looser, nestable trees that give more freedom and more opportunity for drift if you’re not consistent.

Resource footprint: BookStack is the lightest, PHP and MySQL, comfortable on nearly any homelab host. Wiki.js needs Node.js plus a database and sits a step heavier. Outline is the heaviest by a clear margin, wanting Postgres, Redis, and S3-compatible storage as hard dependencies.

Editing experience: Outline’s editor is the most polished and the most collaborative. Wiki.js is close behind with a modern block editor and live co-editing. BookStack’s editor is capable (WYSIWYG or markdown) but visibly plainer than either.

Diagramming: BookStack’s built-in draw.io integration is the strongest fit for network topology and rack diagrams without leaving the app. The other two rely on embedding images or external diagram tools.

Permissions: BookStack offers the most granular built-in permission model, down to individual pages. Outline supports team/collection-level permissions well. Wiki.js has permissions but they’re less fine-grained than BookStack’s.

Login model: BookStack and Wiki.js both support simple local accounts out of the box, with SSO as an option. Outline is built around OAuth/OIDC login by default, which is friction for a single operator who just wants a username and password.

Portability of content: Wiki.js’s git-sync backend gives the clearest path to plain-text, version-controlled pages. BookStack and Outline both store content in their own database, exportable but not natively git-native.

Picking one for your homelab

If you’re one operator who wants something light, stable, and structured with minimal fuss: BookStack. It runs comfortably on whatever’s already hosting your other self-hosted apps, the forced hierarchy keeps infrastructure docs organized without you having to enforce a convention yourself, and the built-in diagramming tool covers the network-map use case directly.

If you want a more modern editing experience and especially if you want your wiki content synced to a git repo as the source of truth: Wiki.js. The heavier stack is worth it specifically for the git-backend feature; without that specific need, it’s extra moving parts for a nicer-looking editor.

If more than one or two people in the house are actively writing documentation, not just reading it, and you’re already running the Postgres/Redis/S3 pieces it needs: Outline. Its collaborative editing and team-oriented permission model are the actual reason to choose it, and they’re wasted on a single-operator setup.

Bottom line

A wiki doesn’t prevent an outage the way backups do, but it’s what turns “I’ll remember how I set this up” into something that survives six months, a hardware swap, or someone else needing to step in. BookStack if you want the simplest, most structured option that just works. Wiki.js if the git-sync backend specifically earns its extra weight for you. Outline if real documentation collaboration across more than one person is the actual requirement. Whichever one you pick, the value comes from actually writing in it, not from which one you chose, so favor whichever option removes the most friction from you opening it up at 11 PM to write down the thing you just figured out.