XWiki Cloud or self-hosted XWiki: which model fits your team
Choose XWiki Cloud if your team lacks the capacity to run upgrades and backups, and you can accept standard pages and an annual upgrade cadence. Choose self-hosted XWiki if you need custom Java or database work, direct access to the database, filesystem or server, or if your data residency rules require you to control the infrastructure yourself. The hosting model is a question of who operates the platform, not of what it costs, because XWiki SAS states that Pro and support pricing is the same in the cloud or on premises. Decide on operations and control first, then price the chosen model.
XWiki Cloud fits a team with limited operations staff that is content with the cloud terms. On XWiki Cloud, the XWiki team performs installation, upgrades and backups, and the wiki is hosted with OVH in France, which XWiki's cloud FAQ describes alongside OVH's ISO 27001, SOC 1, SOC 2 and GDPR compliance statements. XWiki SAS upgrades cloud wikis proactively once a year, and an earlier upgrade can be requested but needs an analysis first. Standard pages and installed app pages must not be overridden, or upgrades can be affected. Confirm with XWiki whether your planned apps and extensions are supported on the cloud before committing, since Pro Apps are not installed by default there.
Self-hosting fits a team that needs direct control. On premises there are no customization limits and access to the database, filesystem, operating system and superadmin accounts is direct, which matters when you maintain custom code or integrate with internal systems. Your team then carries installation, upgrade timing and backup testing, and XWiki support is available depending on your support level. Before deciding, ask XWiki for a written breakdown of what its support level covers in your model, and check with your compliance lead whether a cloud hosting location or an on-premises one better meets your residency and audit requirements.
How the two hosting models differ on the factors that matter
This table compares XWiki Cloud and self-hosted XWiki on hosting, operations, customization, upgrade cadence, billing and Pro pricing. Read each row as a question to settle with XWiki SAS before signing, since several operational details still need written confirmation.
| Factor | XWiki Cloud | Self-hosted XWiki |
|---|---|---|
| Hosting location and provider | Hosted by OVH in France; XWiki's cloud FAQ states OVH holds ISO 27001, SOC 1, SOC 2 and GDPR compliance | Runs in your own cloud accounts, data center or network; you choose the location |
| Who installs, upgrades and backs up | XWiki team performs installation, upgrades and backups | Your team performs them, with XWiki support depending on your support level |
| Customization and direct access | Standard pages and installed app pages should not be overridden; database, filesystem, OS and superadmin access are indirect | No customization limits; database, filesystem, OS and superadmin access are direct |
| Upgrade cadence | Cloud wikis are upgraded proactively once per year; earlier upgrades need an analysis first | Upgrade timing is set by your team, using the release branch you choose |
| Billing terms | Monthly, yearly or 3-year engagement | Support is yearly or 3-year |
| Pro pricing parity | XWiki Pro and support priced the same as on premises, per XWiki SAS | XWiki Pro and support priced the same as in the cloud, per XWiki SAS |
| Confirm in writing | Backup frequency, retention period, restore testing, outage notice and the upgrade rollback path | Support hours, response targets and any help with backup design or restore testing under your chosen support plan |
Where your data sits and what compliance means in each model
Hosting location and certifications shape the first conversation about XWiki Cloud, but they do not settle compliance on their own. The cards below separate what the XWiki Cloud operator provides from what your team must still prove when XWiki runs on your own servers or cloud accounts.
Where XWiki Cloud data is hosted
XWiki's cloud FAQ states that XWiki Cloud runs with OVH in France. For a regulated buyer, the question is whether that location, plus any backup or support access outside France, fits your data residency rules. Ask XWiki SAS to confirm in writing where wiki data, backups and logs are stored, and where support staff can reach them from. In a self-hosted model, the location is whatever data center or cloud region your team chooses.
What the ISO 27001 and SOC claims cover
XWiki SAS lists ISO 27001 certified XWiki Cloud hosted in France through OVHcloud, and XWiki's FAQ says OVH is ISO 27001, SOC 1, SOC 2 and GDPR compliant. These are claims about named organizations and their scope. Ask for the certificate, the statement of applicability and the SOC report for the specific service you would use, and confirm whether they cover the XWiki application layer or only the underlying infrastructure.
Certifications belong to the operator
A certificate attaches to the organization that runs the controls, not to the hosting location. Choosing an ISO 27001 certified host does not make your wiki certified, and self-hosting on a certified cloud account does not make your wiki compliant by default. Each party in the chain, including XWiki SAS, the hosting provider, your team and any implementation partner, needs its own scope and evidence.
Operator duties in the XWiki Cloud model
XWiki's comparison states that the XWiki team performs installation, upgrades and backups for cloud wikis. Those duties produce operational evidence, such as backup records, change records and patch timing, that you may need for your own assessments. Ask which of these records XWiki SAS will share, how often, and in what format, and whether you can review the restore test results.
What you must evidence when self-hosting
On your own servers, your team performs installation, upgrades and backups, and holds direct access to the database, filesystem and operating system. That access is what makes self-hosting attractive for control, and it also means your team must produce the access logs, change tickets, backup restore tests and hardening baselines that an assessor will ask for. Plan these records before go-live, not during the audit.
What DeployOpen prepares and does not issue
DeployOpen can plan, implement, harden, back up and document a self-hosted XWiki inside your own cloud account, data center or air-gapped network, and prepare systems, controls and evidence for a compliance assessment. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so confirm with your assessor which evidence they will accept before the written scope is agreed.
How customization limits and direct access change the work
On XWiki Cloud, the main constraint is that standard pages and installed app pages should not be overridden, because overrides can break during the yearly cloud upgrade. Database, filesystem, operating system and superadmin access are all indirect, so the XWiki team controls the layer beneath your content. For a team whose needs stop at pages, spaces and rights, that boundary costs little. It matters most when you plan custom Java extensions, custom XWiki applications, or scripts that depend on server-side changes, since those may not be possible under cloud operation. Ask XWiki SAS in writing which extension types, script macros and custom server-side components it accepts on Cloud, and whether any of them need a review before the annual upgrade.
On self-hosted XWiki, the facts state there are no customization limits and access is direct. You can edit the database, install extensions at the file level, change the servlet container configuration and manage the operating system yourself. That freedom becomes important when you connect XWiki to internal systems, such as a directory service, an HR source of truth or a document management store, or when your audit logging must capture events below the application layer. Those integrations are where direct access earns its keep, and they are also where your team takes on the testing burden for every upgrade. Illustrative example: a custom extension that reads a legacy directory table would need regression testing on each XWiki release line you adopt.
Choose the model by listing the extensions, integrations and logging requirements before you compare prices, because the same Pro pricing applies either way. If every requirement fits within what Cloud accepts, the indirect access is a feature that removes server work. If one requirement needs direct database or filesystem access, plan to self-host from the start, since moving a customized wiki later is a migration project in its own right. Ask XWiki SAS to confirm, for each requirement on your list, whether it is supported on Cloud, on premises, or both, and document the answer alongside the upgrade and backup responsibilities.
What your team runs in each model
On XWiki Cloud, the XWiki team performs installation, upgrades and backups for your wiki. The platform is hosted with OVH in France, and XWiki's cloud FAQ states that OVH holds ISO 27001, SOC 1, SOC 2 and GDPR compliance. Your team keeps ownership of content, users, groups and rights inside the wiki, and it works within the operating envelope XWiki sets for the hosted service.
- Installation: XWiki provisions and configures the instance, so your team starts from a running wiki instead of a server build.
- Upgrades: XWiki upgrades cloud wikis proactively once per year. You can request an earlier upgrade, but XWiki analyzes the request first.
- Backups: XWiki performs backups as part of the service. Ask for the backup frequency, retention period and whether restores are self-service or ticket-based.
- Customization: Standard pages and installed app pages should not be overridden, so the upgrade path stays clear.
- Access: Database, filesystem, operating system and superadmin access are indirect.
Before you commit, confirm the upgrade calendar against your change freeze windows, and get the restore process written into the service terms.
When you run XWiki on your own servers, your team performs installation, upgrades and backups. XWiki support is available depending on the support level you buy, and it does not replace the operating work. You control the Tomcat version, the database engine, the filesystem layout and the superadmin account, which gives you direct access and no customization limits.
- Installation and configuration: Your team or a delivery partner builds the stack on your infrastructure, with the database variant and Tomcat setup you choose.
- Upgrades: Your team schedules and tests each upgrade, including the extensions and customizations you run. XWiki publishes stable and LTS lines, so you pick the line and the timing.
- Backups: Your team defines the backup scope across the database and attachments, and proves that restores work.
- Customization: You can change pages, templates and configuration directly, which also means you own the consequences at upgrade time.
- Support: XWiki support depends on your plan, so confirm response windows and what is covered before relying on it.
Review your staffing for on-call coverage and confirm that the support level you need includes upgrade assistance.
Monitoring, patching of the Tomcat and database layers, and security response are the duties that most often surprise buyers. XWiki's cloud comparison describes the split for installation, upgrades and backups, but it does not settle every operating duty in the same way. Treat each item below as a question to answer in writing, not as an assumption.
- Monitoring: Confirm who watches availability, errors and resource use, and who gets paged when the wiki fails.
- Tomcat and database patching: On cloud, confirm whether XWiki applies these between yearly upgrades. On premises, your team owns them, and the official Docker images for MySQL, PostgreSQL and MariaDB are one option for a repeatable base.
- Security response: Ask who triages a vulnerability in XWiki, the Java runtime or an extension, and how fast a fix reaches your instance.
- Access logs and audit data: Confirm which logs you can export, and how long they are kept.
- Extension risk: Pro apps are not installed by default on XWiki Cloud, so check which extensions you need and who maintains them.
Ask for the response process in the contract, not only in a product page.
A backup is only useful after a restore has been tested. The cloud and self-hosted models differ in who runs that test and who holds the evidence. Your compliance or audit team will ask for the results, so plan the test before the first production incident, not during it.
- Test frequency: Set how often you restore a copy of the wiki, and into what environment.
- Scope: Confirm that the test covers the database, attachments and configuration, since those three pieces must match.
- Evidence: Keep dated records of each test, including the time taken and any gaps found.
- Cloud model: Ask XWiki to describe the restore procedure, the test cadence it follows, and whether it will share restore test results with you on request.
- Self-hosted model: Your team builds the restore runbook and rehearses it, and you own any gap between the backup and your recovery target.
Ask whether a restore into a non-production environment is included, and whether it counts toward any service level.
XWiki publishes the cloud and on-premises pricing as equal for Pro and support, and it lists payment terms that differ by model. A quote should show what each party does, not only what each party pays. Because most engagements are fixed-scope, put the operating duties into the written scope before work starts.
- Responsibility matrix: Ask for a table that names the owner of installation, upgrades, backups, monitoring, patching and security response.
- Support level: Confirm the support hours, response targets and what the plan covers for upgrades and incidents.
- Term and payment: Compare monthly, yearly and 3-year cloud terms against yearly and 3-year on-premises support terms.
- Cost drivers: Ask which items are recurring, such as support and hosting, and which are one-time, such as installation, migration or training.
- Exit terms: Ask how you get your data and configuration back if you move away.
If DeployOpen is building or operating the self-hosted option, the written scope is where these duties must be assigned by name.
How XWiki pricing works in the cloud and on premises
The first decision is not about the subscription itself. XWiki SAS states that XWiki Pro and support have the same pricing whether the wiki runs on XWiki Cloud or on your own servers, so the license and support line on a quote should match in both cases. What differs is the billing rhythm: XWiki Cloud can be paid monthly, yearly or on a 3-year engagement, while on-premises support is offered yearly or on a 3-year term. Confirm the exact tier, user band (Starter, Basic, Business or Enterprise) and term in writing, because the tier is what you are actually buying in either deployment model.
The subscription is only one cost component. On XWiki Cloud, XWiki SAS performs installation, upgrades and backups, so your internal cost is mostly administration, content governance and integration work. On premises, your own staff or a partner perform those tasks, and you also carry the server, storage, database, backup storage and operating system costs, plus the time to test each yearly upgrade. Optional services are billed separately: XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day. Ask whether migration, customization of pages or apps, and SSO setup are priced as consulting days or as a fixed scope.
Costs rise with user count, the number of Pro apps and connectors you enable, the volume of consulting days, and the amount of customization you need on premises, since that work recurs with each upgrade. Costs fall when standard pages and installed app pages stay untouched, because that keeps upgrades predictable. In the written quote, request the tier and user band, the support term and response hours, whether Pro apps are included, the day rate and estimated days for any consulting or training, the backup retention and storage location you will rely on, and the cost of a single upgrade cycle. Ask for a statement of which items recur annually and which are one-time.
Moving a wiki between self-hosted XWiki and XWiki Cloud
This sequence shows what has to be inventoried, reconciled and verified before a wiki moves between your own servers and XWiki Cloud, so that cutover happens with known permissions, known customizations and a named owner for each step.
Inventory installed apps and customized pages
Start by listing every installed extension, every Pro application in use, and every page that overrides a standard page or an installed app page. Your wiki administrator and the XWiki SAS team should review this list together, because the cloud rules treat overridden standard and app pages differently from ordinary content. The output is a written inventory with one row per extension and per overridden page, marked with its owner and whether it is needed after the move. Ask XWiki SAS in writing which of these items it can host on XWiki Cloud before anyone changes the source instance.
Check customizations against cloud rules
Compare each inventory row with the cloud rules for standard pages, installed app pages, database, filesystem, operating system and superadmin access. Mark each customization as compatible, needs redesign or not available on XWiki Cloud. Self-hosted instances have no customization limits and direct access, so this step usually surfaces work your team has been doing without a written boundary. The output is a signed-off conflict list that your security and platform owners accept as the basis for the move, or a decision to stay on premises for that workload.
Plan the data export and import with XWiki SAS
Agree with XWiki SAS how content, attachments, page history, users, groups and rights will be exported from the source and imported into the target. Ask them to confirm, in writing, the migration method, the effort and the timing for your wiki size, and who runs each part. If you are coming from Confluence rather than from another XWiki instance, confirm separately what the Confluence Migrator Pro extension carries over, including its limits on attachment history. The output is a migration plan with named owners, a rollback point and a written estimate that you can compare with the quote.
Validate permissions and SSO
Rebuild the rights model on the target at wiki, space and page level, then test it with sample accounts for each role that uses the wiki. If you rely on single sign-on, confirm which identity options the target supports for your setup, and treat the xwiki-contrib/oidc extension as an option to verify against your identity provider rather than a given. Document which accounts hold superadmin rights and how they are managed on each side. The output is a test record showing each role can view, comment, edit and delete only what it should, and that sign-in works through the agreed path.
Run a trial on try.xwiki.com where applicable
Where the migration plan allows, use a trial instance at try.xwiki.com to rehearse the import and the rights model before committing to a paid cloud subscription. The published trial allowance is 3 trials of 10 days each, so schedule the rehearsal inside that window and confirm the trial scope with XWiki SAS. Compare the rehearsal results against the inventory and the rights test record, and log every gap. The output is a short rehearsal report that lists what migrated cleanly, what needed rework and what remains open before cutover.
Cut over DNS or custom server names
Schedule the cutover with a freeze on edits to the source instance, run the final export and import, and then point users to the new address. On XWiki Cloud, Basic and higher customers can use a custom server name with their own certificate and a CNAME to cloud.xwiki.com, so confirm your tier and certificate process with XWiki SAS before cutover day. Your network team should own the DNS change and the certificate installation. The output is a verified sign-in and read-write test on the new address, with the change record and rollback steps filed.
Retire the old instance
Keep the source instance in read-only mode for a period your records and retention policy define, then take a final backup, decommission the server and remove its credentials and access paths. Confirm with your compliance owner which backups and logs must be retained and where they live. Once the old instance is retired, confirm in writing with XWiki SAS that the cloud subscription, support contacts and yearly upgrade schedule match what your team expects. The output is a decommissioning record and an updated runbook that names who now performs backups and upgrades.
Questions buyers ask before choosing a hosting model
Is XWiki Cloud priced the same as self-hosted XWiki?
Yes, XWiki SAS states that Pro and support pricing is the same whether the wiki runs in XWiki Cloud or on your own servers. What differs is the billing term. XWiki Cloud can be paid monthly, yearly or on a 3-year engagement, while on-premises support is offered yearly or on a 3-year term. Your total cost still depends on which tier you need, since the Starter, Basic, Business and Enterprise tiers are sized by user count. Your own infrastructure, staff time and backup storage are costs only you carry on premises. Ask XWiki SAS to confirm the tier and term for your user count in writing.
How much staff time does self-hosting XWiki need, and what drives it?
The time depends on the work you take on, and no fixed figure is supplied here. On XWiki Cloud, the XWiki team performs installation, upgrades and backups. On premises, your team performs them, with XWiki support available depending on your support level. The main drivers are the number of environments you run, how often you patch the Java application server and database, how large the wiki and its attachments grow, how many Pro apps and connectors you install, and how strict your backup and restore testing must be. Ask for a written split of responsibilities before you estimate internal hours.
Can our team run XWiki upgrades ourselves?
Yes, on premises the customer performs upgrades, so your team can run them if it has the skills and time. The XWiki Docker images are published in stable, LTS and intermediate LTS lines, which gives you a choice of release line to match your change windows. Plan for database migration checks, testing of your installed extensions and custom pages, and a rollback path before each upgrade. If your team cannot maintain that cycle, a support plan or an implementation partner can take part of the work, and you should confirm the scope in writing before work starts.
How often does XWiki Cloud upgrade, and can we ask for an earlier upgrade?
XWiki SAS upgrades cloud wikis proactively once per year. You can request an earlier upgrade, but XWiki first performs an analysis of the request. Plan your content and extension work around the yearly cycle, and ask XWiki SAS what the analysis covers, how long it takes and whether any of your installed apps or customizations would need changes before an earlier upgrade can proceed. Confirm the upgrade calendar and notification process in the cloud terms before you commit.
Do our customizations survive an XWiki Cloud upgrade?
They survive only if they stay within the cloud rules. On XWiki Cloud, standard pages and installed app pages should not be overridden, because overrides can interfere with upgrades. Database, filesystem, operating system and superadmin access are indirect in the cloud. On premises there are no customization limits and access is direct, so you can change more, but you then own the testing and merge work at every upgrade. Inventory your overrides, scripts and extensions before choosing, since that list determines how much the cloud model constrains you.
How hard is it to move from XWiki Cloud to self-hosted XWiki later, or the reverse?
Moving is possible in either direction, but it is an export, transfer and validation project, not a switch. Check how your content, attachments, users, groups, rights and installed extensions would map to the target. Confirm with XWiki SAS what export options exist from the cloud and whether the target version and database match. Also check that custom server names and certificates can be reassigned. Budget testing time for permissions, which are the most common source of errors after a move. Ask for the exit steps in writing before you sign a multi-year term.
Where is XWiki Cloud hosted, and what certifications does the hosting carry?
XWiki Cloud is hosted with OVH in France. XWiki's cloud FAQ states that OVH is ISO 27001, SOC 1, SOC 2 and GDPR compliant, and XWiki SAS lists ISO 27001 certified XWiki Cloud hosted in France through OVHcloud. These statements describe the hosting provider and XWiki SAS, not an audit report for your wiki. Ask XWiki SAS for the current certificate scope, the data processing terms and where backups are stored, and have your compliance lead confirm that the scope fits your data classification and regulatory obligations.
How DeployOpen scopes and runs self-hosted XWiki
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For XWiki, that means starting from the decision your team has to make: whether the wiki should run in XWiki's hosting or in your own cloud account, data center or air-gapped network, and what that choice means for upgrades, customization and access.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- The written scope states which XWiki edition, database variant and hosting location the work covers
- Scope lists who performs installation, upgrades and backups, and where each responsibility sits
- Customization boundaries are recorded up front, including which pages and apps will be overridden
- Quotes follow from the written scope, so ask for each line item to be tied to a deliverable
How we build
- Installation and configuration on your chosen infrastructure, using the database variant your team selects
- Identity integration with your existing directory or single sign-on provider, tested with real user groups
- Rights model設計 mapped to wiki, space and page levels so permissions match your documented access rules
- Backup and restore procedures are built and tested before the wiki holds production content
- Upgrade runbooks are written for each release line your team chooses to follow
How we hand over
- Operating documentation covers installation, configuration, backups, upgrades and access controls
- Handover includes a walkthrough of the upgrade path, so your team knows what to test before each release
- Evidence for compliance assessments is prepared as operational records, while auditors issue any reports
- Knowledge transfer sessions cover administration tasks your team will run after the engagement ends
- Open items and decisions are logged so the next owner can see why the design looks the way it does
How we support
- Ongoing support, upgrades and continuous testing are available as retainers
- Retainer scope is agreed in writing, including which upgrade windows and release lines it covers
- Security testing of the wiki and its integrations can be scoped separately from platform support
- Support requests are handled against the agreed scope, with changes priced through a new written scope
- Confirm response expectations and escalation paths with DeployOpen before signing any retainer
