Self-hosted Confluence alternative for air-gapped networks

Which self-hosted wiki works on an air-gapped Confluence replacement

For a disconnected network, XWiki is the most complete open-source match, because it publishes official Docker images for MySQL, PostgreSQL and MariaDB, each running on Tomcat, plus packages you can mirror inside the enclave. BookStack and Wiki.js can also run offline, but you install them from files you carry in and sideload, so they suit smaller or simpler wikis. The timing matters: Confluence Data Center licenses expire and become read-only on March 28, 2029, and Confluence Cloud is not an option at all, because it is hosted by Atlassian and requires a connection to Atlassian's service. Any plan that depends on Confluence for a disconnected network has to move to a self-hosted wiki before then.

Start by building an offline artifact bundle. For XWiki, that means the image for the stable, LTS or intermediate LTS line you choose, the matching database image, and any extensions you need, all transferred through your approved media process. Confirm the exact tags with XWiki before you pull them, because the current versions change between releases. For BookStack, confirm its PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6 requirements, and note that it publishes no official Docker images, so you would need to package a community setup yourself. Wiki.js supports sideloading, but its stable line is the 2.x series, and you should confirm how its Node.js dependencies and plugins reach the enclave. The harder question is how updates and extensions arrive. Ask each vendor which extensions run offline, whether XWiki's paid Confluence Migrator Pro can be licensed for a disconnected install, and what your own change process will be for security patches. Schedule that process as a recurring cost, since someone must watch upstream releases, test them in a staging enclave and move them across the boundary.

What an air-gapped wiki must satisfy

A disconnected wiki has to run, install, update and authenticate without reaching the internet. The four requirements below connect the platform choice to the controls your assessors will ask about, and each one needs a check in your own environment before you commit to a target.

No runtime internet dependency

The wiki must start, render pages, search and serve attachments without calling external services such as CDNs, font hosts, telemetry endpoints or hosted SSO. Check every feature you plan to use, including diagram editors, embedded media and plugins, because some pull assets from remote hosts by default. Wiki.js documents sideloading of files for environments without internet access, which is a useful reference point for what a disconnected deployment needs. Test the instance behind a deny-by-default egress policy before go-live.

Reproducible install from verifiable media

Every component should be installed from media you can inspect and reproduce: container images or packages, the database, the application server and language runtimes. XWiki publishes official Docker images in MySQL, PostgreSQL and MariaDB variants, which lets you mirror a known tag into an internal registry. Record checksums or signatures at import, keep the bill of materials with the change record, and confirm with the vendor how each artifact is signed before it crosses the air gap.

Controlled path for updates and extensions

Updates and extensions arrive by transfer, not by live pull, so you need a defined intake: review the release notes, test in a staging enclave, then promote. XWiki offers stable, LTS and intermediate LTS lines, and choosing an LTS line keeps the number of intake cycles lower. For BookStack and Wiki.js, confirm which plugins, themes and storage modules you need and whether they are sideloaded as reviewed source. Note that paid XWiki extensions such as the Confluence migrator arrive under a commercial license, which your procurement process must cover.

Identity and MFA with the internal directory

Sign-in should use the directory your organization already runs, with MFA enforced for every role that can edit or administer content. BookStack supports OIDC, SAML2 and LDAP sign-in and has built-in multi-factor authentication that can be enforced per role, without a paid edition. Wiki.js offers LDAP and Active Directory, SAML 2.0 and Keycloak OpenID Connect modules, plus TOTP. Confirm that your identity provider is reachable inside the enclave and that account lockout, group mapping and deprovisioning work as your access policy requires.

How XWiki, BookStack and Wiki.js compare offline

This table compares the three self-hosted wikis on license, offline install method, runtime and database, sign-in options and the main trade-off for disconnected use. Read the rows as the checklist to confirm with each vendor before you commit to a platform for an air-gapped network. Docs from La Suite and Docmost sit outside this comparison unless your requirements change, and Outline's Business Source License is not open source.

