XWiki vs Wiki.js: which wiki to choose

XWiki or Wiki.js: which self-hosted wiki fits your team

If you are replacing Confluence or consolidating team documentation into one self-hosted wiki, the choice between XWiki and Wiki.js turns on how much structure and permission control your content needs and how much maintenance effort you can carry. XWiki fits teams that need structured pages, fine-grained rights and a heavier Java operations model. Wiki.js fits teams that want Markdown-style editing, a lighter footprint and a Node.js stack. Both are open source, so the decision is about operating fit, not licensing alone.

Choose XWiki when your documentation has real hierarchy, when rights must be set at wiki, page or hierarchy level, or when you expect to manage structured data and extensions over several years. XWiki publishes a stable line, a long term support line and an intermediate LTS line, so you can match an upgrade cadence to your change process. Its official Docker images run on Tomcat with MySQL, PostgreSQL or MariaDB variants, which suits a team already operating Java services. Plan for the Java runtime, database tuning and extension review that come with that choice.

Choose Wiki.js when your editors work in Markdown, your hosting is Node.js or container based, and your permission model is simpler. It recommends PostgreSQL, supports several other databases, and runs on Linux, Docker and Kubernetes. Because the stable 2.x line sits in a separate repository while 3.0 is still marked beta and not for production use, confirm your tolerance for maintaining 2.x now and planning a later migration. The decision turns on four points: permission depth, content structure, SSO needs and that upgrade risk. Check each against your current Confluence spaces before you commit.

Which wiki fits which team scenario

This table matches common team scenarios to the wiki that fits better, naming the condition that drives each choice. Read each row against your own permission model, ops capacity and network constraints, since the deciding factor changes with them.

Scenario	Better fit	Condition that drives the choice
Confluence replacement with page-level permissions	XWiki	XWiki grants view, comment, edit and delete rights at wiki, page or hierarchy level, which matches fine-grained Confluence-style access. Confirm the exact rights model against your Confluence space permissions before migrating.
Developer-led docs site with Markdown and Git	Wiki.js	Wiki.js 2.x offers Markdown-style editing and Git storage that syncs content in both directions. Choose it when engineers want content in a repository, and confirm the Git module fits your review workflow.
Regulated team needing audit-friendly version history	XWiki	XWiki markets version control on every page change. Pair it with your own retention and review evidence, since DeployOpen prepares controls but does not issue audit reports.
Small team with minimal ops capacity	Wiki.js, if a single database and simple upgrades matter most	Wiki.js 2.x needs its own domain and at least 1 GB of RAM on Linux, and it supports SQLite for small installs. XWiki runs on Tomcat with a separate database, so weigh that extra stack against your team's capacity.
Air-gapped network	Depends on sideloading and dependencies	Wiki.js supports sideloading files for environments without internet access. Confirm with XWiki how its images, extensions and updates reach an isolated network before choosing.
Long-term maintenance risk	XWiki	XWiki maintains parallel stable and LTS branches. Wiki.js 3.0 is still beta and marked not for production use, so the stable line depends on the 2.x branch until you confirm a 3.0 release plan.
Enterprise SSO and directory integration	XWiki (confirm edition)	Wiki.js lists SAML 2.0, OpenID Connect and LDAP modules. XWiki Pro lists Active Directory and Azure AD SSO applications in paid tiers, so confirm which features your edition includes.

How XWiki and Wiki.js are built and what that means for operations

XWiki and Wiki.js take very different routes to the same job: a Java application server on one side, a Node.js process on the other. The stack determines what your team patches, how you back up the database and files, and which engineering skills you need on call. The cards below cover the decisions that follow from those build choices.

Java and Tomcat runtime for XWiki

XWiki runs as a Java web application on Tomcat, and the official Docker images are published in MySQL, PostgreSQL and MariaDB variants, each on Tomcat, for amd64 and arm64v8. Patching therefore covers the base image, the Java runtime and the XWiki release itself. Confirm with your platform team whether they already run Tomcat and Java services, because that experience carries over directly.

Database choice for XWiki

