XWiki vs Docmost: which to choose for Confluence exits

Which wiki fits a Confluence exit: XWiki or Docmost

A team leaving Confluence and needing a self-hosted replacement should choose XWiki when its knowledge is highly structured, its access rules must reach down to individual pages, and it expects to extend the wiki with applications. Choose Docmost when the priority is a lighter, real-time collaborative editor that a small or mid-sized team can adopt quickly, and when the AGPL-3.0 core is the license position it wants. XWiki favors structured enterprise knowledge with fine-grained rights and an extension ecosystem, with the *LGPL 2.1* license covering the platform. Docmost favors a faster-moving editing experience, with its core under AGPL-3.0 and its enterprise code under a separate Docmost Enterprise license.

The license split matters more in Docmost than it first appears. Its paid-edition list includes SSO with SAML 2.0 or OIDC, LDAP, SCIM provisioning, MFA, page-level permissions and the Confluence importer, so a team that needs any of those must price a Business or Enterprise plan before it commits. Confirm with Docmost which of these features its current edition includes, and check the Docmost pricing page for the seat minimum and what Enterprise adds. XWiki's Pro subscriptions are the comparable paid layer, and they also carry the Confluence migration tooling, which is priced separately. Ask both vendors for their current feature matrix in writing before comparing costs.

The decision turns on four questions. First, how structured is the content: long hierarchies with templates and data inside pages point toward XWiki, while flatter, document-style spaces suit Docmost. Second, how deep must permissions go, and whether page-level control is a requirement or a nice-to-have. Third, which SSO and SCIM provisioning features are mandatory, and whether they must be available on the free edition. Fourth, whether your team is stronger in Java or Node.js, since XWiki runs on Tomcat with a Java stack and Docmost runs on Node.js with PostgreSQL and Redis. Answer these before running an import test, because the import path is the step that is hardest to reverse.

Which scenario favors XWiki and which favors Docmost

This table maps common team situations to the platform that fits better and the condition that decides it. Read each row as a starting point, then check the condition against your own permission model, identity setup and compliance scope. The main takeaway is that XWiki suits deep structure and rights hierarchies, while Docmost suits lighter collaborative notes, provided you accept that SCIM and audit logs sit in its paid Enterprise tier.

Scenario	Better fit	Condition that makes it so
Deep permission hierarchies across many spaces and sub-trees	XWiki	XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level, which fits layered access models better than a flatter space model.
Structured or form-like data such as registers, inventories or request records	XWiki	Structured wiki data and Pro applications such as Forum, Polls and Calendar suit records that need consistent fields, provided you confirm which Pro apps your use case needs.
Real-time co-authoring of meeting notes and team docs	Docmost	Docmost lists real-time collaboration in its core README, so it fits teams that mainly want simultaneous editing. Remember that a reverse proxy must allow WebSockets.
Diagrams and mixed embeds inside everyday pages	Docmost	Draw.io, Excalidraw and Mermaid diagrams are listed among Docmost's core features, which keeps lightweight diagramming inside the wiki.
Small team with no SSO requirement	Docmost	Email and password sign-in and TOTP multi-factor authentication are available in the free self-hosted edition, so Docmost needs less setup. Confirm the team stays within its free edition's needs.
Regulated environment requiring SCIM provisioning and audit logs	Neither by default, check editions	Docmost lists SCIM and audit logs as Enterprise features, and XWiki's SSO and permission depth depends on Pro apps and extensions. Ask both vendors which edition and extensions meet your control set.
Organization with existing SAML or OIDC directory and group-based access	XWiki	Verify whether the Pro SSO application or the xwiki-contrib OIDC extension fits your identity provider, because SSO support differs by edition and extension.
Confluence migration with page history and attachments to preserve	Confirm with each vendor	XWiki SAS offers Confluence migration services and Confluence Migrator Pro, which keeps page history but not attachment history; Docmost's Confluence importer is a paid-edition feature. Test both on a sample space first.

