When XWiki high availability is worth the extra moving parts
High availability for XWiki means removing single points of failure in the database, attachment storage, search index and reverse proxy, so that losing one component does not take the wiki offline. It is not something you get automatically by installing XWiki. A default deployment runs one application server against one database, with attachments on local disk and a search index that lives with the application data, and each of those is a place where a single failure stops access. Before you pay for redundancy, decide which of those failures your teams can actually tolerate. For many knowledge bases, a well-sized single instance with tested backups and a fast, rehearsed restore is the better fit. People rely on the wiki for daily work, so an outage matters, but the question is how long it lasts and how much content could be lost. A single server with regular database dumps, attachment backups and a documented restore procedure, tested on a schedule, often meets a recovery objective that teams can live with. Ask your stakeholders how long the wiki can be unavailable during a working day and how much recent editing they could re-enter. Those two answers usually decide more than the architecture diagram does. Clustering XWiki nodes adds real complexity. Nodes need shared state, which means a database and storage layer that every node reads and writes consistently. Sessions must either be shared or made sticky at the proxy, so a user does not lose a login when a node fails. Upgrades become coordinated changes across nodes, with extensions and the schema moving together. Each of these adds build work, monitoring and staff skill requirements that continue after go-live. Treat the extra moving parts as an ongoing cost, not a one-time setup. The failure modes that matter most for a wiki are fairly specific. Database loss stops everything and is the first thing to protect with replication or reliable point-in-time backups. Attachment storage loss can go unnoticed for a while because pages still render, so check that attachment directories or object storage are backed up separately from the database. A stuck Tomcat process is common and usually recovers by restart, which a second node or a health-checked proxy can cover. A bad extension release can break rendering or permissions across the whole wiki at once, and a second node running the same bad version gives you no protection, so test extensions in staging before rolling them out. Your database choice shapes your replication options. The official XWiki Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, so start by confirming which database your team already operates and can monitor. Then confirm with your DBA and with XWiki documentation which replication topology that engine supports for your version, and how failover is handled for the application connection. Make that decision before you size the cluster, because it determines whether HA is practical at all.
Which XWiki components need redundancy and how they connect
A XWiki high availability design depends on six connected components: application nodes, the relational database, attachment storage, the search index, the reverse proxy, and the shared time and certificate sources. A failure in one often surfaces in another, such as a database failover that leaves attachments unreachable. Map what each component holds and how it fails before deciding which ones to duplicate.
Application nodes on Tomcat
The XWiki web application runs inside a Tomcat servlet container, and the official Docker images come in MySQL, PostgreSQL and MariaDB variants. Each node holds its own runtime configuration, extension files and local caches. Before you plan more than one node, confirm in the XWiki documentation for your release line which state is local to each node, such as sessions, caches and installed extensions, and what configuration must match across nodes. Settle that answer before you choose a node count.
Relational database
XWiki keeps its content and metadata in a relational database, supplied as MySQL, PostgreSQL or MariaDB. If this database is lost, every node loses access to wiki content, which makes it the first component most teams replicate and back up. Confirm in the XWiki documentation for your release line which database versions are supported, and whether the application can point to a writable primary, read replicas or a failover address. Test a full restore before go-live.
Attachment and file storage
Attachments and uploaded files are stored separately from page text, so restoring the database alone may not bring them back. Confirm where your release line keeps attachment data, whether in the database, a file system path or another store, and whether every node can read the same location at the same time. Decide how that store is replicated and backed up, and include it in restore tests so pages and their files return together.
Search index
The search index is derived data built from wiki content, so it can be rebuilt, but a rebuild on a large wiki takes time. Confirm in the XWiki documentation how the index is stored, whether each node keeps its own copy, and how search behaves when a node is replaced or the index is damaged. Plan for search to be stale or incomplete during recovery, and tell users what to expect while the index catches up.
Reverse proxy and TLS termination
The reverse proxy accepts user traffic, terminates TLS and forwards requests to the XWiki nodes. It becomes a single point of failure unless you run more than one proxy behind a virtual address or load balancer. Confirm in the XWiki documentation which forwarded headers, such as the original host and scheme, the application expects, and how user sessions behave when requests reach different nodes. Include certificate renewal for the proxy in the operations runbook.
Shared time and certificate sources
Nodes, the database, the proxy and any directory connections all depend on accurate clocks and valid certificates. Clock drift can cause token, session or certificate validation failures that look like application faults. Confirm which internal time source every component uses, which authority issues internal certificates, and how trust stores are updated on each node. Monitor certificate expiry dates so that a routine renewal does not interrupt access.
Choosing between one well-sized instance and clustered XWiki nodes
This table compares three ways to keep XWiki available: one well-sized instance with backups and a warm standby, several nodes behind a reverse proxy, and database replication with managed failover. Read each column against your user count, your staff for on-call and upgrades, and your recovery targets. The main takeaway is that clustering adds moving parts your team must operate, so choose the simplest option that meets your recovery requirements.
| Trade-off | Single well-sized instance | Multiple nodes behind a reverse proxy | Database replication with managed failover |
|---|---|---|---|
| When it fits | Moderate user counts, a tolerable restore window and a small operations group. | Higher availability needs for reads and sessions, and a team comfortable with proxy health checks and shared storage. | The database is the main availability risk and the team has database operations skills. |
| Upgrade coordination | One maintenance window covers application, servlet container and any schema changes. | All nodes must run one compatible version, so plan rolling steps and confirm version mixing rules. | Replication does not replace application upgrades; every node still needs the same XWiki version. |
| Sessions and caches | Sessions and caches stay local, so a restart signs users out and clears warm caches. | Session handling must be designed up front, including sticky sessions or shared sessions, per your release. | Failover usually drops active sessions and unsaved edits, so users must sign in again. |
| Search index ownership | One node owns the index, so backups and restores must include it or plan a rebuild. | Decide which node or service runs indexing so nodes do not compete for the same index. | Database replication does not carry the index, so confirm where it lives and how it rebuilds after failover. |
| On-call burden | Mostly host, disk and restore alerts, with failover run as a documented manual procedure. | Adds proxy, node and shared storage failure modes, and more alerts to triage at night. | Adds replication lag, failover and split-brain checks on top of application monitoring. |
| Backup scope | Database, attachments, extension files, configuration and the search index location. | Database, shared attachment storage and any shared configuration must be captured at the same point. | Replication is a copy, not a backup, so keep point-in-time database backups and file backups. |
| Confirm before choosing | Whether your release documents a warm standby approach and how long an index rebuild takes. | Official clustering guidance, supported shared storage and session handling for your exact version. | Which database variant and replication topology the official images and your database platform support. |
How to build XWiki high availability in sequence
This sequence takes a single XWiki instance to a clustered setup in which nodes, database, attachments and proxy each have a defined role and a tested recovery path. Each step closes with a check the team can run before moving on. The result is a runbook and evidence that the design behaves as intended under failure.
Pick the release line and database variant
Choose stable, LTS or intermediate LTS before any other work, because the release line sets your upgrade path and every later step depends on it. At the time of research, the official Docker image tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS, so confirm current tags with XWiki before you pin them. Select the MySQL, PostgreSQL or MariaDB variant at the same time, since the database choice shapes the replication options available to you. Done when the service owner has signed a decision record naming the release line, the exact image tag and the database variant.
Provision the database with replication
The database team builds the tier according to the option you chose, whether that is primary and replica replication or a failover pair in your own infrastructure. XWiki keeps page content, metadata and configuration in this database, so it is the first tier to protect. Confirm the replication mode, failover method and connection endpoint against the documentation for your chosen engine, and do not assume a setup works until you have tested it. Check: a test write on the primary appears on the replica, and the application user connects through the endpoint XWiki will use.
Place attachment storage on shared storage
Attachments must be readable and writable from every XWiki node, so place attachment storage on shared or replicated storage that all nodes mount. Confirm with the configuration documentation for your release how attachment storage is set, and whether any node-local path would cause files to go missing after a node change. Storage performance and capacity planning belong to your infrastructure team and should be sized before go-live. Check: a file uploaded through node A downloads from node B, and a file written through either node is still present after one node is stopped.
Deploy XWiki on Tomcat nodes
Deploy XWiki on each node from the official image, using the identical tag chosen in the first step and the database variant you selected. Tomcat runs inside the image, so the nodes must share the same database connection settings, attachment mount and configuration files. Keep these settings in version-controlled configuration and apply them identically to each host. Check: every node reports the same XWiki version in the administration area, and a page created on one node loads on the others.
Configure the reverse proxy routing
Place a reverse proxy in front of the nodes, configure health checks that remove unhealthy nodes from the pool, and set session routing as your chosen release requires. Confirm in the XWiki documentation for that line whether sticky sessions are needed for login and editing, because session behavior in a cluster depends on the release. Pass the original host and scheme headers through the proxy so generated links point to the correct address. Check: stopping one node removes it from the pool, and an editor in an active session keeps working without a forced login.
Move the search index deliberately
Decide where the search index lives before nodes run in parallel, because an index written independently on each node can drift out of step. Confirm in the search documentation for your release whether the index is node-local or can sit on shared storage, and what a reindex involves. Treat any location change as a planned change made in a maintenance window, and record the new path in the runbook. Check: after reindexing, a page created on node A appears in search results from node B, and the index location is documented.
Back up database, attachments and configuration
Set up backups for the database, attachment storage and configuration files, and treat the three as one restore set. The database and attachments should be captured at a consistent point, so agree the schedule and retention with the service owner and confirm the backup method with your database and storage vendors. Store copies outside the failure domain of the cluster, so a single site or storage incident cannot remove both the live data and its backups. Check: restore the full set into an isolated environment and confirm that a sample page, its attachment and its configuration all load correctly.
Run a controlled failover test
Run a controlled failover test from a written script: stop the primary database, then stop one XWiki node, and confirm that the database and proxy promote and route traffic as designed. Record what you observe, including failed requests, any lost writes and each manual step, and feed those findings back into the runbook. Run the test with the service owner present and a rollback plan ready before you begin. Check: the test log shows the promoted database accepts writes, surviving nodes serve reads and edits, and the team can restore the original topology using the runbook alone.
How XWiki high availability differs by deployment model
A single XWiki node with a warm standby keeps one active application server and one database, plus a second host prepared with the same XWiki version, extensions and configuration but not serving users. Failover is a deliberate step that starts the standby and moves the entry point to it. The application tier stays simple, so most of the design effort goes into database replication, attachment storage and the failover procedure.
- Components that change: the standby needs the same XWiki image tag, database variant and servlet configuration, plus a replicated or restored copy of the database and attachment data.
- What the operator owns: the failover runbook, the decision to fail over, the DNS or proxy switch and regular rehearsals of the switch.
- Network paths: confirm the routes and firewall rules between primary and standby database hosts, and how replication lag is measured and alerted.
- Data loss window: confirm with your replication and backup setup how far behind the standby can be at the moment of failure.
- Restore testing: confirm the standby can start from the most recent backup set without help from the person who built it.
Confirm the switch time, the data loss window and the people authorized to trigger failover before go-live.
Running several XWiki application nodes on virtual machines behind a reverse proxy spreads request load and lets you patch one node at a time. Every node must reach the same database and the same attachment storage, and the proxy decides which node serves each request. This model adds components to operate, so the design work moves from a single host to the traffic path between the proxy, the nodes and the data tier.
- Components that change: the reverse proxy, TLS termination, the application node pool and shared storage for attachments join the design.
- What the operator owns: proxy health checks, certificate lifecycle, the order of node patching and the configuration drift between nodes.
- Session behavior: confirm with XWiki documentation for your release whether several nodes against one database are supported, and what session handling the proxy needs.
- Cache and index consistency: confirm how search indexes and caches behave when a node is added, removed or restarted.
- Network paths: confirm that each node can reach the database, storage and mail services, and that the proxy can reach each node's health endpoint.
Confirm the supported topology for your chosen XWiki line and extensions before you commit to a node count.
Container platforms can run XWiki from the official Docker images, which come in MySQL, PostgreSQL and MariaDB variants, each on Tomcat, for amd64 and arm64v8. The images are maintained by the XWiki Core Dev Team. The design shifts from managing hosts to managing image provenance, persistent storage and the database connection, and the platform's own scheduling and failover behavior must be confirmed rather than assumed.
- Image provenance: pull from the official repository, pin tags, and record digests so every environment runs the same build.
- Storage class behavior: confirm how persistent volumes behave when a workload is rescheduled, whether the access mode suits your deployment, and whether attachment storage can be shared between replicas.
- Database placement: decide whether the database runs inside the platform or on a managed service, and who owns its backups.
- Secrets and configuration: confirm how database credentials and configuration files are injected, stored and rotated.
- Network paths: confirm ingress routing, the path from the application to the database, and any replication traffic between database nodes.
Confirm each of these behaviors in your own cluster with a failure test before relying on them in production.
In an air-gapped network, XWiki cannot reach public image registries, extension repositories or update services directly. Images, extension bundles and backups must cross a controlled transfer boundary, and high availability depends on what can be moved, verified and restored inside the enclave. The design changes from automatic retrieval to a planned, auditable transfer process.
- Image mirroring: bring the official images into an internal registry through an approved transfer, and verify digests on arrival.
- Backup transfer: database dumps and attachment archives cross the boundary on approved media, with integrity checks recorded at each step.
- Extension bundles: every extension and its dependencies must be mirrored internally, and their versions tracked against the XWiki release in use.
- License review: XWiki is licensed under the LGPL 2.1, and your legal team should confirm how that applies to internal redistribution of mirrored images.
- Network paths: confirm which replication and monitoring paths stay inside the enclave, and that no step depends on outbound access.
Confirm your offline update cadence and restore procedure with a test restore inside the enclave before you rely on the standby.
What drives the effort and cost of XWiki high availability
This table lists the factors that raise or lower the work of making XWiki resilient, with what to ask for in a written quote for each. Read it as a checklist for scoping your own estimate, since most drivers are set by your environment rather than by XWiki itself. Consulting from XWiki SAS is listed at 1200 EUR per day for Business or Enterprise support customers, so compare that rate with the time your own staff would spend.
| Driver | Effect on effort and cost | What to ask for in a quote |
|---|---|---|
| Concurrent users and editors | More users and simultaneous editors raise load testing, node sizing and the number of nodes needed, so the design and test effort grows with them. | Load test scope, target concurrency, and the node count and sizing assumptions behind the proposal. |
| Wiki and attachment data volume | Large attachment stores and page histories increase backup size, restore time and replication lag, which add design and recovery testing work. | Current and projected data size, attachment storage location, and how backup and restore timing will be tested. |
| Database platform and DBA skills | Choice between MySQL, PostgreSQL or MariaDB and the replication model changes setup complexity. Limited in-house DBA skills usually add vendor-supported or partner hours. | Named database engine and version, replication topology, failover method, and who operates the database after handover. |
| Number of environments | Each environment (test, staging, production) needs its own clustered build, data refresh and failover test, so effort rises with every added environment. | Which environments are in scope, whether production-like data refresh is included, and how configuration is kept consistent across them. |
| Installed extensions and upgrade retesting | Every extension that touches authentication, macros or storage must be checked for cluster compatibility and retested on each XWiki upgrade, so extension count drives recurring effort. | Inventory of extensions with their sources, a list of those needing cluster testing, and the retest scope per upgrade. |
| Network and data-center topology | Load balancers, reverse proxies, sticky sessions, multiple sites and cloud zones add routing, DNS and firewall design. Cross-site designs add latency and failover complexity. | Topology diagram, reverse proxy product, session handling approach, and whether disaster recovery across sites is included. |
| Recovery time and recovery point expectations | Shorter recovery time and recovery point targets require more automated failover, more frequent backups and more rehearsal, which increases both build and run costs. | Stated recovery time and recovery point objectives, backup frequency, and the restore test schedule the quote includes. |
| Compliance evidence needs | If an auditor expects documented failover tests, backup logs and access records, evidence collection and runbooks add effort. DeployOpen prepares evidence but does not issue audit reports or certifications. | Named control framework, list of evidence artifacts to produce, and confirmation that independent auditors or certification bodies remain responsible for their opinions. |
| Internal staff time versus XWiki SAS consulting | XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise support customers. Internal time is often higher in hours but already paid, so the comparison depends on skills and availability. | Day rate, estimated days by phase, what is excluded, and which support plan is required to access the rate. |
How to verify XWiki high availability before go-live
Before go-live, the team should prove that the XWiki high availability design works by running a fixed set of failure tests and recording what happened in each one. A diagram showing two application nodes and a replicated database is not evidence. The test plan should cover five scenarios: stopping one application node while users are active, failing over the database, restoring from a backup into a separate environment, losing the search index and rebuilding it, and recovering attachments. Each test needs an owner, a load profile, a start time, a recorded result and a rollback path, so the outcome can be reviewed by people who were not in the room.
Start with the application tier. Put a scripted, repeatable load on the reverse proxy, then stop one Tomcat node with XWiki running on it. Record how many requests fail, how long the proxy takes to route traffic away from the stopped node, and whether in-flight edits are lost. Repeat the test with the database primary stopped and a replica promoted, using the failover mechanism your database platform provides. Confirm that the wiki reconnects without a manual restart of every node, and that the team knows which steps are manual. The exact promotion commands depend on the database engine and replication design chosen, so confirm them with your DBA and the database vendor's documentation rather than assuming them.
The restore test deserves the most attention. A successful database dump restore is not proof that the wiki is recoverable. Restore the backup into a separate environment and check page history for several pages with long revision chains, confirm that attachments open and match their checksums, and confirm that the attachment versions your policy requires are present. Also check that the search index can be rebuilt from the restored content and that users and groups resolve correctly if they come from an external directory. Record the time taken for each restore step. That figure, measured on your own infrastructure, is the number to use when you set your recovery time objective.
Define acceptance criteria before running any test, and write them down. For failover, decide what users may see: a brief error on one request, a reload prompt, or nothing at all. Decide how sessions behave when a node fails: whether users stay logged in, and whether an unsaved edit can be recovered. Set the data loss tolerance in plain terms, such as how many minutes of edits the business accepts losing, and check the replication and backup settings against that number. Also verify that the wiki fails safely. Under a database outage or a corrupted index, users should see a clear error page, and pages should not be saved in a partial or broken state. Test this by interrupting writes during an edit and confirming the stored page matches the last complete save.
Finish by confirming the results with the people who will operate the platform. Ask for a written test report that lists each scenario, the observed result, the acceptance criterion it was measured against, and any open defects. Keep the failed tests in the report as well as the passed ones. Schedule the restore test again after every major XWiki upgrade and after any change to the database or proxy layer, because high availability settings that passed in March may not hold after a version change. If your organization needs independent assurance, ask your auditor or certification body which evidence they expect, since DeployOpen prepares this evidence but does not issue audit conclusions.
Securing database credentials, backups and proxy paths in an HA setup
A highly available XWiki deployment has more places where credentials, backups and network paths can be exposed than a single instance does. The cards below cover the controls an operations team can test on each node, in the proxy and in the storage network, and they call out the identity dependency that failover can quietly inherit.
Keep database and replication credentials out of config files
XWiki reads its database connection settings from its configuration, and every node in a cluster needs the same database account. Check that the password is supplied from a secrets store or an environment mechanism your platform team controls, not written into a file that is copied between nodes. Confirm that rotating the password is a documented, tested step that updates all nodes without a manual edit on each one.
Encrypt backups and limit who can restore them
Backups of the XWiki database and attachment storage contain page content, user data and permissions, so they need the same protection as the live system. Verify that backups are encrypted at rest with keys held separately from the backup store, and that the restore role is a named group distinct from the people who administer the wiki. Test a restore into an isolated environment and record who can start it.
Separate administrative access to each node
Each XWiki node, its servlet container and its operating system should have individual administrator accounts rather than a shared login used across the cluster. Check that node access is logged to a central place, that privileged sessions are time limited, and that removing an administrator from one node is a single documented step. This keeps a compromised node from becoming a route to every other node.
Encrypt traffic between the proxy and the nodes
A reverse proxy in front of several XWiki nodes usually terminates the public TLS connection, but the hop from the proxy to each node can still cross a shared network. Where your policy or threat model requires it, configure TLS on that internal hop and verify the certificate chain the proxy trusts. Confirm that session cookies are marked secure and that the proxy does not forward plain HTTP to nodes that accept it.
Restrict direct access to the database and storage network
The database and the shared storage for attachments should accept connections only from the XWiki nodes and the backup system. Check firewall or security group rules from the source addresses you intend, and confirm that no administrator workstation or other application can reach the database port. Run a connection test from outside the allowed sources and keep the result as evidence for the next review.
Vet extensions on every node before failover
Extensions installed on one node must be identical on every node, or failover can move users onto a version that behaves differently or has not been reviewed. Compare the installed extension list and versions across all nodes after each change, and record the approval for each one. Treat a node that was offline during a change as untrusted until its extensions match the approved list.
Plan for the OpenID Connect integration as a separate failure point
If users sign in through the xwiki-contrib OpenID Connect extension, the identity provider becomes a dependency that the cluster does not remove. When that provider is served from a single instance, an outage there blocks sign-in on every node, even though XWiki itself is healthy. Document the fallback position, such as an administrator account kept for emergencies, and test how the wiki behaves when the provider is unreachable.
What to monitor, back up and document after go-live
The first routine after go-live is watching the parts of a clustered XWiki that fail quietly. Start at the reverse proxy, where health checks show which XWiki nodes are answering and which have been taken out of rotation. Next, check the database layer. If you run replication, track replication lag and confirm which node is the primary, because a failover nobody noticed can leave writes going to a node that is no longer intended. Watch storage capacity for the database volumes and the attachment store, since a full volume is a common cause of partial outages. Add search index health, Tomcat error logs and XWiki extension errors to the same dashboard. Each signal needs a named owner, a threshold and a response agreed before go-live. Confirm with your database platform and monitoring tool which metrics they expose, because metric names and failover behavior differ between MySQL, PostgreSQL and MariaDB deployments.
Backup scope should cover everything needed to rebuild the wiki to a known state, not only the database. Include the database, the attachment storage, the XWiki and Tomcat configuration, the reverse proxy configuration, the list of installed extensions with their versions, and the image tags running on each node. Database and attachment backups must come from a consistent point, or pages may reference attachments that are missing from the restored copy. Replication is not a backup: it copies a bad deletion or a corrupted write to the standby as faithfully as a good one. Set backup frequency from the recovery point objective, which is the most data loss the business accepts. Ask the business owners to state that figure in hours or minutes, then choose the schedule and retention that meet it. Store copies outside the cluster and confirm who holds the encryption keys.
A backup only counts once it has been restored. Schedule restore drills at a frequency your change policy sets, and run them in a clean environment that is separate from live nodes. Each drill should confirm that the wiki loads through the proxy, that page counts and sample pages match the source, that attachments open, that search returns results, that users can sign in through the identity provider, and that extensions start without errors. Record the elapsed time and every failed step. Compare the measured time with the recovery time objective agreed with the business, and treat any gap as a planning issue to resolve. Update the restore runbook after every drill. A drill that exposes a missing file or an undocumented step is a finding to fix, not a pass to celebrate.
Hand-over documentation should let someone who was not on the project run a failover at night. Four documents matter most. The topology diagram shows the nodes, reverse proxy, database primary and standby, shared storage, search and the network paths between them. The failover runbook names the trigger, the decision owner, the steps to remove a node and promote the database, and the steps to fail back. The restore runbook covers backup locations, the order of restoration and the validation checks from the drill. The upgrade procedure must deploy the same XWiki image tag to every node, then move nodes one at a time behind the proxy, with a rollback step at each stage. Keep an extension register listing each extension, its version, its purpose and the named owner who approves updates. Release line choice and upgrade testing are covered in the upgrades topic, so plan those changes with this runbook open.
Questions teams ask before building XWiki high availability
Is one well-sized XWiki instance enough for our knowledge base?
For many wikis, one well-sized instance is a reasonable starting point, but the answer depends on your tolerance for downtime, your user count, and how much a short outage would disrupt work. A single node is simpler to run, patch and back up, and it has fewer moving parts to fail. Clustering adds value when a restart window is unacceptable, when user load outgrows one server, or when a policy requires redundancy. Before deciding, ask three things: how long the wiki can be unavailable, what the peak concurrent load looks like, and how fast you can restore from backup on a second host. Clustering also adds shared-state concerns such as database replication, session handling, search index consistency and extension behavior across nodes, so test the design against your own load profile instead of assuming more nodes is safer.
What drives the cost of an XWiki high availability build?
Cost is driven mainly by scope and by how much of the design is new to your team. The main drivers are the number of nodes and their placement, the database topology (replication, failover and backup), the reverse proxy and load balancing setup, the number and complexity of extensions that must behave identically on every node, identity integration, monitoring, and the test effort needed to prove failover works. Costs fall into one-time work (design, build, testing, documentation, runbooks) and recurring work (patching, backup verification, monitoring, and upgrades). Cloud, data center or air-gapped hosting changes infrastructure cost and lead time. DeployOpen does not publish prices. Ask any partner for a written scope that lists each component, the environments covered, the test scenarios, and which items are one-time versus recurring.
How long does a high availability project usually take?
Duration depends on the same drivers as cost, so no single timeline applies to every wiki. A project that reuses an existing database platform, uses a standard reverse proxy and has few extensions will move faster than one that needs new replication infrastructure, a new identity provider and custom extension testing. Schedule time for design decisions, environment provisioning, failover and restore testing, and a documented handover. Many delays come from waiting on infrastructure, change approvals and access to the database and identity systems, not from XWiki configuration itself. Ask a partner to show the phases, the dependencies on your team, and the milestones at which you approve the design and the test results.
What does our internal team need to provide during the project?
Your team needs to supply access, decisions and sign-off. Expect to provide cloud or data center accounts with the right to create load balancers, database instances, DNS records and certificates, plus a named owner for the database, the network, identity and the wiki business owners. Your team also needs to decide on backup retention, recovery time targets, maintenance windows and which extensions are approved for production. Someone internal should own the runbooks after handover, because failover procedures only stay accurate if the people who operate them have practiced them. Ask a partner exactly which of these inputs are required before work starts.
Can our own team build XWiki high availability without outside help?
Yes, a capable platform or infrastructure team can build it without a partner, provided it has experience with clustered application servers, relational database replication, reverse proxies and backup testing. The hard part is rarely the initial configuration. It is proving that failover, restore and upgrades work under real conditions, and keeping the design documented. Check whether your team has run database failover tests, whether it can rebuild a node from backup within your recovery target, and whether it has time to maintain the setup after go-live. If any answer is uncertain, an outside review or a scoped build can reduce risk. Outside help does not remove the need for internal ownership.
What should we ask a partner to include in a written scope?
A useful written scope names the environments, the XWiki line and database variant you will run, and the components in scope, such as the reverse proxy, database replication, backups, monitoring and identity integration. It should list the failover and restore tests, the acceptance criteria for each test, the documentation and runbooks delivered, and the knowledge transfer sessions. Ask which items are one-time and which recur, what is excluded (for example, extension development or content migration), what your team must provide, and how changes to scope are priced and approved. Most DeployOpen engagements are fixed-scope, so the agreed scope and timeline are set in writing before work starts.
How do consulting rates and Pro subscription tiers affect the budget?
XWiki SAS publishes its own commercial terms, and those affect the budget only if you choose to buy them. XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and support subscriptions come in Starter, Basic, Business and Enterprise tiers, based on user count. The tier that fits depends on your user count and on whether you want XWiki SAS support or Pro applications such as Active Directory SSO. Pricing is set by XWiki SAS, not DeployOpen, and the list terms may change, so confirm current figures on the XWiki pricing page and in writing with the vendor. Ask any partner to state separately which vendor subscriptions are required and which work is billed as services.
Which parts of the XWiki high availability design are hardest to get right?
The hardest parts are usually shared state and consistency. Every node must point to the same database, use compatible configuration, and run identical extensions and versions. Session handling behind a load balancer, search index behavior when more than one node writes, and attachment storage must be checked explicitly, since a default single-node setup does not reveal these issues. Database failover is another common weak point, because applications can fail in subtle ways during a switchover. Plan tests for node loss, database failover, restore from backup and a rolling upgrade, and record what happens to active sessions and in-progress edits during each one.
How DeployOpen scopes, builds and hands over XWiki high availability
DeployOpen plans, builds, tests, documents and supports self-hosted XWiki inside your own infrastructure, including the database, servlet container, reverse proxy and backup layers that high availability depends on. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm whether a clustered design or a single well-sized instance fits your uptime, recovery and staffing goals.
- Agree the XWiki line (stable or LTS) and the database variant before any infrastructure is provisioned.
- Record which components are in the written scope, including replication, reverse proxy, backups and failover tests.
How we build
- Deploy XWiki nodes, the shared database and reverse proxy in your cloud accounts, data centers or air-gapped network.
- Configure database replication, session handling and shared attachment storage, then test failover behavior against the agreed design.
- Verify backups by restoring them to a separate environment and documenting the measured recovery steps.
How we hand over
- Deliver runbooks covering node restarts, database failover, backup restores and reverse proxy changes in your language.
- Document the architecture, configuration decisions and the trade-offs accepted during scoping for your own operators.
- Walk your platform and operations team through failover drills so they can run them without DeployOpen present.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
- Plan XWiki upgrades and extension checks against the high availability design before they reach production.
- Ask any support provider to confirm response scope, failover test cadence and who owns incidents in the quote.