The official XWiki images let you pick the database engine at build time, so the choice is made once and then shapes backups, replication and restores. Ask which engine your DBA team can operate and back up to your standard. Changing engines later is a migration project, not a configuration switch, so decide before the first content load.

Node.js runtime for Wiki.js

Wiki.js runs wherever Node.js is supported, including Linux, macOS, Windows, Docker and Kubernetes. Your team patches the Node.js runtime, the Wiki.js release and its npm dependencies, so the upgrade path looks more like a typical JavaScript service. Confirm that your security scanning covers npm packages before you adopt it.

Dedicated domain and host sizing

Wiki.js requires a dedicated domain or subdomain and cannot be mapped to a subfolder of an existing site, which affects DNS, certificates and reverse proxy design. Linux systems need at least 1 GB of RAM. Confirm this with your network team early, because a subfolder layout on an existing portal is not an option.

Wiki.js database support and PostgreSQL

Wiki.js 2.x recommends PostgreSQL 9.5 or later and also supports MySQL 8.0 or later, MariaDB, MS SQL and SQLite. The PostgreSQL search module needs the pg_trgm extension, which your DBA must enable. Choose the engine your team already backs up and restores, and check that the search extension is allowed on your managed database service.

Staff skills and version tracking

XWiki is typically operated by teams comfortable with Java, Tomcat and structured wiki administration, while Wiki.js suits teams fluent in Node.js and Git-style workflows. Wiki.js 2.x is the stable line, and the 3.0 beta is marked not for production use, so track which branch you deploy. Ask each vendor for its supported upgrade path and plan staff training against that path.

How long-term maintenance risk differs between parallel XWiki branches and Wiki.js 2.x

XWiki gives you a choice of release line, and that choice sets your upgrade cadence. XWiki maintains several branches in parallel. The stable line is at 18.8.0, published on September 29, 2026. The intermediate LTS line is at 18.4.7 and the LTS line is at 17.10.14, both published on October 15, 2026, and a 16.10.19 release from October 2, 2026 shows that older branches also receive builds. The official Docker image tags follow the same split: 18.8.0 for stable, 18.4.7 for the intermediate LTS and 17.10.14 for LTS. Teams that want new features should track stable and expect to upgrade often. Teams that want fewer, planned upgrades should pick an LTS line and budget for the move to the next one. Confirm the support window of each line on the XWiki release pages before you set a schedule, since the window is what determines how long a branch stays patched.

Wiki.js 2.x is the stable line, and 3.0 is not yet a production option. The stable 2.x code lives in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. The main requarks/wiki repository holds Wiki.js 3.0, which its README marks as beta and not for production use. For a Wiki.js deployment, that means you are choosing 2.x today and should plan for an eventual move to 3.0 as a separate, tested project rather than an in-place upgrade. Write that move into the plan: back up the database, keep a staging copy with the same authentication and storage modules, and test your Git or cloud storage sync and your SSO login before cutover. Note that the 2.x database, module and domain settings are the things most likely to change, so record them now.

Before you commit to either product, ask the maintainers two questions in writing. For Wiki.js, ask when 3.0 will leave beta, whether a supported migration path from 2.x will be published, and how long 2.x will receive security fixes after that. For XWiki, ask which branch is designated LTS, how long each line is patched, and what the recommended path is from an LTS line to the next one. If you run a support contract or a DeployOpen engagement, put the answers and the chosen release line in the written scope so that upgrade work, testing and rollback are priced and scheduled up front. The answers to these questions matter more to long-term risk than the current version numbers.

Feature comparison: permissions, SSO, storage and editing

This table compares XWiki and Wiki.js on license, rights granularity, page history, SSO, storage and database support. Read each row against your own requirements, since a gap on one row matters only when your content model, identity provider or hosting model depends on it.