How XWiki and Docmost are built and deployed

XWiki and Docmost take different routes to a self-hosted wiki: a Java servlet application on Tomcat with three release lines, and a Node.js application with a PostgreSQL and Redis backing layer. The differences show up later, in how you upgrade, where you put backups and how users reach the real-time editor.

XWiki runs as a Java app on Tomcat

The official XWiki Docker images run on Tomcat and come in MySQL, PostgreSQL and MariaDB variants, for amd64 and arm64v8. The database choice is fixed when you build the stack, so confirm it against your existing database standard before you install. Your platform team will also need a Java-aware monitoring and patching routine for the application server, not only for the database and container host.

Three XWiki release lines

XWiki publishes a stable line, a long term support line and an intermediate LTS line. 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. Choosing the LTS line trades newer features for a slower, more predictable upgrade cadence, so ask which line your extensions and Pro apps support before you pick one.

Docmost is a Node.js app with two services

Docmost's compose template runs the application alongside PostgreSQL 18 and Redis 8 images, and Docker is its recommended installation method. Your backup scope covers the database, Redis state where it matters to your sessions, and the file store. Ask your team who owns Redis patching and failover, because it is a second stateful service that a Confluence-style wiki admin may not have run before.

Docmost stores files locally by default

Docmost keeps attachments on local disk unless you configure S3-compatible or Azure Blob storage. Local storage makes a simple single host workable, but it means file backups and disk capacity become your problem from day one. If you plan to scale out or meet a retention policy for attachments, decide on object storage before go-live, since moving files later adds a migration step.

WebSockets at the reverse proxy

Docmost's real-time editor needs WebSockets enabled on any reverse proxy in front of it, so a proxy rule that works for ordinary HTTP can still break live co-editing. Test collaborative editing from two browsers through your actual proxy and load balancer. XWiki does not have this requirement in the same form, so the check belongs only on the Docmost side of your design.

Secret handling and version pinning

Docmost requires an APP_SECRET of at least 32 characters, so generate it once, store it in your secrets manager and back it up with the database, since rotating it later affects your deployment. Pin image tags for both platforms rather than tracking latest, and make upgrades a scheduled change with a restore test. Confirm each platform's upgrade notes with the vendor before you plan the window.

Permissions, SSO, editing and import compared feature by feature

This table compares how XWiki and Docmost handle rights, single sign-on, version history, real-time editing, diagrams and Confluence import. Read the paid edition column first, because several features that matter for enterprise rollout sit behind Docmost's Business or Enterprise plans or XWiki Pro.

Capability	XWiki	Docmost
Rights granularity	Wiki, page and hierarchy level view, comment, edit and delete rights, per XWiki's product description	Spaces and permissions management with groups; page-level permissions are listed as a paid-edition feature
Single sign-on	XWiki Pro lists Active Directory and Azure Active Directory SSO applications; xwiki-contrib/oidc is a community extension to confirm for your IdP	LDAP, SAML or OIDC are listed as authentication methods; SAML 2.0 or OIDC SSO is a paid-edition feature
User provisioning	Confirm SCIM or directory sync options with XWiki SAS for your identity stack; not covered in supplied facts	SCIM provisioning is a paid-edition feature, listed under Enterprise pricing
Multi-factor authentication	Confirm MFA options and extensions for your environment before deciding	TOTP multi-factor authentication is listed among authentication methods; MFA is also a paid-edition feature
Version history	Every page change is kept under version control, per XWiki's product description	Page history is included in the core feature list; confirm retention and restore behavior in your test instance
Real-time editing	Confirm co-editing behavior in the version you plan to run before relying on it	Real-time collaboration is a core feature; reverse proxies need WebSockets enabled
Diagrams	Confirm diagram tooling through XWiki Pro apps such as Diagram before standardizing on it	Draw.io, Excalidraw and Mermaid diagrams are listed in the core README
Confluence import	Confluence Migrator Pro from XWiki SAS moves spaces, pages, users, groups, permissions and attachments, keeps page history but not attachment history	Confluence importer is a paid-edition feature; Markdown, HTML, DOCX and Notion ZIP imports are listed

