XWiki vs BookStack: which fits your documentation load
Choose XWiki when the wiki must enforce access at the level of the wiki, a single page or a whole page hierarchy, when pages carry structured data that other content depends on, and when you want every page change kept under version control. XWiki is LGPL-2.1-or-later and its parent company, XWiki SAS, sells support, hosting and paid Pro applications, so the cost of a richer setup can grow beyond the free core. Choose *BookStack* when your main need is a clear shelf of books, chapters and pages that people can find and edit without training. BookStack is MIT licensed, requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and offers OIDC, SAML2 and LDAP sign-in, which keeps the stack lighter to run.
The decision turns on three questions. First, content volume: a few thousand pages organized by team or process is well within what a book and chapter model handles, but confirm how each product's search and navigation perform against your own export before committing. Second, permission complexity: if you need different groups to see or edit different branches of one space, or you need comment rights separate from edit rights, test that exact matrix in XWiki's rights model. If your rules are roughly one level deep, BookStack's shelf-level permissions may be enough. Third, structured data: if the wiki must hold fields, lists or records that feed reports or other pages, XWiki is the stronger fit. If the content is mostly prose and procedures, BookStack avoids that modeling effort.
If you are replacing Confluence, map your current spaces and permission schemes first, then pilot a sample of pages in both products with the same identity provider. Ask any implementation partner for a written scope that covers the migration of page history, attachments and permissions, and confirm which XWiki Pro applications your design requires, since those are paid add-ons and their license terms should be read before you rely on them. For BookStack, confirm which sign-in and attachment features your edition and configuration support in the current installation documentation. Whichever you choose, plan a rehearsal migration and an owner for permission reviews, because that work recurs for as long as the wiki runs.
Which scenario favors XWiki or BookStack
This table maps four common wiki scenarios to the platform that usually fits better, and names the condition that tips the choice. Read each row by asking how many spaces need different rights and whether pages must carry structured fields. The main takeaway is that BookStack suits hierarchical documentation with shared rules, while XWiki suits layered access and structured data.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Department handbook | BookStack | One audience, a few shelves and chapters, and shared read or edit rules. Choose BookStack if the team mainly needs clear navigation and a fast editor. |
| Regulated policy library with per-space access rules | XWiki | Many spaces or page hierarchies need different view, comment, edit and delete rights. XWiki grants these at wiki, page or hierarchy level, which fits this layering better. |
| Product documentation set | BookStack | Content is mostly books, chapters and pages with a single publishing audience. Confirm whether versioned releases of the docs need separate branches, since neither choice is assumed here. |
| Confluence-style team space | Depends on structure | If teams only need spaces and pages with light permissions, BookStack is simpler to run. If pages need structured fields or per-space rights, XWiki is the closer match. |
| Pages that carry structured fields | XWiki | Records such as vendor reviews, risk entries or policy owners need consistent fields across pages. BookStack handles text-led content and is weaker for this. |
| Small wiki with few admins | BookStack | A small admin group can manage a single shelf structure and standard sign-in. Confirm the supported sign-in methods (OIDC, SAML2, LDAP) against your identity provider before committing. |
| Heavy change history and review trails | XWiki | Every page change is kept under version control in XWiki, which helps when assessors ask for edit history. Confirm the retention and export approach your auditors expect. |
| Paid add-ons for workflow or apps | Depends on need | XWiki sells Pro applications and support from XWiki SAS. Check which features you need are in a paid app and whether that cost fits your budget before choosing XWiki. |
How XWiki and BookStack are built and deployed
XWiki and BookStack solve different documentation problems, and their build and runtime choices shape what your team maintains after go-live. The cards below cover licensing, release cadence, runtime stack and database requirements, the parts that drive upgrade planning and staffing.
XWiki's Java platform and licence
XWiki is LGPL-2.1-or-later, so you can self-host the platform without open-sourcing your own extensions in most arrangements. Its runtime is a Java application, which means your team needs Java operations skills, servlet container tuning and JVM memory management alongside the wiki itself. Before sizing hardware, confirm the supported Java version and database requirements in XWiki's installation documentation, since these set the baseline for your server build.
Parallel XWiki release branches
XWiki maintains several release branches at once, so a single upgrade decision rarely means moving to the newest version. Your team must choose which branch to standardize on and plan when to move between branches, since each branch receives its own maintenance releases. Ask XWiki SAS which branches receive fixes and for how long before you commit to one for a regulated environment.
BookStack's MIT PHP application
BookStack is MIT licensed and runs as a PHP application, which many Linux administrators can operate with standard web stack skills. The licence is permissive, so internal modifications carry few obligations. Plan for a PHP runtime, a web server and a supported database, and confirm that your OS packages provide PHP 8.2 or later before you schedule the deployment.
BookStack database requirements
BookStack requires MySQL 8.0 or MariaDB 10.6 or later, which keeps the data layer familiar for most database teams. A single relational database holds books, chapters, pages and user records, so backup and restore follow standard database procedures. Confirm which MySQL or MariaDB version your platform team supports, because an older database host can block the install even when the PHP version is correct.
Upgrade planning and staffing
XWiki's Java runtime and branch model call for staff who can handle JVM tuning, branch selection and periodic migrations across release lines. BookStack's smaller PHP and MySQL footprint usually fits a general Linux and web administration skill set. Ask each vendor or your implementation partner to document the upgrade path, the maintenance window and the staff roles needed for your own environment.
Hardware sizing checks
Hardware choices depend on user count, attachment volume and whether you run search or extensions, so sizing should come from a written test in your environment rather than a generic guideline. For XWiki, confirm Java memory and database sizing in its installation documentation before you buy servers. For BookStack, confirm the PHP and database limits on your hosts and measure page load and upload behavior with realistic content.
XWiki vs BookStack feature by feature
This table compares XWiki and BookStack on licensing, release cadence, rights, versioning, data model, editing, sign-in and paid add-ons. Read each row as a question to answer for your own environment, and treat any cell marked for confirmation as an open item to close with the vendor before you shortlist.
| Capability | XWiki | BookStack |
|---|---|---|
| License | LGPL-2.1-or-later, with XWiki SAS selling support, hosting and paid Pro applications | MIT licensed, with no paid edition described in the supplied facts |
| Latest dated release | 18.8.0 published September 29, 2026, with 18.4.7 and 17.10.14 also maintained | v26.09.1 published September 29, 2026 |
| Release branches | Several branches maintained in parallel, so you choose a line that fits your upgrade plan | Single release line, so confirm your upgrade path and testing cadence with the project |
| Permission model | Rights grantable at wiki, page or hierarchy level for view, comment, edit and delete | Permissions are set per book, chapter and page; confirm how fine-grained role and group rules behave at scale |
| Version control of page changes | Every page change kept under version control, per XWiki's own description | Confirm page revision history, restore and retention behavior in your installed version |
| Data model | Structured wiki pages suited to structured data alongside documentation | Books, chapters and pages grouped on shelves, optimized for documentation hierarchy |
| Editors | Confirm the editor options and macro support in your target version | WYSIWYG editor with an optional Markdown editor |
| Sign-in options | Confirm supported SSO and directory options with XWiki SAS for your edition | OIDC, SAML2 and LDAP sign-in |
| Paid add-ons | Pro applications sold by XWiki SAS; confirm which features each Pro app adds | No paid add-on tier identified in the supplied facts; confirm with the project |
What the XWiki and BookStack licenses cover
XWiki is licensed under the LGPL-2.1-or-later, which allows you to use, modify and deploy the platform inside your own infrastructure without paying a license fee to use the core. The license governs the source code and the redistribution terms for changes you ship. XWiki SAS, the company behind the project, sells support, hosting and paid Pro applications on top of the open core, so the paid layer is a separate commercial choice rather than a condition of the license.
- Core platform: the LGPL-2.1-or-later covers the platform source you deploy, with no per-user license fee for the open core.
- Support: XWiki SAS sells support subscriptions, which are optional and priced by the vendor, not by the license.
- Hosting: XWiki SAS offers hosting, which replaces your own infrastructure work rather than adding a license cost to it.
- Pro applications: paid Pro applications are extensions sold separately, so confirm which features you need are in the free core and which are Pro-only.
- Release branches: several release branches are maintained in parallel, so confirm with XWiki SAS which branch and support window your contract covers.
Confirm with XWiki SAS exactly which Pro applications and support terms you would need for your rights model, and request the list in writing before you assume a feature is free.
BookStack is licensed under the MIT license, one of the most permissive open-source licenses. You may use, modify, embed and redistribute it, including inside commercial products, provided the copyright notice and license text are kept. The license places no restriction on deployment size or number of users, and it does not require you to publish your own changes.
- Core platform: the MIT license grants broad use and modification rights for the full application.
- Paid edition: no paid edition was identified in the supplied facts, so do not assume one exists or that the feature set is split by tier.
- Commercial support: confirm with the BookStack project or any third party directly whether support contracts, hosting or customization services are available and what they cover.
- Authentication: OIDC, SAML2 and LDAP sign-in are part of the documented platform, so verify your identity provider setup against the current documentation.
- Redistribution: if you ship a modified BookStack inside a product, keep the MIT notice and check that your internal policy accepts a permissive license.
Before you rely on BookStack for a regulated deployment, ask in writing whether any commercial support or hardening service is available and who would perform it.
A license tells you what you may use and change, but it does not pay for the work that makes a platform fit for your environment. For both XWiki and BookStack, the largest costs are usually implementation, hardening, integration with your identity provider and backup and upgrade routines. Those costs are paid to your staff or to a services partner, and they recur whenever the platform is upgraded or your requirements change.
- Implementation: installation, database setup, theme and content structure, and migration from existing wikis are separate work items.
- Hardening: access control design, TLS, secret handling and review of extensions or macros are not provided by either license.
- Identity integration: connecting SSO, group mapping and provisioning requires configuration and testing in your own environment.
- Operations: backups, upgrades, monitoring and incident response are your responsibility unless you buy a support or retainer contract.
- Support time: the time to diagnose issues and apply patches is an effort cost, whichever license applies.
When you request quotes, ask each vendor or services firm to list these items separately, with who performs them and how often they recur.
Moving content from BookStack to XWiki or back
This sequence gives you a tested path for moving pages, hierarchy and sign-in between BookStack and XWiki, with a clear list of what carries over and what your team rebuilds by hand before users switch.
Inventory shelves, books and spaces
Start by listing every BookStack shelf, book, chapter and page, or every XWiki space, page and attachment, with its owner, last edit date and approximate size. Mark content that is stale, duplicated or unused so it can be archived instead of migrated. Your content owners sign off on the list. The output is a written inventory that becomes the migration baseline, and you know this step is done when every content owner has confirmed their area in writing.
Map hierarchy to the target structure
Translate the source structure into the target model. BookStack shelves and books map to XWiki spaces and child pages, while BookStack chapters map to nested pages, and XWiki's deeper hierarchy may need flattening to match BookStack's three-level model. Record each mapping decision in a shared table. The output is a mapping sheet that a second reviewer has checked, and you know this step is done when every source object has a named destination.
Decide which rights carry over
Compare the access model on each side before moving anything. XWiki grants view, comment, edit and delete rights at wiki, space, page or hierarchy level, so the target rights may be finer than what BookStack's shelf and book permissions express, and the reverse direction usually loses detail. Security and content owners decide which rights are copied, which are simplified and which are redesigned. The output is a signed rights decision record, and you know this step is done when no content area is left with an undecided permission model.
Export and convert page content
Export page content from the source system and convert it into the target format, typically HTML or Markdown depending on the editor each side uses. Test a representative sample of pages first, including tables, code blocks, images and embedded media. Plan to review pages with custom macros, structured data or extension output by hand, because those rarely convert cleanly. The output is a converted sample set that content owners have reviewed, and you know this step is done when the sample shows no loss of text or hierarchy.
Rebuild sign-in and group access
Configure sign-in on the target platform before importing users. BookStack supports OIDC, SAML2 and LDAP sign-in, and XWiki's authentication options should be confirmed in your own environment against the version you run. Recreate groups and map them to the rights decided in the previous step, then test with accounts from each group. The output is a working test login for each role, and you know this step is done when each group sees exactly the content its decision record allows.
Import content and attachments
Load the converted pages into the target in the mapped hierarchy, then copy attachments and images and confirm they open. Run the import in a staging instance first, then repeat it against production during an agreed change window. Keep the source system read-only during the final import so no edits are lost. The output is a staging instance with matching page counts that the owners have accepted, and you know this step is done when a reconciliation report shows the same objects on both sides.
Verify links, attachments and search
Check internal links, image references and attachment URLs, since these often break when paths change. Rewrite broken links in bulk where possible and log the rest for manual repair. Confirm that search returns expected results for a set of known terms. The output is a link and attachment report with every failure either fixed or accepted, and you know this step is done when a sampled crawl shows no unresolved internal references.
Retire the source and document the result
Once owners confirm the target, set the old system to read-only, keep an archived export under your retention policy, and publish a short guide covering the new structure, the rights model and where content moved. Document what was rebuilt by hand, including custom macros, structured data and any extensions, so the next maintainer knows the original intent. The output is a signed cutover record and archive, and you know this step is done when the archive is verified and the guide is published to users.
What drives the running cost of each wiki
The largest difference in running cost between XWiki and BookStack is not the license fee, since both are open source with no license charge. It is who does the work after go-live. With XWiki, you pay for a Java application server, a database, backups and identity integration, and you also pay for staff time to track the parallel release branches the project maintains, test upgrades against your own rights model and extensions, and keep any Pro applications current. If you buy support, hosting or Pro applications from XWiki SAS, those become recurring line items. Ask the vendor for the exact list of applications your design depends on, which of them are Pro, and whether their pricing is per instance, per user or per year. Ask whether support covers upgrades across branches or only troubleshooting.
With BookStack, the infrastructure is lighter: a PHP 8.2 or later application with MySQL 8.0 or MariaDB 10.6 or later, as its installation docs require. Recurring cost is driven mostly by content growth, which increases database size, backup duration and restore time, and by any custom theming or extension work your team maintains through each release. One-time cost sits in migration from an existing wiki and in setting up OIDC, SAML2 or LDAP sign-in. Ask any implementation partner to price migration by page count, attachment volume and link cleanup as separate items, and to state what a theme change costs on each upgrade. For either platform, put the following in a written quote: one-time setup (install, identity, permission design, migration, documentation), recurring upkeep (upgrades, backups, monitoring, support hours), and any third-party or paid components with their renewal terms. Confirm who holds the backup and restore duties and how often restores are tested. Where a figure is not in the vendor's published material, such as XWiki Pro or support pricing, request it in writing rather than estimating from a comparison page.
Questions buyers ask before hiring help with a wiki
How much effort does it take to run a self-hosted XWiki or BookStack?
Both run on your own infrastructure, so the effort is the platform, the database, the identity connection, backups and upgrades. BookStack has a lighter stack: the installation docs call for PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later. XWiki is a Java platform maintained on several parallel release branches, including 18.8.0 published on September 29, 2026 and 17.10.14 and 18.4.7 published on October 15, 2026, so the upgrade path depends on which branch you pick. Confirm the Java runtime, database and hosting model your team already supports before comparing effort, and ask any implementer to estimate upgrade work per branch.
Can an internal team run XWiki or BookStack without outside help?
Yes, many teams do, especially for BookStack, where the shelf, book, chapter and page model is simple to administer. The harder part is usually permission design in XWiki, where view, comment, edit and delete rights can be set at wiki, page or hierarchy level, and mistakes there are easy to make. Ask whether your team has someone who can own Java application upgrades, database maintenance and directory group mapping. If not, an outside partner can plan, implement and document the setup, and then your staff can run it.
What does the work need from our side before a wiki project starts?
Three inputs drive most of the work. First, identity provider access: BookStack supports OIDC, SAML2 and LDAP sign-in, and XWiki's authentication options must be confirmed against your directory before you commit. Second, a rights design that maps your groups to spaces, pages or hierarchies, which is where XWiki needs the most decisions. Third, named content owners who can approve what moves, what gets archived and who signs off on access. Without these, timelines slip regardless of platform.
How long do wiki migrations usually take, and what drives the time?
No supplied figure gives a standard migration duration, so treat any number you are quoted as a planning estimate to verify. The main drivers are the volume and age of content, how many spaces or books need restructuring, whether attachments and page history must be preserved, how many permission rules need translating, and how much cleanup your content owners can do. Ask the implementer to show the migration steps, the test migration on a sample, and how they will reconcile page counts and access rights after cutover.
Do we need XWiki Pro apps to meet our requirements?
Not always. XWiki's core platform is LGPL-2.1-or-later, and XWiki SAS sells support, hosting and paid Pro applications. Before buying any Pro app, list the specific feature you need and check whether the free core or a community extension covers it. Confirm the current license terms for each app with XWiki SAS, since packaging can change. BookStack is MIT licensed and has no paid tier to compare against.
How should we compare a fixed-scope quote with a retainer?
A fixed-scope quote covers agreed deliverables and timelines for a defined piece of work, such as an installation, identity integration, rights model and migration. A retainer covers ongoing support, upgrades and continuous work over time. Compare them by what each includes, what is one-time versus recurring, and who is paid for what. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and does not publish a price list, so ask for a quote tied to a written scope and check which upgrades, backups and testing are covered after go-live.
What does a buyer need to confirm about security and compliance readiness?
Ask how access is governed, how page changes are retained and who can delete content. XWiki keeps every page change under version control, which supports audit questions, but you still need to confirm retention settings and backup coverage in your environment. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so confirm with your independent auditor which evidence they will expect.
Where XWiki and BookStack projects usually run long
The longest XWiki and BookStack projects rarely stall on installation. They run long when the rights model, the content inventory and the ownership of spaces are decided late. Decide the permission design before any migration starts. For XWiki, that means mapping who needs view, comment, edit and delete rights at wiki, space and page level, then deciding which of those rules can be expressed through group membership rather than per-page exceptions. For BookStack, the equivalent work is deciding how shelves, books and chapters map to teams, and whether the built-in role and permission settings cover the access pattern without custom workarounds. Confirm the sign-in path early as well: BookStack supports OIDC, SAML2 and LDAP sign-in, and XWiki's authentication options should be confirmed against the version you plan to run with your identity provider and group sync rules.
Sizing and installation are usually the simpler parts. BookStack requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, as listed in its installation documentation, so the database and PHP runtime should be confirmed against your hosting standard before the build. For XWiki, confirm the supported Java and database combination for the release line you choose, since XWiki maintains several branches in parallel. Content cleanup is where scope most often grows. Duplicate pages, abandoned drafts and pages with no named owner tend to surface only once the source wiki is exported. Agree in writing who decides whether a page is migrated, archived or deleted, and who signs off each space or book. Editor training should follow the chosen editing style: BookStack offers a WYSIWYG editor with an optional Markdown editor, so decide which one the team will standardize on before writing the editor guide.
A fixed written scope limits these risks because it forces the open questions into the document before work begins. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms inside the client's own environment, so the scope can state which of these services apply to each platform, who owns the rights matrix, who approves content decisions, and what training and handover are included. Ask any vendor or implementation partner to show the permission model as a worked table, the cleanup rules as a checklist, and the acceptance criteria for each migrated space. Where a scope item depends on a feature you have not yet confirmed, such as a specific XWiki app or an identity integration detail, record it as an assumption with an owner and a date to resolve it.
How DeployOpen helps choose and implement a wiki
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For XWiki vs BookStack, we start from your content volume, permission model and editing habits, then deliver the platform in your cloud account, data center or air-gapped network.
How we scope
- We map which spaces, books or sections need fine-grained rights and which need only simple shelf-level access.
- The written scope lists identity sources such as SAML, OIDC or LDAP and the sign-in flows each platform must support.
- We confirm current license terms and any paid XWiki Pro applications before the scope is agreed in writing.
How we build
- We install the chosen platform and its database, then configure permissions, authentication and backups to the agreed design.
- Where XWiki structured data is needed, we design the data model and test it against real page templates before rollout.
- We test permission boundaries with sample users from each group to confirm access matches the written rights design.
How we hand over
- We deliver runbooks covering upgrades, backups, restores, user onboarding and permission changes for your own staff.
- We migrate existing content in agreed batches and document how page history and attachments were handled.
- Handover includes a walkthrough of editing conventions so authors and administrators know where content belongs.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover is complete.
- Retainers can cover tracking of XWiki release branches or BookStack releases, with upgrades tested before production.
- Ask any provider which upgrade, backup and access-review tasks are included in the retainer and which are billed separately.