Capability	XWiki	Wiki.js 2.x
License	LGPL-2.1-or-later for the platform and official Docker images. Weaker copyleft than AGPL, which matters if you modify and redistribute XWiki itself.	AGPL-3.0. Network use of a modified version can trigger source disclosure, so confirm this fits your legal review if you change the code.
Rights granularity	View, comment, edit and delete rights can be set at wiki, page or hierarchy level. Advantage applies when you need section-level access for different departments.	Access control is coarser and is handled through its own permission model. Confirm in the Wiki.js admin guide that it meets your per-space requirements before you commit.
Page change history	Every page change is kept under version control. Useful when auditors or content owners need to see who changed what and when.	Page versioning is available in the 2.x line. Confirm retention, diff display and restore behavior in your own test instance.
Editing style	Structured pages with macros, typed data and applications. Suits teams that want forms, data and reusable components inside the wiki.	Markdown-based editing with a visual option. Suits teams that prefer plain text and Git-friendly content, but offers less structured data.
SSO and identity modules	Active Directory and Azure Active Directory SSO applications are listed as XWiki Pro features. Advantage applies if your identity estate is Microsoft-centric and you accept a paid subscription.	Modules include Azure AD, Keycloak OpenID Connect, generic OpenID and OAuth2, Okta, LDAP and Active Directory, and SAML 2.0, with TOTP two-factor authentication. Advantage applies if you need SAML or OIDC without a paid tier.
Storage backends	Content is stored in the wiki database. Confirm backup and export procedures with your DBA and operations team.	Git, AWS S3 and DigitalOcean Spaces storage modules are available. Git sync runs in both directions for some modules, which helps teams that want content in version control. Confirm sync conflict handling before relying on it.
Database support	Official Docker images come in MySQL, PostgreSQL and MariaDB variants on Tomcat. Confirm your chosen database version against the XWiki installation notes.	PostgreSQL is recommended (9.5 or later), with MySQL 8.0 or later, MariaDB, MS SQL and SQLite. Confirm pg_trgm is enabled if you use PostgreSQL search.

What is free and what is paid in XWiki and Wiki.js

XWiki Standard is the free, open source version of the platform, published under the LGPL 2.1 license. You can download, run and modify it inside your own infrastructure without a subscription. The license cost is zero, but the work of installing, upgrading, backing up and customizing the wiki stays with your team or with a services partner you hire.

No license fee: Standard carries no subscription, so the recurring spend depends on the people and services you choose to add.
Official images: Docker images for MySQL, PostgreSQL and MariaDB on Tomcat are maintained by the XWiki Core Dev Team, with stable, LTS and intermediate LTS tags.
Services are separate: On-premises support, installation help and training come from XWiki SAS as paid engagements.
Extensions outside Pro: Pro applications and connectors are not part of Standard, so any feature you need from them must be built, sourced or licensed separately.

Confirm with XWiki SAS which extensions you need for single sign-on and connectors, and whether each is in Standard or only in a Pro subscription.

What drives the running cost of each wiki

This table lists the cost components of running XWiki and Wiki.js yourself, who is paid for each, and whether it is one-time or recurring. Use it to build a like-for-like quote request, since the platforms differ most in paid support, extension upkeep and the version lines you must track.

Cost driver	XWiki	Wiki.js
Infrastructure	Java application server (Tomcat) plus a supported database (MySQL, PostgreSQL or MariaDB) in the official Docker images; size for your user count and attachments	Node.js app plus PostgreSQL recommended, with MySQL, MariaDB, MS SQL or SQLite also supported; Linux needs at least 1 GB of RAM
Administrator skills	Java servlet container tuning, XWiki extension management and structured-page administration; plan for a Java-literate operator	Node.js service operation and database administration; a dedicated domain or subdomain is required, and the PostgreSQL search module needs pg_trgm
Pro subscription or support	Optional: XWiki Pro and support tiers are recurring, with the same pricing in cloud and on premises per XWiki SAS; Pro apps and connectors are only in paid plans	Wiki.js is AGPL-3.0 with no paid edition in the supplied facts; support comes from your own staff or a third party you contract
Upgrade effort	Several maintained branches (stable, intermediate LTS, LTS) let you choose a cadence, but each move between lines is a planned migration you test and schedule	Stable 2.x is maintained in its own repository; 3.0 is beta and not for production, so a move to 3.0 is a future one-time migration to budget for
Extension maintenance	Extensions and Pro apps need compatibility checks against the chosen XWiki line; recurring effort if you run many custom macros	Authentication and storage modules (for example Git, S3, Keycloak OIDC, SAML 2.0) need configuration checks after each update
Backups and content operations	Versioned page history is built in, but full database and attachment backups remain your recurring task	Storage and sync configuration, such as Git two-way sync, adds recurring checks; backups of the database remain your task
Outside help (one-time or recurring)	Migration from Confluence is quoted separately (for example the Confluence Migrator Pro starting price in the supplied facts); consulting and training are priced per day by XWiki SAS	Services are not priced in the supplied facts; ask any implementation partner for a fixed scope covering install, SSO, migration and handover