What the free and paid editions of each platform include

XWiki is licensed under the LGPL 2.1, and its official Docker image repository is also LGPL 2.1. XWiki Standard is the free open source version. XWiki SAS sells XWiki Pro, which combines XWiki with business applications, connectors and XWiki SAS support. Pro subscriptions are tiered by user count, and XWiki SAS states that cloud and on-premises pricing is the same.

LGPL 2.1 licensing: The core and the official Docker images are LGPL 2.1, which governs how you may modify and redistribute the code. Confirm the terms with your legal team for your own distribution model.
XWiki Standard (free): The open source version you can install and run without a subscription. Support then comes from your own staff or a partner you contract separately.
Pro tiers by user count: Starter (up to 25 users, XWiki Cloud only), Basic (up to 1,000 users), Business (up to 10,000 users) and Enterprise (unlimited users).
Pro applications and connectors: The Pro page lists Active Directory and Azure Active Directory SSO applications, File Manager, Forum, Polls, Calendar, and Google Apps, Office365 and OnlyOffice connectors. Check each application's license scope against the tier you buy.
Services priced separately: XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day.

Ask XWiki SAS to confirm in writing which Pro applications and support hours your tier includes, and whether the same tier applies to your deployment model.

Why SSO, SCIM and permission features sit behind paid editions

The license split matters most for a regulated team because the controls an auditor asks about first, single sign-on, user provisioning and fine-grained permissions, are where the two platforms draw their paid lines. Docmost's documentation lists SAML 2.0 or OIDC single sign-on, LDAP, SCIM provisioning, MFA, and page-level permissions as paid-edition features, while its free self-hosted Community edition still offers email and password, LDAP, SAML or OIDC sign-in and TOTP multi-factor authentication as authentication methods. That means the free edition can meet a team's needs only if its identity provider is reachable through the methods the documentation lists for Community, and if spaces and groups, rather than individual page rights, are enough to separate content. Confirm the current contents of each tier on Docmost's pricing page before you plan around them, because edition boundaries change between releases.

XWiki takes a different route. XWiki Standard is the free open source version under LGPL 2.1, and its built-in rights model grants view, comment, edit and delete rights at wiki, page or hierarchy level, so granular permissions are not in themselves a paid feature. The paid decision sits elsewhere: XWiki Pro lists Active Directory and Azure Active Directory SSO applications, and support subscriptions are tiered by user count. A team that needs directory SSO on XWiki should therefore price an XWiki Pro application or a support plan as a line item, and should check with XWiki SAS whether an open source OIDC extension, such as the one in the xwiki-contrib repository, meets its identity provider requirements. Ask both vendors to state in writing which features the quoted edition includes, because this determines whether a paid license, a Pro application or a free extension closes the gap.

Ask for a feature matrix tied to your identity provider, your provisioning process and your permission model, then test each claim in a staging instance before signing. A Docmost Business plan or an XWiki Pro subscription can be the right answer for a team that needs SCIM or directory-backed SSO on a schedule, but it becomes a recurring cost tied to seats or users, which should appear in the total cost of ownership next to the one-time migration effort. Record the decision and the vendor's written answer, since an auditor will ask who controls access and how it was verified.

What drives the running cost of each wiki

Running either wiki costs more than its license line. The main drivers are the hosting footprint, the skills your administrators already have, the paid tiers that unlock SSO and permissions, and the upgrade work you will repeat for years. Each card below names one driver and what to confirm before you commit.

Hosting and database footprint

XWiki's official Docker images run on Tomcat and come in MySQL, PostgreSQL and MariaDB variants, so the database choice is yours to make. Docmost's Docker template runs PostgreSQL 18 and Redis 8 alongside the application, and it needs WebSockets enabled on any reverse proxy for the real-time editor. Ask both vendors for the memory, CPU and storage they expect at your user count, and whether the Redis dependency adds a service your operations team must back up and monitor.

