Which wiki fits your team: BookStack or DokuWiki
Choose BookStack when your regulated operations team needs a database-backed knowledge base with shelves, books, chapters and pages, and when single sign-on through OIDC or SAML2, LDAP sign-in and multi-factor authentication enforced per role are requirements. Choose DokuWiki when you want a file-based wiki with no database, a small dependency footprint and a long-standing plugin ecosystem, and you can accept that access control, authentication and backup design will rely more on plugins and your own file-level procedures. The decision turns on four questions: how you will authenticate users and enforce MFA, how you will back up and restore content, which plugins your workflow truly needs, and who will run and patch the hosting after go-live.
Start with authentication, because it sets the rest of the design. BookStack supports OIDC, SAML2 and LDAP sign-in and a full role and permission system, so you can map directory groups to roles and enforce MFA by role. DokuWiki also supports LDAP and Active Directory through bundled authentication plugins (authldap and authad), and its access control plugin manages page-level rights. Confirm with your identity team which mechanism you will use for MFA, whether DokuWiki's bundled plugins cover your directory layout and group mapping, and how sessions are revoked when someone leaves. Also test how each option behaves in a pilot with your real directory groups, not sample accounts. For backups, BookStack stores content in MySQL 8.0 or MariaDB 10.6 or later, so your backup routine must capture both the database and the uploaded files, and you should rehearse a restore. DokuWiki keeps its pages under a data directory rather than a database (savedir ./data by default), so backups are file-based and simpler to copy, but you must include the configuration and the users and access files. Ask who owns backup verification, how often restores are tested, and whether the documentation itself must be retained under a records policy. Run one restore drill on each candidate before you commit.
Which scenario points to which wiki
This table maps common team scenarios to the wiki that fits better and the condition under which the other one wins. Read each row as a starting point, then confirm the named capability against the current release and your own identity setup before you commit.
| Scenario | Better fit | Reason and when the other wins |
|---|---|---|
| Regulated team needing SSO and enforced MFA | BookStack | BookStack supports OIDC, SAML2 and LDAP sign-in and built-in multi-factor authentication that can be enforced per role. DokuWiki can use LDAP or AD, but confirm how your MFA requirement is met through your identity provider before choosing it. |
| Small ops team wanting minimal moving parts | DokuWiki | DokuWiki's default configuration stores pages as files in a data directory rather than a database, so there is no database server to run. BookStack needs PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6 or later, which adds a service to patch and back up. |
| Team needing AD group-based access to spaces | Either, after testing | DokuWiki bundles authad and authldap, and its access control plugin manages page rights. BookStack also supports LDAP sign-in with a full role and permission system. Test how your AD groups map to roles in each before deciding. |
| Team relying on plugins and custom extensions | DokuWiki | DokuWiki bundles an extension manager and a broad set of plugins and a remote API. BookStack's feature set is built in, so choose DokuWiki if you expect to add functionality through community plugins. |
| Team wanting a book, chapter and shelf structure with a modern editor | BookStack | BookStack organizes content into shelves, books, chapters and pages, with a WYSIWYG editor, an optional Markdown editor and built-in diagrams.net diagrams. DokuWiki uses namespaces and pages, which suits teams that prefer plain-text markup. |
| Team that needs file-level backups and simple restore | DokuWiki | Because content lives in files, backups of the data directory are straightforward to copy and version. BookStack backups must cover the database and the uploaded files together, so confirm your backup routine covers both. |
| Team that must run on an existing database standard | BookStack | BookStack runs on MySQL or MariaDB, which many operations teams already maintain. Choose DokuWiki if you want to avoid database administration entirely, since its default setup does not need one. |
| Team with a strict PHP version policy | Confirm first | Both platforms are PHP-based and DokuWiki's composer.json also requires PHP 8.2 or later, so the runtime is not the differentiator. Check the database and web server requirements against your patch policy instead. |
How BookStack and DokuWiki are built and deployed
BookStack and DokuWiki solve the same documentation problem with very different plumbing. One runs as a database-backed PHP application, the other keeps its content in files, and that choice shapes backups, upgrades and who on your team needs to be comfortable with a database.
BookStack runs on PHP and a database
BookStack is a PHP application built on the Laravel framework. It requires PHP 8.2 or later and either MySQL 8.0 or MariaDB 10.6 or later, so your content, users and permissions live in a relational database that someone must back up, tune and patch. Confirm that your team already runs MySQL or MariaDB well before you commit to this route.
DokuWiki stores pages as files
DokuWiki's default configuration keeps all pages and metadata as files under a data directory rather than in a database. There is no database server to install, but the data directory becomes the critical asset, so backups must capture it completely and consistently. Confirm that your file-level backup tooling handles that directory tree as one unit.
Install paths and container options
BookStack publishes official installation scripts for Ubuntu 22.04, 24.04 and 26.04, and it does not publish official Docker images. Teams that standardize on containers will rely on community setups such as LinuxServer.io, which you should review and pin yourself. Ask who maintains the image and how quickly it follows new BookStack releases.
Backups follow the storage model
BookStack backups need two consistent parts: a database dump and the uploaded files, so restore testing must cover both. DokuWiki backups center on the data directory and its configuration, which is simpler to copy but easy to get wrong if writes happen during the copy. Test a full restore on both platforms before treating either backup as proven.
Database administration effort
With BookStack, someone owns database versions, user accounts, character sets, storage growth and failover decisions, which adds recurring operational work. DokuWiki avoids most of that work because there is no database to administer, though file permissions, web server configuration and PHP upkeep remain. Ask your operations team which of these tasks they already perform on other systems.
Upgrade paths differ
BookStack upgrades involve application code, PHP compatibility and database migrations, so each release needs a staged rollout with a tested backup. DokuWiki upgrades replace application code while preserving the data directory, but plugins must be checked for compatibility with each release. Confirm how each vendor documents its upgrade steps and whether you will test upgrades in a non-production copy first.
Editing, structure, authentication, backups and plugins compared
This table sets BookStack and DokuWiki side by side on the capabilities that usually decide a documentation rollout: how people write, how content is organized, how users sign in, what must be backed up and what ships built in. Where a supplied fact does not settle a point, the cell says what to confirm in a trial install before you commit.
| Capability | BookStack | DokuWiki |
|---|---|---|
| Editing | WYSIWYG editor with an optional Markdown editor and built-in diagrams.net diagrams | Editing approach to confirm with the current edit toolbar and syntax on dokuwiki.org |
| Content structure | Shelves, books, chapters and pages | Namespaces and pages; confirm how namespace hierarchy maps to your team's sections |
| LDAP and Active Directory | LDAP sign-in supported; confirm AD-specific group handling in your version | authldap and authad bundled as plugins |
| Single sign-on | OIDC and SAML2 sign-in supported | Not listed among bundled authentication plugins; confirm before relying on it |
| Default authentication | Local accounts with the other sign-in methods layered on | authplain is the default; authpdo available for SQL-backed users |
| Access control and MFA | Full role and permission system with multi-factor authentication enforceable per role | Bundled acl plugin for page-level rights; confirm whether MFA exists through a plugin |
| Backups | Database plus uploaded files must both be backed up and restored together | Single data directory holds the content; backup the files, with no database to coordinate |
| Bundled plugins and admin tools | Built-in role, user and content administration; extend through the platform's own options | Bundled acl, user manager, extension manager, config manager, revert and log viewer plugins |
| Remote API | Confirm the API scope and token model in the current docs | Remote API bundled with the core |
License terms and what is paid for each
BookStack is released under the MIT license, which permits commercial use, modification and redistribution with the license notice retained. The latest release supplied for this comparison is v26.09.1, published on September 29, 2026, following v26.09 on September 24, 2026. The project's website states that paid support plans and sponsorship are available, and that the software is developed with community contributors.
- License scope: MIT imposes few conditions beyond keeping the copyright and license notice, so the license itself does not gate features behind a paid tier.
- Latest release: v26.09.1 was published on September 29, 2026, which is the reference point for any upgrade plan.
- Paid support: Paid support plans are offered by the project. The tiers, response commitments and what they include were not supplied here.
- Sponsorship: Sponsorship is available as a way to fund development. It is a funding channel, not a license upgrade.
- Hosting costs: Your own infrastructure, PHP and database operation, backups and staff time remain your costs regardless of the license.
Before budgeting, ask BookStack's maintainers which support plans exist, what each covers and whether any feature you need is tied to a paid arrangement. Confirm the current release and upgrade notes on the release page before scheduling changes.
DokuWiki is licensed under GPL-2.0, according to the license metadata of its GitHub repository, which credits Andreas Gohr and the DokuWiki community. The most recent release supplied for this comparison is release 2026-07-14 "Mort", published on July 14, 2026. Hotfix 2026-07-14c followed on September 2, 2026, and the 2026-07-14b hotfix, published on August 11, 2026, fixed a security issue.
- License type: GPL-2.0 requires that distributed modified versions keep the same license and make source available, which matters if you package or redistribute a customized build.
- Release line: Release 2026-07-14 "Mort" is the base version, with hotfix 2026-07-14c on September 2, 2026 as the later patch.
- Security hotfix: The 2026-07-14b hotfix on August 11, 2026 addressed a security issue, so confirm that your deployment runs at least that level.
- Paid edition: No paid edition or commercial support plan was supplied for DokuWiki in this research.
- Plugin licenses: Third-party plugins carry their own licenses, which you should review separately from the core license.
Ask DokuWiki's community or any third-party provider whether commercial support exists and under what terms. Check the releases page for the newest hotfix before you deploy, because the supplied information is a snapshot.
Neither platform was supplied with a paid edition, so the practical difference lies in who can provide support and what that support covers. For BookStack, the project documents paid support plans and sponsorship. For DokuWiki, the supplied facts describe the license and releases but not a commercial support offer. Either way, the operating work of hosting, patching, backing up and restoring stays with your team or your implementation partner.
- Cost components: License fees are zero for both platforms. Recurring costs come from hosting, staff time, backup storage and any support contract you choose to buy.
- One-time costs: Initial installation, authentication setup (LDAP or Active Directory) and content migration are usually one-time, and their scope depends on your existing data.
- Recurring costs: Patching, security hotfixes and any paid support renewal recur for as long as you run the platform.
- Quote inputs: Ask for a written scope covering versions, supported authentication methods, backup routines and the response expectations you need.
- Support variability: A paid BookStack support plan and a community-only DokuWiki path lead to different escalation routes and different contract terms.
Before comparing offers, ask each vendor which support options exist, which versions they cover, what response commitments apply and whether those terms change for self-hosted installations.
How LDAP, AD and SSO change the identity design
Directory support does not decide this comparison on its own. Both BookStack and DokuWiki can authenticate against LDAP, and DokuWiki bundles an Active Directory plugin (authad) alongside authldap. The identity design differs in what happens after the login: where roles come from, whether MFA can be required, and how a departing user loses access. Start by listing which of those three controls your identity team must own.
BookStack offers OIDC, SAML2 and LDAP sign-in, built-in multi-factor authentication that can be enforced per role, and a full role and permission system inside the application. That lets you tie an MFA requirement to a role such as editors or administrators, independent of how the user signed in. DokuWiki relies on its file-based access control list, its user manager and the authad or authldap plugin for directory-backed accounts. Access rules are expressed per namespace and group, so the design work is in the ACL file and group naming, not in a separate permission model. Confirm in your own environment whether DokuWiki's bundled plugins cover the sign-in method your identity provider requires, since the supplied facts do not describe MFA for DokuWiki.
Before you commit, run two tests in your own directory with a non-production account set. First, map a sample of real group memberships to each platform's roles or ACL groups and check that nested groups resolve the way you expect. Second, disable a test account in the directory and confirm it loses access on both platforms, including existing sessions and any local fallback accounts. Ask the vendor or community which local accounts remain active when the directory is unreachable, because that is the path most often left open.
Moving content from DokuWiki to BookStack, or back
This sequence moves a team's pages, users and access rules between a file-based DokuWiki and a database-backed BookStack without losing structure or breaking links. Each step ends with a check that tells you whether the move is safe to continue.
Inventory namespaces, pages and access rules
Start by listing every namespace, page count, attachment folder and access control list (ACL) entry in the DokuWiki data directory and its configuration. Your wiki administrator or the team that owns the content should confirm which namespaces are still in use, which are archived and who holds edit rights on each. Record any plugin-specific syntax, such as custom macros or table plugins, because these will not render in BookStack without rewriting. The step is done when you have a signed-off inventory that maps every namespace to an owner and an access level.
Map namespaces to shelves and books
Decide how each top-level namespace becomes a BookStack shelf, and how each sub-namespace becomes a book or chapter. BookStack groups content as shelves, books, chapters and pages, so a deep DokuWiki namespace tree may need flattening into fewer books. Write the mapping as a table that lists source namespace, target shelf, target book and target chapter. Ask the content owners to approve it before any export runs. The output is an approved mapping document that the migration scripts will follow.
Export and convert pages to BookStack format
Export DokuWiki pages from the data directory in their native format, then convert the DokuWiki syntax to HTML or Markdown that BookStack accepts. A conversion tool or script run by your platform engineer is typical, but it should be tested on a copy first. Expect to review tables, internal links, media references and any plugin output by hand, since automated conversion rarely handles every case. The check is a trial import of a sample namespace into a staging BookStack instance, reviewed page by page by a content owner.
Migrate users and groups
Recreate user accounts in BookStack using the same identity source your organization already runs. Both platforms support LDAP, and DokuWiki also supports Active Directory through its authad plugin, so LDAP or AD group membership can often carry over with the right mapping. BookStack also supports OIDC and SAML2, so confirm which method your identity team will use before creating accounts. Local DokuWiki users, which are stored in a file rather than a directory, will need a decision on whether to recreate them, link them to directory accounts or retire them. The check is a login test for a representative set of users from each group.
Rebuild permissions on shelves and books
DokuWiki ACL rules are set per namespace and per page, while BookStack uses roles and per-shelf, per-book or per-page permissions. Translate each ACL rule into a BookStack role assignment and a content-level permission, and record every rule that cannot be expressed exactly. Those gaps need a decision from the content owner, usually a simpler rule or a restricted book. Have a security engineer review the resulting permission model against the original inventory. The check is a documented matrix in which every original ACL rule is either mapped or accepted as a deliberate change.
Verify links, attachments and images
Test internal links, interwiki references, attachments and embedded images on the staging instance. Links that used DokuWiki namespace paths will break when pages move to new books, so you need a redirect or a rewrite list for every moved page. Confirm that attachments and media files are present, opened correctly and linked from the right pages. A sample crawl plus a manual review of high-traffic pages is a practical check. The step is complete when broken links and missing files are either fixed or listed for a known-issues record.
Cut over and keep the reverse path ready
Schedule a freeze on DokuWiki edits, run the final export and import, and point users and bookmarks at BookStack. Keep the DokuWiki data directory and a verified backup intact until the team confirms that the content is correct. The reverse path, moving from BookStack back to DokuWiki, carries the same risks: markup conversion, ACL translation and link breakage all apply in the other direction. Document how you would run that path before you need it. The output is a signed cutover record, a tested backup of both systems and a named owner for post-migration support.
What drives the cost and effort of running each wiki
The cost of running either wiki is mostly staff time, not licenses, because both are free to download under open-source licenses. BookStack is MIT licensed and DokuWiki is GPL-2.0, so the recurring spend is the infrastructure your team runs, the people who operate it, and any support plan you buy. For BookStack, the database is a line item of its own: it requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, so someone must own backups, version upgrades and restore testing for that database. For DokuWiki, there is no database to administer, but plugin maintenance takes that role. Each third-party plugin you add must be checked against each DokuWiki release, and your team carries that compatibility work. Ask any implementer to price these two lines separately in a written scope.
One-time effort is front-loaded. Installation, single sign-on or LDAP and Active Directory configuration, and content migration all happen once, but they can be the largest share of the first year. Permission design deserves its own estimate. In BookStack, you map roles and permissions across shelves, books and chapters and decide whether multi-factor authentication is enforced per role. In DokuWiki, you map access control list rules across namespaces and decide which of the bundled plugins stay enabled. Migration staff time depends on how much legacy content must be reshaped and how clean the source permissions are. Ask for the migration method, the content volume assumed, and who signs off on the permission model before work begins.
Recurring effort is patching, backups, upgrades and monitoring. Both platforms receive security releases, and DokuWiki's 2026-07-14b hotfix, published on August 11, 2026, fixed a security issue, which shows why a patch window must be part of the run plan. Ask the implementer to state in writing who applies updates, how often, how backups are verified and where they are stored, and whether a retainer covers upgrades and out-of-hours response. Any support plan from the BookStack project is a separate purchase from implementation work, and the implementer's fees are separate again. Request all three as distinct line items so you can compare them against your internal capacity.
Questions buyers ask before choosing between BookStack and DokuWiki
How much effort does a migration from DokuWiki to BookStack take?
The effort depends mainly on how much content you have, how cleanly it is structured, and how many users and permissions must carry over. DokuWiki stores pages as files in a data directory, so the content is plain text in DokuWiki markup, while BookStack expects its own shelves, books, chapters and pages in a database. Someone has to map DokuWiki namespaces onto BookStack's hierarchy, convert markup, move attachments, and check internal links after the move. Teams with a small, well-organized wiki usually have a short, bounded task. Teams with years of loosely organized namespaces should budget time for a content audit before any import. Ask any implementation partner for a written scope that names the content volume, the conversion approach, and how links and users will be verified.
Can a team run BookStack or DokuWiki without outside help?
Yes, a capable team can run either platform, but the workload is different. BookStack needs a PHP 8.2 or later runtime, MySQL 8.0 or MariaDB 10.6 or later, a web server, and regular upgrades, and BookStack provides official installation scripts for Ubuntu 26.04, 24.04 and 22.04. It does not publish official Docker images and points to community setups such as LinuxServer.io, so the team must decide how it will manage containers. DokuWiki needs PHP 8.2 or later and a web server, with no database to operate. Both platforms have security releases that must be applied. Outside help is most useful for initial setup against your identity provider, hardening, backup design, and upgrade planning. Whether your team can carry that work alone is a question about your existing skills and on-call coverage.
What does running either wiki require from internal staff?
Internal staff need to own four recurring areas: the web and PHP runtime, the data layer, authentication, and content governance. For BookStack, the data layer means a MySQL or MariaDB instance with its own backup, restore and patching routine. For DokuWiki, the data layer is the file system, so staff need to manage permissions on the data directory and keep copies of it. Both need someone who applies releases promptly, including the DokuWiki 2026-07-14b hotfix published on August 11, 2026, which fixed a security issue. Content governance matters as much as the software. Someone must decide who creates shelves or namespaces, who approves pages, and how stale content is retired. Ask a partner to document each of these responsibilities in the handover so the team knows what it has taken on.
Does DokuWiki work without a database, and what does that mean for backups?
Yes. DokuWiki's default configuration stores all its files under a data directory (savedir ./data) instead of a database, so the wiki's pages, revisions and media live on the file system. That makes the backup scope simple to describe: the data directory and the configuration must be copied together and restored consistently. You do not need to coordinate a database dump with a file copy. The trade-off is that you must protect file permissions and restore them correctly, and that large content sets are handled as many files. BookStack keeps content in MySQL or MariaDB, so its backups must include the database and the uploaded files, captured at a consistent point. Confirm your restore procedure with a test restore, whichever platform you choose, because a backup that has never been restored is unproven.
How does each wiki handle LDAP and Active Directory sign-in?
Both platforms support LDAP, and both can be connected to Active Directory. DokuWiki bundles an authldap plugin and a dedicated authad plugin for Active Directory, along with authplain as the default and authpdo for SQL databases. BookStack supports OIDC, SAML2 and LDAP sign-in, and provides built-in multi-factor authentication that can be enforced per role, plus a full role and permission system. Which one fits depends on your directory design, your group structure, and whether you want a single sign-on protocol instead of direct directory binds. Confirm with your directory team how group membership maps to wiki roles, how disabled accounts are removed, and how service accounts are protected. Test sign-in with a pilot group before you change the production login path.
What does a DeployOpen support engagement cover for either wiki?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a wiki project, that can include planning the hosting footprint, setting up the chosen platform, connecting it to your identity provider, designing backups and testing restores, documenting the operating procedures, and planning upgrades. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to list the platform, the number of users, the identity integration, the migration content, and the backup and restore tests included.
What drives the cost of hosting BookStack compared with DokuWiki?
The main cost drivers are the infrastructure your team must run and the labor to keep it current. BookStack's stack is a PHP application plus a MySQL or MariaDB database, so there is more to patch, monitor and back up. DokuWiki's stack is PHP plus the file system, which is a smaller footprint to operate. Both are free to download under their licenses: BookStack is MIT licensed and DokuWiki is GPL-2.0. Neither publishes a paid edition in the facts supplied here, so the recurring costs are your own staff time, hosting, and any external support you choose to buy. One-time costs include migration, identity integration and documentation. Ask any provider to split the quote into setup, migration, integration and recurring support so you can compare the two platforms on like terms.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For BookStack vs DokuWiki, we start with the written scope that decides which of the two fits your documentation, authentication and hosting constraints, then carry the chosen platform through to handover.
How we scope
- Map which content must live in shelves, books and pages, and which can stay in flat wiki namespaces.
- Confirm the directory setup for LDAP or Active Directory sign-in on both platforms, including group mapping and account ownership.
- Agree in writing which plugins, editors and backup targets are in scope before any work starts.
How we build
- Install BookStack on your own servers or DokuWiki on your file storage, with the database or data directory decisions documented.
- Configure authentication, role and permission rules, and access control to match your team structure.
- Test sign-in, page permissions, backups and restores in your environment before the platform goes live.
How we hand over
- Document the installation, configuration, upgrade steps and the plugin or extension list for your team.
- Walk administrators through backup and restore procedures, with the data files or database dumps they must protect.
- If you are migrating existing wiki content, deliver a mapping of old spaces to the new structure and a record of what moved.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan upgrades around the platform release cycle your team chooses, with testing before each change.
- Ask for the written scope, deliverables and timeline in the quote so the boundaries of support are clear.