Criterion	XWiki	BookStack	Wiki.js
License	LGPL-2.1 or later for the platform	MIT	AGPL-3.0 for the stable 2.x line
Offline install method	Official Docker images for offline registries, plus packaged installs; confirm image mirroring in your environment	Official installation scripts for Ubuntu 22.04, 24.04 and 26.04; no official Docker images, only community setups	Runs on Node.js with sideloading of files for environments without internet access
Runtime and database	Tomcat with MySQL, PostgreSQL or MariaDB image variants, on amd64 and arm64v8	PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later	Node.js with PostgreSQL 9.5 or later recommended; MySQL, MariaDB, MS SQL and SQLite also supported
Release lines for patching	Stable, LTS and intermediate LTS lines, so you can choose a slower update cadence	Single release line; plan your own patch intake from the GitHub releases	Stable 2.x line; the 3.0 repository is beta and not for production use
Sign-in options	Extension-based SSO; confirm which authenticators your edition covers	OIDC, SAML2 and LDAP with enforced MFA by role	Azure AD, Keycloak, LDAP and Active Directory, generic OIDC and OAuth2, Okta, SAML 2.0 and TOTP
Extensions and updates offline	Extensions and Pro applications need an offline transfer path; confirm licensing for paid add-ons	Updates and plugins are applied from packages you stage internally	Modules are configured per instance; sideloaded files must be kept current by your team
Main trade-off	Broadest feature set and Confluence migration path, but the heaviest runtime to operate	Simple to install on a single server, but no official container path for image-based pipelines	Lightest footprint with a dedicated domain requirement, but a Markdown model without Confluence macros

Choosing an offline install path by platform

XWiki has the most established offline story of the three because it ships official Docker images and is also available as packages. The official images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. The current tags supplied for research were 18.8.0 for the stable line, 17.10.14 for LTS and 18.4.7 for the intermediate LTS, so the team must pick a line before mirroring anything. In a disconnected network, the images, the chosen database image and any base images they depend on need to be copied into an internal registry, and the images must be pulled in a staging zone that has access to the public registry.

Images and tags: Mirror the exact XWiki tag and digest you choose, plus the matching database image, into an internal registry.
Database engine: Mirror the database image for your chosen engine, or use a database service already approved inside the network.
Extensions: Confirm which XWiki extensions you need and download their packages in the staging zone, because the running wiki will not fetch them on its own.
Upgrade path: Plan to mirror each new tag and its dependencies, not only the one you install today.
Support boundary: Confirm with XWiki SAS, the company behind XWiki, whether any support or migration work it offers covers your offline layout.

Ask your platform team to confirm that the internal registry can serve the exact tags you approve, and that image signatures are verified before deployment.

How to deploy and update an offline wiki

This sequence produces a wiki running inside the air-gapped enclave, built from images and packages verified outside it, with a repeatable transfer cycle for every later update. Each step ends with a check that tells the team whether it can move on.

