XWiki

Last reviewed Sep 13, 2026 · 897 words

Calling XWiki a wiki undersells it and misleads the people who should not install it. It is a Java platform for building structured, scriptable, form-driven applications that store their data inside wiki pages, with a wiki on top. If what you want is a place to write documentation that your household or team will read, that is BookStack, and you will be done by lunch. If what you want is Confluence with the macros, the page properties, the custom forms and the ability to build a small asset register or CRM inside your knowledge base, XWiki is the only open-source project that does all of it, and the 2 GB of RAM and the Tomcat tuning are the entry fee.

An application platform wearing a wiki's clothes

The distinguishing mechanism is that any page can carry an XClass, essentially a schema, and any other page can hold an object of that class. Define a "Server" class with hostname, owner and rack fields, and every server gets its own page with those fields rendered as a form, plus a live table querying all of them. The App Within Minutes wizard builds this without code; Velocity or Groovy scripting inside pages extends it without limit. Structured content is the reason enterprises pick XWiki over MediaWiki, and it is why the listing's "powerful structured content" pro is the whole story rather than one bullet.

The Extension Manager pulls in hundreds of add-ons: diagrams, a Kanban board, LDAP and OIDC authentication, PDF export, a meeting notes app. Many are maintained by XWiki SAS, the company that sells hosting and support, which is both the project's strength and where the paid-versus-free line lives.

2 GB is the floor, not the recommendation

XWiki is a Java web application, and the JVM heap is the number you tune. The listing's 2,048 MB minimum gets you a working single-user install; a wiki with a few dozen active users and a few thousand pages wants a 4 GB heap and a host with 6 GB or more once the database is counted. Start-up takes a minute or two while the platform loads its core extensions, and the first search index build on a large import can peg a CPU for a while. None of this is unreasonable for what it does, but it is the opposite end of the scale from a Go binary, and anyone coming from the lighter wiki category should size accordingly.

Install: Tomcat plus a real database, never the demo one

The official Docker images are tagged by database and servlet container, for example the LTS build on Tomcat with PostgreSQL, and the compose file pairs the XWiki container with a PostgreSQL or MariaDB container. The web app listens on port 8080; put a reverse proxy in front and set the wiki's home URL in administration once TLS is in place, because absolute links in notifications and exports use it.

The standalone download ships with an embedded HSQLDB database for evaluation. Do not run anything you care about on it. Migrating from HSQLDB to a real database later is an export-and-import job, and people lose history doing it. Start on PostgreSQL, snapshot the database and the permanent data directory together, and you have a restorable backup.

After first login, the distribution wizard installs a default flavour and asks about the main wiki's extensions. Accept the standard flavour unless you know why not; it is the set the documentation assumes.

The Confluence escape hatch

XWiki's headline use is replacing Confluence, and there is a Confluence migration extension that reads a space export and recreates pages, attachments and a good share of macros. Macros that have no XWiki equivalent land as visible placeholders you clean up by hand. For a wiki of a few hundred pages this is a weekend; for thousands of pages with heavy macro use it is a project, and XWiki SAS sells the pro version of the migrator for exactly that reason. The broader Confluence alternatives page covers the lighter options if migration fidelity matters less than a fresh start.

Administration is a part-time job

Complex to administer is a fair con. Rights are per wiki, per space, per page, per group, and they inherit, which is powerful and easy to get wrong. Upgrades between LTS lines require reading the release notes because the distribution wizard will offer to migrate extensions and sometimes an extension has no compatible version yet. Java memory settings, database vacuuming, and the Solr search index all need occasional attention. A single person running XWiki for a team should expect an hour or two a month of care, which is fine for an organisation and a lot for a homelab.

What I'd do

If you need forms, structured data and scripting inside your documentation, or you are moving a real Confluence instance, run the LTS XWiki image on Tomcat with PostgreSQL, a 4 GB heap, and Caddy in front, and commit to reading release notes at each upgrade. If you need a wiki for people to read and edit, run BookStack or Wiki.js and keep the 2 GB for something else. XWiki is the right answer to a specific question, and most self-hosters are not asking it.