Administrator skills: Java versus Node.js

XWiki runs on the Java and Tomcat stack, so your team will need someone comfortable with JVM tuning, servlet containers and XWiki's extension model. Docmost runs on Node.js with PostgreSQL and Redis, which matches many web platform teams but is a different operational profile. Check which skills you already staff, who covers on-call, and whether a partner's training can close the gap before go-live.

Paid tiers that gate SSO and permissions

For Docmost, SAML 2.0 or OIDC single sign-on, LDAP, SCIM provisioning, MFA and page-level permissions sit in paid editions, so a self-hosted Community install may not meet an identity requirement on its own. XWiki Pro bundles Active Directory and Azure Active Directory SSO applications with its Pro apps. Map every identity and permission requirement to the edition that includes it before you compare totals.

Per-seat fees and user caps

Docmost's Business plan is priced at $6 per seat per month billed annually, with a 10-seat minimum, and Enterprise is custom priced. XWiki Pro and support subscriptions are tiered by user count: Starter for up to 25 users on XWiki Cloud only, Basic up to 1,000, Business up to 10,000 and Enterprise unlimited. The recurring cost of each model grows differently as headcount and guest access change, so model both at your expected growth.

One-time services: consulting, training and migration

XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day. Confluence Migrator Pro starts at 2000 EUR, and its trial is limited to 30 pages per migration. These are one-time or project costs, separate from subscriptions. Ask for the days, the named deliverables and the migration scope in writing, and whether attachment history is included.

Upgrade effort on each side

XWiki maintains a stable line, an LTS line and an intermediate LTS line in parallel, so you choose which branch to run and when to move between them. Docmost ships through tagged releases, with v0.96.0 tagged on September 8, 2026. Plan the cost of extension compatibility checks, database upgrades, and reverse proxy changes at each move, and ask each vendor for its upgrade notes and support window in the quote.

Moving content from Confluence into either platform

This sequence moves approved Confluence spaces into XWiki or Docmost with a written record of what transferred, what was skipped, and who owns each gap before cutover. Each step ends with a check against the inventory you build first.

Inventory spaces, users and permissions
List every Confluence space with its page count, attachment volume, user and group membership, and any page-level restrictions. Mark each space as live, archived or retired, and ask the space owner to confirm which ones move. A Confluence administrator usually runs this inventory, and the wiki owner signs off on the scope. The step is done when every space has a named owner, a restriction list and a status, and that sheet becomes the baseline for every later check.
Choose the importer for each target
Decide how each platform will receive the content. For XWiki, the Confluence Migrator Pro extension migrates spaces, pages, users, groups, permissions, attachments and metadata, keeps page history but not attachment history, and is priced from 2000 EUR per the XWiki Store listing. For Docmost, the Confluence importer is listed among paid-edition features, so confirm the edition and its cost in writing before testing. The output is one written importer choice per target with license costs confirmed.
Test with one sample space
Run a trial migration of one representative space on a staging instance. The Migrator Pro trial is limited to 30 pages per migration, so pick a space that fits within that limit, or plan batches if the trial is the path you take (illustrative: a space of 60 pages would need at least two runs). Check how tables, images, cross-page links and Confluence macros render on each target. An editor from each team that uses the space should review the output side by side and sign off.
Map permissions and groups first
Translate Confluence space permissions and page restrictions into each target's model before the full run. XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level, which covers most space-level and restricted-page patterns. Docmost organizes access through spaces, groups and permissions, but page-level permissions and SCIM provisioning are listed among paid-edition features, so restricted pages may need a paid plan or a manual rebuild. The output is a mapping table showing each group, its target role and any restriction that cannot carry over.
Run the full migration on staging
Import the approved spaces into a staging instance, in batches if volume calls for it, and keep the import log for each run. Expect XWiki to carry page history over while attachment history stays behind, and record that gap in the cutover notes. For Docmost, record which content types imported cleanly and which were skipped or flattened. The step is done when every space has a logged result and every skipped item appears on a list with a named owner.
Validate links, attachments and users
Compare the staging results with the step one inventory. Check internal links, including links that cross spaces, attachment counts and file integrity, and page history where it was promised. Confirm that restricted pages block users who should not see them, and that users sign in through the identity provider you plan to run, since SSO depends on the edition you select. The step is done when the validation sheet lists no unexplained gaps.
Rebuild what does not transfer
Recreate the macros, custom layouts and attachment history that did not move, and document each rebuilt item with an owner. Plan for the switching cost: a later move to the other platform repeats the export, mapping and validation work, and history lost in the first move cannot be recovered from the new platform. Keep the Confluence export archived until the business confirms it is no longer needed. Ask each vendor, in writing, which importer features are dropped.