Build a staging environment outside the enclave
The platform or security team builds a connected staging host that matches the target enclave: the same operating system family, container runtime or PHP and web server versions, and the same database engine. Staging is where every download, test install and integrity check happens, so nothing reaches the enclave untested. The step is done when a staging instance of the chosen wiki starts, serves a page and passes a basic login test using the same database engine planned for production.
Pull and verify images or packages
Staging pulls the chosen release artifacts: for XWiki, the official Docker image tag for the line you have selected, such as 18.4.7 for the intermediate LTS or 17.10.14 for LTS, in the MySQL, PostgreSQL or MariaDB variant you need. For BookStack, pull the 26.09.1 release archive or a community container image pinned to that release. Record each digest or checksum, verify it against the publisher's published values, and keep the original files. The step is done when a manifest lists every artifact, its version, its checksum and the date it was verified.
Transfer artifacts through the approved media process
Your security team moves the verified bundle into the enclave through the media process your policy defines, such as a controlled transfer station, scanning of removable media or a data diode. Include the manifest and checksums in the same transfer so the receiving team can recheck them. Confirm the enclave's malware scanning and approval steps with your own security owner, because the requirements differ between organizations. The step is done when the receiving side has confirmed each checksum against the manifest and logged the transfer.
Install the stack inside the enclave
The operations team installs the database first, then the wiki. Choose PostgreSQL, MySQL or MariaDB to match the stack the wiki requires: BookStack needs PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and Wiki.js 2.x recommends PostgreSQL. Load the transferred images or packages without any outbound pull, set the database credentials and file storage paths, and confirm backups run to a location inside the enclave. The step is done when the wiki starts, creates its database schema and serves its first page to an internal user.
Configure internal identity and access
Connect the wiki to the enclave's directory service and sign-in provider, such as LDAP, Active Directory, or an internal OpenID Connect or SAML identity provider, rather than local accounts. Test that group membership maps to the intended roles and that multi-factor authentication works in the enclave. Confirm which sign-in modules your chosen edition supports, because some features are paid editions in certain products. The step is done when a test user from each role can sign in and sees only the spaces or books they should, and the administrator account is protected.
Record version pins and review release notes
Record the exact image tags, package versions and checksums that run in production, for example XWiki 18.4.7 or BookStack 26.09.1, in your change register and configuration repository. Review each vendor's release notes and security advisories before accepting an update, and confirm with each vendor how often it publishes security fixes and which lines receive them. Extensions and plugins are pinned the same way. The step is done when every running component has a recorded version, a named owner and a documented review point.
Repeat the transfer cycle for each security update
For each update, staging repeats the pull, verification and manifest steps against the newer release, then the same transfer and install process runs inside the enclave. Test the upgrade on a copy of production data first, take a backup before the change, and keep the previous version available for rollback. Ask your vendor or support partner what migration notes apply between versions. The step is done when the updated instance passes the same login and page checks, the backup is confirmed restorable and the change record is closed.

How extensions and updates reach a disconnected wiki

On a disconnected network, an XWiki instance receives extensions and updates only through your transfer process, so the first thing to build is a mirror of every package and extension the wiki depends on. Start with the official XWiki Docker images in the variant you chose (MySQL, PostgreSQL or MariaDB, each on Tomcat), then add the platform packages, any XWiki extensions you have approved, and the Java and database dependencies they pull in. Record the exact version of each item, because the stable, LTS and intermediate LTS lines move on different schedules. Confirm with your vendor or your own build pipeline how each artifact is verified against its published checksum before it crosses the boundary.

Check licensing before anything paid enters the enclave. The XWiki platform is LGPL-2.1-or-later, but Confluence Migrator Pro is a paid extension sold by XWiki SAS, priced from 2000 EUR according to the XWiki Store, and it has its own license terms, activation and support entitlement. Ask XWiki SAS, in writing, whether the license is node-locked, whether it needs a licence server that can reach the internet, and whether an offline activation or a renewal file can be transferred. Also ask how updates to the paid extension are delivered, since a stale version may stop matching the platform release you run.

The migrator is built on XWiki's open-source Confluence XML filter stream, which is a separate component with its own code and its own review path. Treat it as a dependency in its own right: pin its version, include it in your software bill of materials, and have your security team review the change history before each import. Wiki.js has a different pattern. Its sideloading feature lets you install content without internet access, and its Git storage module can synchronize pages in both directions, so both depend on what your enclave allows in: a Git server inside the boundary, a one-way import, or no storage sync at all. Decide that first, then document it in the transfer procedure.

Risks that offline operation adds

A disconnected wiki cannot lean on a vendor's update feed, hosted backups or cloud integrations, so the team takes on those duties itself. The four risks below share one root cause: the install is only as current, verifiable and recoverable as the procedures your staff run and document.

Delayed security patches

