BookStack vs Wiki.js

Documentation is the one thing you self-host that has to be readable years after you stop paying attention to it. That reframes the comparison. The editor, the theme and the search box matter for a week. What matters in year five is whether the project still ships, whether the storage format is something you can read without the application, and whether an upgrade you postponed for eighteen months is still possible.

On that test these two are not close.

The live fact: Wiki.js 3.0 has still not shipped#

Wiki.js announced a 3.0 developer preview in October 2022 with a beta promised shortly after. As of September 2026 the newest stable release is v2.5.314, dated 1 May 2026. The 3.0 line is still tagging prereleases, 3.0.0-beta.550 carries a 7 September 2026 date, and they are labeled not for production use. The project's own roadmap gates the beta on full feature parity with 2.5.x and attaches no date to it.

So what you would actually install is 2.x, and 2.x is in maintenance. It received roughly six releases in the last twelve months, and they are dependency bumps and build fixes rather than features. We classify its maturity as legacy for exactly this reason: it works, it is stable, and it is not going anywhere new.

There is a second-order problem. Version 3 drops every database engine except PostgreSQL. Wiki.js 2.x supports PostgreSQL, MySQL 8.0+, MariaDB 10.2.7+, MS SQL Server 2012+ and SQLite 3.9+. Version 3 keeps only Postgres. If you install on MariaDB today because you already run one, you have signed up for a database migration stacked on top of an application migration whose shape nobody can describe yet. If you install Wiki.js anyway, install it on PostgreSQL.

BookStack, meanwhile, shipped v26.05 and then v26.05.1 through v26.05.4 behind it. Different problem, same test, opposite result.

What the spec table hides#

The two look nearly identical on paper: both idle around 260 MB, both are two services, both do arm64, both have native OIDC. The rows that matter are maturity and datastore, and neither is a number. Read the table for the licence difference (MIT versus AGPL-3.0) and the database constraint, then come back here, because the operational gap between them is not visible in any specification.

What "boring" actually buys you#

BookStack is a Laravel app on MySQL with one maintainer working on it full time since 2015. The concrete evidence for calling it boring is its version-specific upgrade notes page: between v24.05.1 and v26.05, across two years of releases, the only documented manual steps were a folder permission change for export fonts and a revision visibility change. Everything else was three commands:

git pull origin release
composer install --no-dev
php artisan migrate

From v25.02.1 onward you can swap the composer step for ./bookstack-system-cli download-vendor, which removes the need for Composer on the host entirely.

That predictability is the product. Page content is rows in MySQL with images in public/uploads and attachments in storage/uploads. There is no plugin ecosystem, so there is nothing to rot. A mysqldump plus tar -czvf files.tar.gz .env public/uploads storage/uploads themes is a complete backup, and a live file copy is safe because uploads are immutable.

The one thing that ruins a restore: losing APP_KEY from .env. It encrypts stored secrets including multi-factor seeds, so a perfect database dump restored under a fresh key locks every MFA user out with no self-service recovery. Put .env in the backup set, not just the uploads. Backups that actually restore covers rehearsing that before you need it.

The uncomfortable truth about the boring option#

Boring does not mean unattended. BookStack's patch releases between features are almost entirely security fixes, and you have to take them. The v26.05.1 through v26.05.4 series alone covered attachment permission leaks, a remote-code-execution path in ZIP import, draft page permission bypasses, and OIDC/SAML identity mismatching on IDs that differ only by case.

An instance pinned to last year's tag is not stable, it is unpatched. Budget for a monthly pull. That is the real ongoing cost of BookStack, and it is why we score it 2 rather than 1 on ops load.

There are two more costs worth naming:

• No official Docker image. LinuxServer.io and solidnerd carry the community ones. That means the PHP version inside the image, the file ownership model and the upgrade timing are the image maintainer's decisions, not BookStack's, so you read two sets of release notes. The supported path is a git checkout with Composer, and shared hosting is explicitly unsupported.
• MySQL or MariaDB only. Postgres and SQLite are declined, permanently. On a Postgres-standardized host this means a MariaDB container that exists purely for the wiki.

Shelves and books versus a graph#

BookStack's structure is a fixed four-level tree: shelves contain books, books contain chapters, chapters contain pages. It is deliberately rigid. There are no backlinks, no transclusion and no graph view, and there is no real-time co-editing on the same page.

If you are coming from Confluence that model is familiar and the migration is mostly mechanical. If you think in bidirectional links you will hate it, and you should look at Trilium Notes for personal use or Outline for a team, with the caveats in Outline vs Docmost.

Wiki.js is flat paths with per-page and per-path permissions, three editors that coexist (Markdown, WYSIWYG, AsciiDoc), and the Git storage module. That module is the genuine reason to choose it: pages exist as Markdown files in a repository you control, which is a disaster-proof export that BookStack cannot match. Point it at a repository nobody rewrites history in, on Forgejo or Gitea, and accept that bidirectional sync will occasionally wedge and need a manual resync from the admin panel.

Two Wiki.js constraints people discover late: it will not run under a subpath, so example.com/wiki is not an option and you allocate wiki.example.com before you start, and all assets live in the database, so uploads inflate your Postgres volume rather than a directory.

Migration risk, which is the real question#

Ask what happens when you want to leave.

From BookStack: export per page, per book or per shelf as Markdown, PDF, HTML or plain text, via the UI or the API. The database schema is plain MySQL rows you can query with mysql if the app will not start.

From Wiki.js 2.x: if you enabled the Git storage module you already have Markdown files, which is the best exit in this comparison. If you did not, everything including images is inside Postgres and you are writing SQL or a script against the pages table. Enable the Git module on day one for this reason alone, even if you never look at the repository. It does not carry users, permissions or assets, so it supplements the pg_dump, it does not replace it.

The verdict, by situation#

The default is BookStack. Choose Wiki.js when the Git module is a requirement you can name, not a feature you find appealing, and when you have accepted that the version you install today is the version you will run for years.

What to do next#

Pick the domain before you install either one, because Wiki.js hard-requires a dedicated subdomain and BookStack builds absolute URLs from APP_URL. Reverse proxy and TLS covers the Caddy block for both. If SSO is on your list, both support it free and Single sign-on for self-hosters explains what a single user actually gains. Set the backup up on the same day you set the wiki up, using Backing up a running database for the dump and An update strategy that does not lose data for the monthly patch habit. Browse Documents if neither shape fits, and check Replace Notion if this is a migration rather than a greenfield install.