Moving content from Wiki.js to XWiki or the reverse

This sequence moves pages, structure, permissions, sign-in and attachments from one wiki to the other with a documented check at each stage, so the destination can be trusted before users are cut over.

Export and inventory the source content
The migration owner, with a content lead, exports pages from the source wiki and builds an inventory: page count, folder or path hierarchy, attachment count and size, page owners, and any pages that depend on Wiki.js-specific features such as custom HTML or plugins. For a Wiki.js 2.x source, confirm how your instance stores content (database or Git storage module) so you know which export path applies. The step is done when every page has a row in the inventory with its location, owner and status, and the team has agreed which content is in scope to move. Content marked for retirement is recorded and excluded rather than silently dropped.
Map Markdown pages to XWiki structure
The information architect maps each Wiki.js path to an XWiki space and page hierarchy, deciding which folders become spaces, which become parent pages, and where Markdown syntax needs conversion into XWiki's own markup. Because XWiki pages are structured and carry their own version history, decide up front whether imported pages start with a fresh history or with a single imported revision. Confirm with the vendor or your own tests how links, images and internal references convert. The step closes with a written mapping document, reviewed by the content owners, that lists each source path and its target location.
Import a pilot space and test conversion
The platform engineer loads one representative space into a non-production XWiki instance, using the mapping from the previous step. The team reviews rendering, tables, code blocks, embedded images and internal links on a sample of pages, comparing each with the source. Record every conversion defect and decide whether to fix it in the mapping, in a script or by manual rework. The pilot is complete when the reviewers have signed off the sample and the defect log has an owner for each open item. Only then proceed to the full import, so that conversion problems are found on a small set first.
Rebuild permission models at each level
The wiki administrator recreates access rules at wiki, space, page and hierarchy levels in XWiki, since rights granted in Wiki.js do not transfer as a model. Start from the source access list, group users by role, and apply view, comment, edit and delete rights at the highest level that matches the policy, using page-level exceptions only where needed. A security reviewer checks a sample of restricted pages with test accounts from each group. The step closes when the access matrix is documented and every test account sees exactly the content its role allows, with the results saved as evidence.
Reconnect single sign-on and groups
The identity engineer configures sign-in on the destination wiki against the same identity source, whether that is an OpenID Connect provider, SAML 2.0, LDAP or Active Directory, and confirms how groups from the directory map to XWiki groups used by the access matrix. Wiki.js offers these modules along with TOTP two-factor authentication, so check which second-factor controls must be carried over. Confirm the mapping for XWiki-specific connectors with the vendor or your own tests before relying on them. The step is done when test users from each group can sign in through the new path, are denied where they should be, and the team has recorded the configuration in the change log.
Validate attachments, links and search
The content lead runs a reconciliation between the inventory and the destination: every page is present, attachment counts and file sizes match, and a sample of attachments opens correctly. Check internal links and external links on the imported pages, and confirm that search returns results for known phrases. Note that a Confluence Migrator Pro scope covers pages, users, groups, permissions and attachments, but not attachment history, so if you are moving from Confluence instead, record that limit in the inventory. The step closes with a reconciliation report showing zero unexplained gaps, and each exception has a named owner and a decision.
Cut over and retire the source
The project owner announces a freeze date, runs a final incremental export and import, then points users, bookmarks and integrations to the new wiki. Keep the source in read-only mode for a period agreed by the team, so that late corrections can be checked against it. Confirm with the vendor or your own runbook how long backups of the source must be retained under your policy. The step is complete when the freeze has been lifted on the new wiki, users have confirmed access, the source is archived with a recorded backup, and the migration report is filed with the change record.

