XWiki or BookStack: which fits your knowledge base
A team replacing Confluence or consolidating internal documentation has to decide early whether it needs a structured enterprise wiki or a simple documentation shelf. XWiki fits when you need view, comment, edit and delete rights set at wiki, page or hierarchy level, structured data attached to pages, and optional Pro applications, all under the LGPL-2.1-or-later license. BookStack fits when your content is mostly manuals and runbooks that map cleanly to books, chapters and pages on shelves, you want an MIT license, and you want a lighter operational footprint with PHP 8.2 or later and MySQL or MariaDB.
The decision turns on five questions. First, permission complexity: if different groups need different rights on individual pages or sub-trees, XWiki's model is the stronger fit, while BookStack's role and permission system suits organizations that can manage access at the shelf, book and chapter level. Second, content volume and structure: large volumes with cross-linked, typed data favor XWiki, while a few thousand documentation pages organized as manuals favor BookStack. Third, SSO and paid features: confirm which sign-in methods and extensions you need, since XWiki Pro lists Active Directory and Azure Active Directory SSO applications and BookStack lists OIDC, SAML2 and LDAP sign-in. Fourth, migration effort: if you are leaving Confluence, check whether a Confluence to XWiki migration path matches your spaces, permissions and attachment history needs before you commit.
Run a short test before deciding. Pick one space with restricted pages, one with heavy attachments and one with structured content, then import each into a trial instance of both platforms. Ask XWiki SAS and your internal team to confirm how the Pro applications you need are licensed and supported in your edition, and ask yourself who will own permission design and upgrades. Choose XWiki if the permission model and structure are central to your requirements, and choose BookStack if your content is documentation-first and your administrators want a simpler system to run.
Which scenario favors which platform
This table maps common wiki scenarios to the platform that usually fits better, and names the condition that drives the choice. Read each row against your own content volume, permission model and migration source, then check the conditions before committing.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Flat internal handbook for one department | BookStack | Content fits a shelf, book and chapter hierarchy, and the team wants a simple editor without a Java runtime to operate. |
| Multi-team wiki with page-level restrictions | XWiki | Access must be set at wiki, space, page or hierarchy level and reviewed by team, so the rights model needs to be fine-grained from the start. |
| Confluence migration with spaces and permissions | XWiki (confirm first) | XWiki SAS offers a Confluence migration tool covering spaces, users, groups and permissions, but it is a paid product. Confirm the scope in writing before choosing either platform. |
| Regulated organization needing audit-style change history | XWiki | XWiki markets version control on every page change. Confirm with your auditors which change records they need, and whether BookStack's revision history meets that bar. |
| Small team with no dedicated platform staff | BookStack | BookStack publishes installation scripts for Ubuntu and relies on a MySQL or MariaDB database, which is a smaller operating footprint than running a Java application server. |
| Large content volume growing over several years | XWiki (test first) | Structured pages and multiple maintained release lines suit long-lived content, but plan an upgrade path and test performance with your real volume. |
| Need for structured data inside pages | XWiki | XWiki's structured data model suits forms and records inside wiki pages. BookStack is organized around books, chapters and pages, so confirm whether that model is enough. |
| Need for SSO and MFA controls | BookStack (confirm) | BookStack documents OIDC, SAML2 and LDAP sign-in with role-enforced MFA. For XWiki, SSO depends on extensions and Pro applications, so confirm the exact edition and extension you need. |
How XWiki and BookStack are built and deployed
XWiki and BookStack come from different stacks and ship in different ways, so the day-to-day work of patching, backing up and staffing each one differs. The cards below cover the runtime, database choices, release lines, Docker and installer paths, and the skills each platform asks your team to hold.
XWiki runs on Java and Tomcat
XWiki is a Java application served by Tomcat, and its official Docker images come in MySQL, PostgreSQL and MariaDB variants for amd64 and arm64v8. Choosing the database image is a decision you make at install time, and it shapes backup tooling and DBA involvement later. Your team needs Java and servlet container operations skills, not just wiki administration. Confirm which database variant your standards already support before you pick an image.
XWiki maintains three release lines
XWiki publishes a stable line, an intermediate LTS line and an LTS line, and each receives its own maintenance releases. At the time of research the official Docker tags were 18.8.0 for stable, 18.4.7 for the intermediate LTS and 17.10.14 for LTS. Pick the line that matches how often you can afford to upgrade, and plan the path from one line to the next before go-live.
XWiki images from the core team
The official XWiki Docker images are maintained by the XWiki Core Dev Team, which makes the image provenance clear for a security review. You still own the container host, the database, the image pinning policy and the rebuild schedule when a new tag appears. Ask your team who will watch the release branches and who approves an image change in production.
BookStack runs on PHP and Laravel
BookStack is a PHP application built on the Laravel framework and needs PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later. Its database is one relational store, so backups cover the database and the uploaded files together. Staff who already run LAMP or LEMP stacks will recognize most of the work. Confirm your PHP and database versions against the installation requirements before you schedule the build.
BookStack installs by script, not container
BookStack provides official installation scripts for Ubuntu 26.04, 24.04 and 22.04, and it does not publish official Docker images. Community Docker setups such as LinuxServer.io exist, but they are maintained outside the project. If your standard is containers with pinned images, you will build and own that image pipeline yourself. Check whether your host standard matches one of the supported Ubuntu releases before you choose BookStack.
Skills and patch rhythm differ
XWiki patching means tracking several release branches, testing extension compatibility and maintaining a Java runtime. BookStack patching means keeping PHP, the database and the application current on a single line. Neither platform removes the need for a named owner who reads release notes and schedules maintenance. Ask both vendors and your own platform team how often you expect to patch, and who is on call when a release breaks an extension.
Side-by-side capability comparison
This table compares XWiki and BookStack on license, permissions, version history, structured data, editors, diagrams, identity and connectors. Read each row as a question to answer for your own environment, and treat the Pro-only cells as conditions that depend on the subscription you buy.
| Capability | XWiki | BookStack |
|---|---|---|
| License | LGPL-2.1-or-later for the platform, with paid Pro applications and support from XWiki SAS | MIT, with paid support plans and sponsorship available from the maintainers |
| Permission model | View, comment, edit and delete rights set at wiki, page or hierarchy level | Full role and permission system; confirm how fine-grained page-level rules can get for your structure |
| Version history | Every page change is kept under version control | Page revision history is available; confirm retention and restore behavior in current docs |
| Structured data | Structured pages and data model support, suited to records and typed fields | Content is organized as books, chapters and pages on shelves, without a structured data model |
| Editors | WYSIWYG editing; confirm the editing experience for your user base | WYSIWYG editor with an optional Markdown editor |
| Diagrams | Diagram app available in XWiki Pro; confirm the built-in option in Standard | Built-in diagrams.net diagrams |
| SSO and MFA | Active Directory and Azure Active Directory SSO apps in XWiki Pro; OIDC via the community xwiki-contrib extension; confirm the supported options | OIDC, SAML2 and LDAP sign-in; built-in MFA that can be enforced per role |
| Connectors | Google Apps, Office365 and OnlyOffice connectors, plus Confluence migration tooling, in Pro or paid services | No paid connector catalog published; confirm integrations you need with the maintainers |
| Stack and deployment | Java with Tomcat; official Docker images for MySQL, PostgreSQL and MariaDB | PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later; official install scripts, no official Docker image |
What is free and what is paid on each side
XWiki Standard is the free open-source version of the platform, licensed under the LGPL 2.1, so you can run, modify and deploy it without a license fee. The software itself costs nothing to obtain, but a production deployment still needs servers, a database, an identity setup, backups and staff time to operate it. Those are the costs to model before comparing against any paid option.
- No license fee for the core: The LGPL 2.1 terms cover the standard distribution, and the official Docker images carry the same license.
- Database choice: Official images are built for MySQL, PostgreSQL and MariaDB variants running on Tomcat, which affects your hosting bill and DBA workload.
- Self-supported operation: Installation, upgrades, backups and troubleshooting fall to your team or to a services partner you contract separately.
- Release branches: Stable, LTS and intermediate LTS lines are published in parallel, so you choose which line to pin and when to move.
- Services are optional: Hosting, support and training come from XWiki SAS or other providers on separate contracts.
Confirm with XWiki SAS which Pro applications, if any, your required features depend on, because those are not part of Standard.
XWiki Pro combines the platform with business applications, connectors and support from XWiki SAS. Support and Pro subscriptions are sold in tiers defined by user count, and XWiki SAS states that cloud and on-premises pricing are the same. Subscriptions recur, so the annual total depends on tier and headcount.
- Pro applications: The Pro page lists Active Directory and Azure Active Directory SSO applications, File Manager, Forum, Polls, Calendar, Ideas, Meeting, Diagram, Pro Macros, and Google Apps, Office365 and OnlyOffice connectors.
- Tiers by user count: Starter covers up to 25 users and is XWiki Cloud only, Basic covers up to 1,000 users, Business up to 10,000 users, and Enterprise is unlimited.
- Same price in cloud or on premises: XWiki SAS states that pricing does not change with hosting model, which matters when you compare against self-hosting costs.
- Consulting and training rates: Consulting is listed at 1200 EUR per day and requires a Business or Enterprise support plan, and training is listed at 1500 EUR per day.
- Confirm before buying: Ask which Pro apps are in your tier, which SSO applications apply to your identity provider, and what support hours apply.
Get the current tier table and day rates in writing from XWiki SAS, since these are list figures and quotes may differ.
If you are leaving Confluence, the migration tool is a separate paid item from the platform itself. Confluence Migrator Pro from XWiki SAS moves spaces, pages, users, groups, permissions, attachments and metadata, which covers much of the work that otherwise falls to your team. It is a one-time purchase for the migration effort, not a recurring fee.
- Starting price: Confluence Migrator Pro is priced from 2000 EUR, according to the XWiki Store listing.
- Trial limit: The trial is limited to 30 pages per migration, which is useful for testing mappings but not for a full move.
- What carries over: Page history is kept, but attachment history is not, so plan how you will handle older file versions.
- Other migration work: XWiki SAS also offers Confluence to XWiki migration services, which are quoted separately from the tool.
- Your own effort: Permission mapping, user cleanup and validation remain your responsibility regardless of tooling.
Ask for the scope of any migration quote, including attachment handling, permission mapping and validation steps.
BookStack is MIT licensed, which allows you to use, modify and redistribute the software with few conditions. The project is built on PHP and Laravel, was created by Dan Brown and is developed with community contributors. Paid support plans and sponsorship are available, but they are optional and are not required to run the software.
- MIT license: The license covers the full product, with no separate paid edition of the core software that unlocks features.
- Paid support plans: These exist, but the published material does not give tier names or prices in the sources reviewed, so ask the maintainers directly.
- Sponsorship: Organizations can sponsor development, which is a voluntary contribution rather than a license purchase.
- Your own hosting costs: Servers, a MySQL 8.0 or MariaDB 10.6 or later database, PHP 8.2 or later, backups and staff time are your responsibility.
- Installation path: Official installation scripts cover Ubuntu 26.04, 24.04 and 22.04, while community Docker setups are the usual route for containers.
Ask the BookStack maintainers what support options, response expectations and pricing apply before you budget for paid help.
What drives the running cost of each wiki
Both wikis are free to download and run, so the running cost of XWiki and BookStack comes from people and services rather than licenses. The staff time to install, patch, back up and monitor the platform is paid by your organization under either option. For XWiki, the paid options are XWiki SAS support, on-premises professional support, installation and configuration help, training and consulting, plus Pro subscriptions that add business applications and connectors. For BookStack, the source material is MIT licensed and paid support plans and sponsorship are available from the project, so most spending is internal labor or an external partner. Hosting is paid under both, whether that is your cloud account, a data center or the XWiki Cloud service, which is a separate choice covered elsewhere on this page.
The one-time costs are installation, configuration of single sign-on and permissions, content migration and any customization. Migration is usually the largest and least predictable line. If you are moving from Confluence, XWiki SAS sells Confluence Migrator Pro, which the XWiki Store lists from 2000 EUR and which carries spaces, users, groups, permissions and attachments, but keeps page history without attachment history. Its trial is limited to 30 pages per migration, so run a representative sample early. BookStack has no equivalent vendor migration tool supplied in our research, so confirm import options and their effort with the project or your partner. Recurring costs are upgrades, support subscriptions, patch windows and backup storage. XWiki maintains parallel release lines, so decide which line you will track and budget the regular upgrade work for it.
When you request a written quote, ask for each item to be priced separately. Specify the scope in terms of content volume (page count, attachment size and number of spaces or books), the user count (XWiki Pro tiers are set by user ceiling, and XWiki SAS states cloud and on-premises pricing is identical), the connectors and Pro applications you need, the migration volume and whether attachment history must survive, and the support hours and response expectations. Ask whether consulting at the listed 1200 EUR per day requires a Business or Enterprise support plan, and whether training is included. For BookStack, ask for the same breakdown against its MIT codebase and your chosen database and authentication setup. Under either option, request a fixed-scope statement of deliverables so you can compare the two quotes on the same basis.
Moving content between XWiki and BookStack
This sequence gives you a verified inventory, a mapped hierarchy, a decided position on history and attachments, a tested pilot and a controlled cutover, so the move in either direction does not lose permissions or structured data silently.
Inventory spaces, books and permissions
List every XWiki space or wiki and every BookStack shelf, book and chapter in scope, with page counts, attachment counts and the page and hierarchy rights set on each. Record who holds view, comment, edit and delete rights at wiki, page or hierarchy level in XWiki, and which roles and per-item permissions apply in BookStack. The owning team signs off the inventory. It is done when every in-scope item has a row, an owner and a permission summary that the reviewers agree matches the live source.
Map the hierarchy to the target model
Decide how XWiki spaces and nested pages become BookStack shelves, books, chapters and pages, since BookStack organizes content in that fixed four-level model and XWiki allows deeper nesting and rights at each level. Write the mapping as a table and flag every place where a rights rule cannot be reproduced one to one. Ask the target administrator to confirm the role model they will configure. It is done when the mapping table is approved and each flagged rights rule has a named decision.
Decide what history and attachments must survive
Confirm which page history the business needs to keep. XWiki's Confluence Migrator Pro, sold by XWiki SAS, keeps page history but not attachment history, so any attachment history you need must be exported separately or accepted as lost. Check the same question for any move out of XWiki, because the target must be able to hold the version record you require. Put the decision in writing with the compliance or records owner. It is done when the retention position for page history and attachment history is documented and signed.
Re-model structured data before leaving XWiki
If the XWiki content uses structured data such as classes, objects or custom forms, plan how that data will be represented in a book model. BookStack's pages hold rich text and diagrams, so a move out of XWiki into a book model loses structured data unless it is re-modeled, for example as tables, templates or a separate system of record. Estimate the rework with the people who own those applications and the target team. It is done when every structured data type has a documented target representation or an approved retirement decision.
Pilot with a representative subset
Choose a subset of spaces or books that covers the hard cases: deep hierarchy, restricted rights, attachments, and any structured data. Move that subset to a non-production instance, then compare titles, links, attachments, permissions and search results against the source. Ask a sample of real users from each affected group to test access as well. It is done when the pilot report lists every defect found, its fix, and a pass result on the agreed checks.
Run the full migration and verify
Run the migration for the full scope on a schedule agreed with the content owners, with the source set to read-only or frozen where the platform allows it. Reconcile counts of pages, attachments and users, and repeat the permission checks from the inventory. Record any items that could not be moved and their disposition. It is done when the reconciliation report shows every in-scope item either moved and verified or formally excluded by its owner.
Cut over and retire the source
Switch users and links to the target, publish redirect or notice pages where feasible, and keep the source in read-only mode for an agreed period that your records policy sets. Confirm backups of the source before any decommissioning step, and document the retained copy and who can access it. Retire the source only after the owner signs off that no open business need depends on it. It is done when the cutover is announced, the retained archive is documented, and the decommissioning approval is on file.
Where XWiki and BookStack projects usually run long
Most XWiki projects run long on permission design, not on installation. XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level, and every rule you add interacts with inherited rights on child pages. Teams that start configuring spaces before agreeing a written permission model usually rework it after the first audit question or the first department asks for an exception. Before scoping, ask the vendor or your implementer to confirm how the permission model maps to your existing directory groups and which rights need to be set per page rather than per space. Content structure is the second common slip: XWiki's structured data is useful only if the page types, classes and hierarchy are decided before migration, so budget a design step for them.
SSO is where XWiki scope grows. The Active Directory and Azure Active Directory SSO applications are part of XWiki Pro, so confirm the edition and the license terms before you plan around them. If you choose the community route, the xwiki-contrib OIDC extension is the relevant starting point, and its configuration, claim mapping and group handling need to be tested against your identity provider as a separate work item. For BookStack, the effort sits in the installation and hardening on your chosen Ubuntu release, since official install scripts cover Ubuntu 26.04, 24.04 and 22.04 and the community Docker setups are not official. Role mapping from OIDC, SAML2 or LDAP groups to BookStack roles, and enforcing multi-factor authentication per role, should be written down and tested with real accounts before go-live.
The most underestimated BookStack work is restructuring content into shelves, books and chapters. Migrated pages often arrive without the hierarchy a shelf model needs, and a flat export can take as long to reorganize as it did to move. Plan a cleanup owner for each shelf, a rule for retiring stale pages, and a decision on which permissions go at shelf level versus book level. For both platforms, ask each vendor or implementer to confirm migration scope, the effort to rework permissions after cutover, and who owns content quality once the project closes. A fixed written scope that names these items protects the timeline on either platform.
Questions buyers ask before choosing a wiki
How much does each wiki cost to run, and what drives the cost?
Neither product charges a license fee: XWiki Standard is LGPL 2.1 or later and BookStack is MIT licensed. The recurring spend is therefore infrastructure, the staff time spent on upgrades and backups, and any paid support. XWiki SAS sells Pro subscriptions in Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users) tiers, and lists consulting at 1200 EUR per day for Business or Enterprise support plans and training at 1500 EUR per day, per xwiki.com pricing. BookStack offers paid support plans and sponsorship, but this research did not supply its prices, so confirm them on its site. The main cost drivers are user count, whether you need Pro applications, hosting size, and who performs upgrades. Ask any vendor or partner for an itemized quote that separates one-time setup from recurring support.
Can our team install and maintain XWiki or BookStack without outside help?
Yes, if your staff already runs Linux, a database and a PHP or Java web stack, but confirm the capacity of the people who will own it. BookStack provides official installation scripts for Ubuntu 26.04, 24.04 and 22.04 and requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, per its installation documentation. It publishes no official Docker images, so container setups usually come from the community. XWiki publishes official Docker images in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8, maintained by the XWiki Core Dev Team. In both cases your team still owns upgrades, backups, patching and monitoring. If you want outside help, DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, usually under a fixed scope agreed in writing before work starts, with ongoing support available as a retainer.
How long does a migration from Confluence take, and what does it depend on?
This research did not supply a migration duration, so ask for an estimate that is tied to your own content before you commit. The main drivers are the number of spaces, pages and attachments, how much page history you need to keep, the number of users and groups, how complex your Confluence permissions are, and how much content must be reshaped to fit the target structure. For XWiki, Confluence Migrator Pro from XWiki SAS migrates spaces, pages, users, groups, permissions, attachments and metadata. It keeps page history but not attachment history, and it is priced from 2000 EUR, with a trial limited to 30 pages per migration, per the XWiki Store listing. This research did not identify an equivalent Confluence migration tool for BookStack, so ask BookStack and any partner which import paths they support. A practical check is a trial run on a representative sample of spaces that includes your most restricted content and attachments.
Can BookStack handle fine-grained page permissions?
BookStack has a full role and permission system, and it can enforce built-in multi-factor authentication per role, per the BookStack site. Whether that matches your model depends on how granular your rules are. BookStack organizes content into shelves, books, chapters and pages, so a team that mostly needs book-level or shelf-level access will find the model easy to reason about. XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level, per xwiki.com, which suits a restricted page sitting inside a broadly shared space. Test your hardest rule in both products before deciding. For example, an illustrative HR page nested under a company-wide space should be visible only to one group, while the rest of the space stays open to everyone. Confirm each product's current permission documentation and check that the group sync you need works with your directory.
Does XWiki Pro single sign-on require a paid plan?
XWiki Pro lists Active Directory and Azure Active Directory SSO applications among its offerings, per the XWiki Pro page, so those SSO options are part of the paid Pro product. Whether a free XWiki Standard deployment can use SSO is a separate question this research did not settle. The community OIDC extension exists in the xwiki-contrib repository, but its feature coverage, maintenance status and support terms are not established here. Before you buy, confirm with XWiki SAS which protocols (OIDC, SAML, LDAP or Active Directory) are covered by Standard extensions, which are included in a Pro subscription, and whether support covers SSO problems on your tier. Pro subscriptions are sold per user tier, and XWiki SAS states that cloud and on-premises pricing is the same, per xwiki.com pricing.
How do I pick an LTS line for XWiki?
XWiki publishes a stable line, a long term support (LTS) line and an intermediate LTS line, and it maintains them in parallel. At the time of research, the official Docker tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS. The xwiki-platform releases page also listed 16.10.19 on October 2, 2026, and 18.8.0 was published on September 29, 2026. Choose the stable line if you want newer features and can upgrade often. Choose an LTS line if you prefer fewer major changes and a slower cadence, and accept that you will eventually move to a newer line. Before committing, read the release notes for the branch you plan to run and ask XWiki SAS for the support end date of that branch. Your choice should also reflect how many Pro applications you depend on, since those must be compatible with the version you run.
Does BookStack offer official Docker images for container deployments?
No. BookStack does not publish official Docker images and points to community Docker setups, such as LinuxServer.io, according to its installation documentation. That shifts several responsibilities onto your team. You need to confirm who maintains the image, how quickly it follows new BookStack releases, and how security patches reach your environment. You also need to pin versions and test upgrades before rolling them out. If your platform standard is containers, plan for that review before you choose BookStack. By contrast, XWiki publishes official Docker images, maintained by the XWiki Core Dev Team, in MySQL, PostgreSQL and MariaDB variants, which reduces the image-ownership question. Either way, the database, backups and upgrade process remain your responsibility, so confirm the restore procedure with a test before go-live.
How DeployOpen helps you choose and implement
DeployOpen approaches the XWiki vs BookStack decision as an implementation question: which content model, permission model and identity setup your teams need, and what it takes to run that platform inside your own infrastructure. We plan, implement, customize, integrate, harden, back up, document and support self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
How we scope
- Written scope covers content volume, page hierarchy, and the permission rules each space or team needs to follow.
- We confirm identity requirements such as OIDC, SAML2 or LDAP sign-in and which users must be enforced with multi-factor authentication.
- Confluence migration needs are defined up front, including which spaces, users, permissions and attachments move and which history is kept.
How we build
- We deploy the chosen platform in your environment, with database, web server and storage sized to the scope you agree.
- Permission structures are configured at wiki, space, book or page level and tested with representative user accounts before rollout.
- Integrations, SSO connections and any paid extensions are implemented and checked against the written deliverables.
How we hand over
- Documentation covers the architecture, administration tasks, permission model and the upgrade path for the chosen release line.
- Backup and restore procedures are tested and handed over so your team can run them without outside help.
- Knowledge transfer sessions walk your administrators through daily operation, content governance and troubleshooting steps.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Before any quote, we ask you to confirm licensing, user counts and paid application needs so the cost of ownership is clear.