Where XWiki and Docmost projects usually run long

The longest stretches in an XWiki or Docmost project are rarely the installation. They are the permission model in XWiki, the identity wiring for SSO and SCIM, the reverse proxy in front of Docmost, the cleanup after import, and the habits of the people who will write in the wiki. Plan time and named owners for each of these before the first migration batch runs. In XWiki, the rights model is set at wiki, space, page and hierarchy level, so a design that grants view, comment, edit and delete rights by group should be written down and tested with a small set of accounts before any content moves. Ask your team who approves changes to that design, because rights drift is the most common reason a structured wiki becomes hard to trust.

Docmost's real-time editor depends on WebSockets passing through your reverse proxy, and the Docker installation documentation calls this out directly. Confirm early that your proxy forwards WebSocket upgrades, that APP_SECRET is set to at least 32 characters, and that the stack matches the PostgreSQL 18 and Redis 8 images in the compose template. On the identity side, SAML 2.0 or OIDC single sign-on and SCIM provisioning are paid-edition features in Docmost's documentation, so confirm with Docmost which edition covers each control you need before the identity team starts. Both platforms require someone on your side who can own the identity provider configuration and the group mappings that feed permissions.

Import work tends to take longer than expected. Docmost accepts Markdown, HTML, DOCX, Notion and Confluence exports, but links, attachments and internal page references usually need rewriting after the move, and the Confluence importer is a paid-edition feature. XWiki's Confluence Migrator Pro keeps page history but not attachment history, so decide whether attachment history matters to your auditors before you choose a path. Finally, plan user training around the structure decision. XWiki rewards teams that agree on spaces, page templates and naming conventions, while Docmost's freer editing suits teams that accept lighter structure. An implementation partner can help with the permission design review, the proxy and identity runbooks, and migration testing, and should be asked to work to the same written scope for both platforms.

Questions buyers ask before choosing XWiki or Docmost

What does it cost to run XWiki or Docmost ourselves?

Both self-hosted cores are free to download, so the recurring cost is people and infrastructure, not licenses. For XWiki, the supplied pricing covers XWiki Pro and support subscriptions in Starter, Basic, Business and Enterprise tiers, with user caps of up to 25, 1,000, 10,000 and unlimited users, and XWiki SAS states cloud and on-premises pricing is the same. For Docmost, the supplied pricing lists a Business plan at $6 per seat per month billed annually with a 10-seat minimum, and Enterprise at custom pricing. Ask each vendor for a written quote covering your user count, support hours and paid features, then add the staff time to run upgrades and backups.

How long does a Confluence migration take, and what drives it?

No supplied figure gives a duration, so treat any timeline as something to confirm in writing. The main drivers are the number of spaces and pages, how much attachment and page history you need to keep, how many users, groups and permissions must map cleanly, and how much content needs manual cleanup afterward. XWiki's Confluence Migrator Pro keeps page history but not attachment history, and a trial is limited to 30 pages per migration. Docmost's documented importers include Confluence, but the paid-edition list includes the Confluence importer, so confirm which edition your import requires before you plan.