Where XWiki and Wiki.js implementation projects usually run long

Most of the schedule risk in an XWiki or Wiki.js project sits in decisions made before the first page is migrated. On XWiki, the permission model is the largest one. Rights can be granted at wiki, page or hierarchy level, so a Confluence-style space structure has to be translated into groups, rights and inheritance rules that a security team will sign off on. Plan a workshop with content owners and the security team to write the rights matrix, then test it with real test accounts for each role before any bulk import. Ask the vendor or the XWiki documentation to confirm exactly how inherited rights interact with page-level overrides in the version you choose.

Single sign-on and group mapping take longer than most teams expect. XWiki's OIDC support is delivered through the community extension in xwiki-contrib/oidc, so the extension version, its configuration and the mapping from identity provider groups to XWiki groups need their own test cycle. Wiki.js offers a wider set of authentication modules, including LDAP and Active Directory, Keycloak OpenID Connect and SAML 2.0, with TOTP two-factor authentication. Each one still needs claim mapping, a decision on who may self-register, and a test of what happens when a user leaves the directory. Extension selection and testing add more time on the XWiki side, because each extension must be checked against the chosen platform release line.

Content restructuring is where migrations overrun. Confluence spaces rarely map cleanly onto XWiki's hierarchy or onto Wiki.js's flat page tree, and attachment history may not carry over in every tool. For an air-gapped Wiki.js deployment, plan the sideloading step explicitly: the requirements documentation says sideloading supports environments without internet access, so the team must build a repeatable package process and test the offline install on the target network. DeployOpen plans and delivers this work under a fixed scope agreed in writing before work starts, and the timeline follows from that written scope rather than from a published figure. Ask for a scope that lists the number of spaces, page volume, extensions, identity sources and the migration method, because those inputs drive the quote.

Questions buyers ask before choosing XWiki or Wiki.js

Which costs more to run, XWiki or Wiki.js?

Neither platform's software carries a license fee for the free edition, so the difference comes from people, infrastructure and any paid support. XWiki Standard is free open source under LGPL-2.1-or-later, and its Java stack runs on Tomcat with a MySQL, PostgreSQL or MariaDB database. Wiki.js 2.x is AGPL-3.0 and runs on Node.js with a minimum of 1 GB of RAM on Linux. Cost drivers include the number of users, how much customization you need, whether you buy XWiki SAS support or Pro applications, and how much your team already knows Java or Node.js. Ask any vendor or partner for a written scope that separates one-time setup from recurring upgrades, backups and support.

How long does it take to migrate from Confluence to XWiki?

The duration depends on content volume, permission complexity and how much history you need to keep, and no supplied fact gives a general timeline. XWiki SAS offers Confluence Migrator Pro, which moves spaces, pages, users, groups, permissions, attachments and metadata, and keeps page history but not attachment history. Its listed price starts at 2000 EUR, and its trial is limited to 30 pages per migration, which lets you test mappings before committing. Wiki.js has no equivalent product in the supplied facts, so a move there would likely be a manual or scripted export. Confirm the migration path, the attachment handling and the permission mapping in writing before work starts.

What does running XWiki or Wiki.js need from the internal team?

XWiki needs people who can operate a Java application server, a relational database and the XWiki upgrade process, and it offers stable, intermediate LTS and LTS lines to plan around. Wiki.js needs Node.js operations skills, a dedicated domain or subdomain (it cannot run under a subfolder), and a PostgreSQL instance that uses the pg_trgm extension for its search module. Both need backups, TLS and an identity provider connection. Teams that already run Java or Node.js services will carry less new load. Ask the implementer which tasks they own after go-live, such as upgrades, backups and patching, and which remain with your staff.

Can our team install XWiki or Wiki.js without outside help?