An offline XWiki, BookStack or Wiki.js instance receives fixes only when someone carries them across the air gap. Each release (for example, XWiki's stable line at 18.8.0 or LTS line at 17.10.14) needs a documented intake step: who downloads it, who reviews the changelog, and who approves the transfer into the enclosure. Keep a signed transfer log that records file hashes and approvals for every package moved in. Ask your vendor or implementation partner which releases carry security fixes and how long your window for applying them is.

Unverified third-party packages

Extensions, plugins, Docker images and PHP or Node.js dependencies all arrive as files you must trust. Verify checksums or signatures against the publisher's release page before import, and mirror only the versions you have tested. Confirm the license of each component, since XWiki is LGPL-2.1 and its core is separate from paid applications such as Confluence Migrator Pro. Record every artifact in an inventory so you can answer what runs in the enclosure and where it came from.

Lost cloud integrations

Single sign-on, mail relays, Git sync and cloud storage connectors often depend on services that a disconnected network cannot reach. Wiki.js, for example, supports storage modules such as Git, AWS S3 and DigitalOcean Spaces, and authentication through providers like Azure AD or Okta. Inventory each integration before go-live and decide whether an internal replacement exists, such as LDAP, an on-premises identity provider or a local Git server. Test sign-in and sync with the enclave's real network rules, not with a lab that has internet access.

Single-person knowledge of the install

When one administrator understands the database layout, reverse proxy, backup schedule and upgrade steps, the wiki becomes fragile during leave, turnover or an incident. Require a written rebuild procedure that a second engineer can follow from bare hardware, and run a tested restore on a schedule your team agrees. Store runbooks inside the enclave with the backups they describe. Ask any implementation partner for documented handover, and confirm that the restore test covers attachments as well as the database.

Questions buyers ask about offline Confluence alternatives

What does an offline Confluence alternative cost to install and run?

The software itself is free for XWiki, BookStack, Wiki.js and Docmost under their open-source licenses, so the cost sits in the work around it. That work includes planning, building the offline package set, hardening, database and backup setup, identity integration and staff time to administer the wiki. Some costs are one-time, such as the initial build and content migration, and others recur, such as patching, backups and staff time. XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day (xwiki.com pricing). If you need paid Confluence import, XWiki SAS prices its Confluence Migrator Pro from 2000 EUR (XWiki Store). Ask any provider for a quote that separates these components and states which are one-time and which recur.

How long does an air-gapped wiki deployment take?

The duration depends on the scope, not on the license, and no supplied source gives a fixed timeline for this work. The main drivers are how many packages and images must be carried across the air gap, whether you need LDAP or SAML sign-in, how much content must be migrated from Confluence, and how quickly your security team can review the transfer process. Confluence XML export support ends on December 1, 2026, which may shape your plan (Atlassian support knowledge base). Ask for a timeline in the written scope with milestones for transfer, install, identity integration, content import and acceptance testing.

What does the internal team need to run an offline wiki?

Your team needs Linux administration, database administration, web server or container operation, and an owner for identity and backups. The exact stack depends on the tool. BookStack requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later, and its official installation scripts cover Ubuntu 26.04, 24.04 and 22.04 (BookStack installation docs). Wiki.js 2.x recommends PostgreSQL 9.5 or later and needs a dedicated domain or subdomain (Wiki.js requirements documentation). XWiki publishes official Docker images for MySQL, PostgreSQL and MariaDB on Tomcat (Docker official image documentation for XWiki). Someone must also own the process for moving each update package across the air gap and testing it first.

Can our own engineers install and maintain an air-gapped wiki without outside help?

Yes, many teams do this with in-house staff, provided they have the Linux, database and security skills listed above and time to test updates. Outside help is most useful for scoping the transfer process, hardening the install, planning content migration and training administrators. Confirm early whether your staff can handle a packaged install, backup restore testing and a full offline update cycle. A fixed-scope engagement can cover specific deliverables, such as the offline install, documentation and admin handover, and DeployOpen offers ongoing support as a retainer for upgrades and continuous testing.

Do we need XWiki's paid support to run XWiki air-gapped?

No. XWiki Standard is the free open-source version, and its LGPL-2.1 license lets you run it in your own network without a subscription (xwiki-platform LICENSE file). Paid support from XWiki SAS is optional. It covers on-premises professional support, installation and configuration help, and training, and its support plans start with the Business tier for consulting access (xwiki.com pricing). Weigh that cost against your own staff capacity. Paid XWiki Pro applications are also optional, and any extension you add must be tested and transferred into the offline environment like any other package.

How do we request an accurate quote from a provider?

Send the provider a written scope before asking for a price, because a quote follows from the scope. Include the target wiki, the number of users, the identity sources to connect, the amount of Confluence content to migrate and whether attachments and page history matter, the transfer method for packages and images, the security and audit evidence you need, the hosting platform and the support period you expect. Ask the provider to list deliverables, acceptance criteria and timelines in writing, and to split one-time work from recurring support. DeployOpen plans and delivers most engagements on a fixed scope agreed in writing before work starts, and it does not publish a price list.

Records to keep for security and compliance reviews

An assessor or regulator reviewing an air-gapped wiki will ask for proof of what is running, how it got there and who can change it. Start with a software inventory that lists every component by exact version: the XWiki image tag and variant (MySQL, PostgreSQL or MariaDB), the Tomcat and database versions, any extension packages, and the operating system. Record the release you chose and the date you chose it, so the inventory can be compared against the vendor's published release notes at any later point. Confirm with the XWiki project which tags it treats as stable, LTS or intermediate LTS, because your choice affects how long you will be expected to stay on that line.

Keep a transfer and verification log for every package that crosses the air gap. For each transfer, record the source, the person who approved it, the file names, the checksums or signatures you verified against the publisher's values, and the import date. The same log should cover Docker images, Wiki.js sideloaded files and BookStack or XWiki extensions. Change records then tie each update to a ticket, a test result and a rollback plan. Assessors usually sample these records, so a log that is complete for every item is more useful than a detailed log for a few.

Finally, collect evidence for access control and MFA and for backup and restore tests. Export the role and group configuration, the SSO or directory mapping, and the MFA enforcement settings, and keep dated screenshots or configuration files as proof. For BookStack, that includes per-role MFA enforcement, and for Wiki.js, the TOTP setting and the chosen authentication module. Run a restore into a separate environment on a schedule, and keep the result. DeployOpen can prepare these systems, controls and evidence, but it does not issue audit reports or certifications. Independent auditors and certification bodies make that determination, so ask them early which artifacts they expect.

How DeployOpen deploys an air-gapped wiki

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source wikis inside the client's own infrastructure, including air-gapped networks. For an air-gapped Confluence replacement, the work centers on getting the platform, its extensions and its updates onto a disconnected network in a controlled, repeatable way.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names the candidate platforms, such as XWiki, BookStack or Wiki.js, and the reason each one fits the network.
Scope covers the content to migrate, the identity source, the database variant and which extensions the wiki must run offline.

How we build

Build the wiki from the official XWiki Docker images or packages, then mirror every image and dependency into the enclosed network.
Set up a sideloading process for BookStack or Wiki.js so plugins, assets and updates pass through a documented transfer step.
Test sign-in, backups, search and restores inside the disconnected environment before the wiki carries real content.

How we hand over

Deliver runbooks for installing, patching and rolling back the wiki, including the offline update and extension transfer procedure.
Document the backup schedule, restore tests and the evidence that supports internal control reviews or compliance assessments.
Hand over administrator training for the client's own staff so they can operate the wiki without outside access.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover scheduled offline update bundles, security review of new releases and periodic restore tests.
Ask any provider to confirm how they receive patches into a disconnected network and who validates them before deployment.