Can an internal team run either platform without outside help?

Yes, both are self-hosted open-source products, so an internal team can run them if it has the skills. XWiki is packaged as official Docker images with MySQL, PostgreSQL and MariaDB variants running on Tomcat, and XWiki maintains stable and LTS lines, which helps with planning upgrades. Docmost recommends Docker, with a compose template that uses PostgreSQL 18 and Redis 8, requires an APP_SECRET of at least 32 characters, and needs WebSockets enabled on the reverse proxy for real-time editing. Outside help is most useful for migration, customization, hardening and upgrade planning. Ask any partner for a fixed-scope written plan before work starts.

Which edition do we need for SSO and SCIM?

Check the paid-edition list before you commit, because the answer differs by product. Docmost's documentation lists SSO with SAML 2.0 or OIDC, LDAP, SCIM provisioning and MFA among paid-edition features, while its community edition lists email and password, LDAP, SAML or OIDC, and TOTP as authentication methods. Its pricing page places SCIM under Enterprise. XWiki Pro lists Active Directory and Azure Active Directory SSO applications, and XWiki's OIDC support is available through the xwiki-contrib/oidc project. Confirm with XWiki SAS which SSO options work in Standard and which need Pro, and confirm your identity provider's protocol before you buy.

How hard is it to switch away from either platform later?

Switching is practical if you keep content portable from the start. Docmost exports pages or whole spaces as Markdown or HTML, and its import dialog accepts Markdown, HTML, DOCX, Notion and Confluence exports. XWiki stores every page change under version control, which helps when you need history in a new system, but the Confluence migration tool is an XWiki product and does not cover the reverse path. Ask each vendor for the export formats, what happens to attachments and permissions, and whether the export preserves page history before you rely on either tool as your system of record.

Is Docmost's AGPL core enough for a regulated team?

The core is AGPL-3.0, but code in the enterprise paths is under the Docmost Enterprise license, so a regulated team should not assume the full feature set is open. Docmost's README places code in the server, client and shared ee directories under that enterprise license. Have legal review both licenses, and confirm which features your controls depend on, such as SCIM, audit logs and SIEM integration, are included in the edition you plan to run. XWiki is LGPL-2.1-or-later, and its paid Pro applications are a separate commercial offering that your counsel should also review.

Does the Java or Node.js stack change how we run it?

Yes, the stack changes the skills, runtime and upgrade routine your team carries. XWiki runs on Tomcat from official Docker images, so Java application servers, JVM tuning and Tomcat patching sit in your operating model. Docmost runs on Node.js in its documented Docker setup with PostgreSQL 18 and Redis 8, so you need Node and Redis operations skills and attention to WebSocket configuration. Neither stack is inherently harder, but your team's existing expertise should decide the choice. Confirm each vendor's supported versions for the database and runtime you intend to use.

How DeployOpen helps choose and implement either 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 Docmost, that means working from your Confluence estate, permission model and SSO requirements to a written scope before any build starts.

How we scope

Inventory Confluence spaces, page volume, attachments, users, groups and permissions before choosing a target.
Confirm which SSO, permission and import features your chosen edition must include, and which sit in paid tiers.
Agree scope, deliverables and timelines in writing; most engagements are fixed-scope.

How we build

Deploy the chosen wiki in your cloud account, data center or air-gapped network, with its database and file storage.
Configure SSO, groups and space or page permissions, and test them with representative users before migration.
Run a trial import on a sample of spaces, then check page history, attachments and links against the source.

How we hand over

Document the architecture, reverse proxy and WebSocket settings, backup and restore steps, and upgrade procedure.
Provide runbooks for administrators covering permissions, user provisioning and extension or plugin management.
Walk your platform and security teams through the handover so they can operate the wiki without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Plan upgrades around each product's release lines, so you know which branch you run and when to move.
Ask any provider to confirm which features your edition includes before you rely on them in production.

XWiki vs Docmost