A technical team can install either one from its documentation, but the cost of getting permissions, SSO and backups right is where most unplanned effort appears. XWiki publishes official Docker images for MySQL, PostgreSQL and MariaDB on amd64 and arm64v8, maintained by the XWiki Core Dev Team, which shortens a basic container deployment. Wiki.js runs on Linux, macOS, Windows, Docker and Kubernetes and supports sideloading for air-gapped networks. Self-installing is realistic for a pilot, while a production rollout with SSO, hardening and migration usually benefits from a fixed-scope plan. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and it works from a written scope.

Is Wiki.js 3.0 ready for production use?

No. The main requarks/wiki repository holds Wiki.js 3.0, and its README marks it as beta and not for production use. The stable line is the 2.x series in the requarks/wiki-v2 repository, where v2.5.316 was published on October 2, 2026. Choosing Wiki.js today therefore means choosing 2.x, and you should plan an upgrade path before 3.0 is declared stable. Confirm the release status with the maintainers at the time of your decision, and check whether the 2.x line will receive fixes for the period you need. This maintenance risk is a central reason some teams weigh XWiki's parallel release branches more heavily.

Which SSO features need XWiki Pro, and which are free?

XWiki Standard is the free open source version, and the supplied facts do not list a free SSO application in the same way. XWiki Pro lists Active Directory and Azure Active Directory SSO applications as part of its bundle, along with File Manager, Forum, Polls, Calendar, Ideas, Meeting, Diagram, Pro Macros and connectors for Google Apps, Office365 and OnlyOffice. Wiki.js 2.x lists authentication modules for Azure AD, GitHub, Google, Keycloak OpenID Connect, LDAP and Active Directory, generic OpenID and OAuth2, Okta and SAML 2.0, with TOTP two-factor authentication, without a paid tier in the supplied facts. Before you decide, confirm with XWiki SAS which SSO protocols your identity provider needs and whether the open-source OIDC extension covers them.

What does XWiki Pro cost compared with support only?

XWiki Pro and support subscriptions are sold 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. XWiki SAS states that cloud and on-premises pricing is the same. Consulting is listed at 1200 EUR per day and requires a Business or Enterprise support plan, while training is listed at 1500 EUR per day. Your choice depends on user count, which Pro apps you need and how much hands-on help you want from the vendor. Ask for a quote that lists each tier, the user cap, the included apps and the support hours, and compare it against the internal time you would otherwise spend.

Which database should we choose for each wiki?

For XWiki, the official Docker images come in MySQL, PostgreSQL and MariaDB variants, so the choice follows your database standard and your operations team's skills. For Wiki.js 2.x, PostgreSQL is recommended and needs version 9.5 or later, while MySQL 8.0 or later, MariaDB, MS SQL and SQLite are also supported. Wiki.js's search module on PostgreSQL requires the pg_trgm extension, so confirm that your database administrators can enable it. Choose the engine you can back up, restore and patch within your existing change process, and test restore time on a copy of your real content volume.

How DeployOpen helps choose, implement or migrate your 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 Wiki.js, that means working from your content volume, permission model and identity setup to a written scope before any build starts.

How we scope

Review your current wiki content, page hierarchy, attachments and the permission rules you need to keep.
Confirm which database, identity provider and hosting model your team must run, including PostgreSQL or another supported option.
Agree deliverables, timelines and responsibilities in writing, as most engagements are fixed-scope.

How we build

Deploy the chosen wiki in your cloud account, data center or air-gapped network, with the database and reverse proxy you approve.
Configure single sign-on, group mapping and page-level rights, then test them against sample access scenarios.
Run a pilot migration on a representative content set and review page history and link integrity before a full cutover.

How we hand over

Document the installation, configuration, backup and restore steps so your own staff can repeat them.
Deliver a record of the permission model, identity settings and content migration decisions for your audit file.
Walk your administrators through upgrade steps for the release line you chose, including any future branch changes.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
Review new releases of the chosen wiki and plan upgrades to your schedule rather than waiting for an incident.
Revisit the decision if your requirements change, such as a move to Pro-style apps or a different maintenance model.

XWiki vs Wiki.js