BookStack vs Wiki.js

BookStack forces every page into a shelf, book, chapter and page hierarchy, while Wiki.js 2.x lets you shape the tree with its own page paths. In BookStack, a team decides early where a page belongs before it can be written, and that choice governs how readers browse. In Wiki.js, the page path is the address and the navigation, so structure is set by how each page is named and placed, with storage modules such as Git determining where the content lives on disk. Both models work, but they make different trade-offs for the people who maintain them.

For onboarding, the BookStack hierarchy gives new staff a predictable map: a shelf for a function, books for its processes, chapters for the steps. This helps readers who do not know the wiki's history, but it also means authors must agree on the taxonomy before they write. In Wiki.js, a new contributor can create a page at any path, which is faster on day one and can produce drift over time. Before choosing, run a pilot: ask two or three people outside the documentation team to find a known procedure, and record how many clicks and guesses it takes in each tool.

Reorganizing content is where the difference is most expensive. Moving a chapter in BookStack is a structural action that changes the context of every page inside it, so the team should agree on a naming convention and an owner for each shelf first. Moving a path in Wiki.js is more flexible but can break links that readers and other documents rely on, and if the content is synced to Git, the restructure also becomes a repository change. For finding pages later, BookStack's search and shelf view favor users who know the taxonomy, while Wiki.js favors users who remember a path or title. Confirm search behavior and link redirects with the current release notes and your own test instance, since these details vary by version.

The key point for a team choosing Wiki.js is that the stable line today is 2.x, and 3.0 is not yet a production target. The stable 2.x line now lives in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. The main requarks/wiki repository holds the 3.0 beta, which its README marks as not for production use. A team that deploys 2.x now should pin to a specific 2.x release, track the requarks/wiki-v2 releases page, and treat any move to 3.0 as a separate, planned project rather than a routine upgrade.

Plan for 2.x to be a supported line you run in production while 3.0 matures. Before go-live, stand up a staging instance on the same database engine you will use in production, since Wiki.js recommends PostgreSQL and the search module depends on the pg_trgm extension there. Restore a copy of production content into staging, then test authentication end to end (the identity provider, group mapping and TOTP enrollment), your Git or S3 storage sync, and sideloaded content if you run without internet access. Record which modules and settings you depend on so you can judge a future 3.0 migration against a concrete list. Ask the project for its published migration path and whether 3.0 will support in-place upgrades from 2.x. Those answers are not in the supplied facts, so confirm them before committing a date.

The comparison with BookStack changes here. BookStack's current release is v26.09.1, published on September 29, 2026, after v26.09 on September 24, 2026. Its installation requirements are PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later. Confirm the upgrade cadence and any breaking changes in the BookStack release notes before you set a patching policy, and record the BookStack and Wiki.js versions you run together so that both upgrades stay on your change calendar. If your shortlist depends on a stable upgrade path with fewer open questions about the platform's next major line, weigh that against Wiki.js's dual-line situation as part of the decision.

The longest stretches in either project are rarely the install itself. Identity integration testing and permission mapping consume the most calendar time, because BookStack's role and permission system and Wiki.js's authentication modules each need to match how your directory groups actually map to editors, readers and administrators. For BookStack, test OIDC, SAML2 or LDAP sign-in against a staging identity provider, then confirm that per-role multi-factor enforcement behaves as intended. For Wiki.js, confirm which authentication strategy you enable (Azure AD, Keycloak OpenID Connect, LDAP and Active Directory, SAML 2.0 and others), how group claims are read, and whether TOTP two-factor authentication is enforced or optional. Ask your identity team to supply a written group-to-role matrix before any work starts, since rework here is the most common source of delay.

Content cleanup before migration is the second hidden workload. Legacy wiki exports often contain duplicate pages, orphaned attachments and inconsistent headings, and BookStack's fixed hierarchy of shelves, books, chapters and pages forces a decision about where each page belongs. Wiki.js has no such fixed hierarchy, so the cleanup question shifts to path naming and page organization. On the Wiki.js side, Git storage configuration adds its own work: you must decide the repository layout, the sync direction (the Git module synchronizes content in both directions, so conflicting edits made through the web interface and the repository need a policy), the credentials used, and how the sync is tested under failure. Your implementation partner or internal team should produce a written content inventory and a sync design, then validate both with a sample of real pages.

Database backup and restore design and staff training on the editor are easy to underestimate. BookStack depends on MySQL 8.0 or MariaDB 10.6 or later, and Wiki.js 2.x recommends PostgreSQL 9.5 or later, with the PostgreSQL search module requiring the pg_trgm extension. In both cases, backups must cover the database and the uploaded files or storage target, and a restore must be rehearsed on a separate host, not assumed. Confirm recovery objectives with your own risk owners, not with a vendor default. Editor training also differs: BookStack offers a WYSIWYG editor with an optional Markdown editor, while Wiki.js has its own editing flow tied to its storage module. Budget time for both the rollout and for a short written style guide, and ask any partner to state in its quote which of these items are included in fixed scope and which are optional retainer work.

The running cost of either wiki is mostly staff time and the database and hosting choices made at installation, not the software licence, since both BookStack and Wiki.js 2.x are free to self-host. For BookStack, the infrastructure is a PHP 8.2 or later application on MySQL 8.0 or MariaDB 10.6 or later, installed on a server or through the official installation scripts for Ubuntu 26.04, 24.04 or 22.04. BookStack does not publish official Docker images, so a team that standardizes on containers must decide whether to accept a community image and who patches it. For Wiki.js 2.x, the cost drivers are a dedicated domain or subdomain (it cannot sit under a subfolder), at least 1 GB of RAM on Linux, and a database that the requirements documentation recommends as PostgreSQL 9.5 or later. Confirm the database engine you will operate, because PostgreSQL search also depends on the pg_trgm extension.

The recurring costs are patching, upgrades, backups and identity maintenance. Wiki.js is the riskier line to budget for: the stable 2.x line is maintained as v2.5.316 (October 2, 2026), while the 3.0 beta in the main repository is marked not for production use, so a migration to 3.0 is a future project with its own testing and storage rework. Git storage sync in Wiki.js writes content in both directions, which means backup design must cover the Git remote as well as the database, and someone must own conflict handling. BookStack keeps content in its database and file storage, so its backup set is simpler to define, but restore testing still takes staff time. Identity integration is a one-time build cost with a recurring review cost: BookStack's OIDC, SAML2 and LDAP sign-in and enforceable multi-factor authentication, and Wiki.js's broader module list including Keycloak, Okta and Azure AD, each need role mapping that must be re-checked when the identity provider changes.

When requesting a quote, ask for the scope in writing: installation and hardening, the identity provider and sign-in method to configure, the storage and backup design (including Git remote handling for Wiki.js), a migration plan from any existing wiki, upgrade and patch responsibilities, and whether a retainer covers the Wiki.js 3.0 evaluation when it leaves beta. Ask which items are one-time and which recur, how paid support is priced, and what happens if an upgrade breaks a customization. DeployOpen does not publish prices, so the quote follows from that written scope. Compare each quote against the same list of components so the totals reflect the same work.