How XWiki Collabora Online integration edits attachments over WOPI
The XWiki Collabora Connector Application uses WOPI to let users open documents, spreadsheets and presentations attached to XWiki pages in a Collabora Online server that you run separately, and it can create new office files from the page. Use it when the goal is to edit an attachment in place, without downloading it, changing it locally and uploading it again. The connector needs XWiki 15.10 or later and a Collabora Online server address entered on the application's administration page, so the first check is which XWiki version you run today and whether an upgrade is already planned. Confirm the compatibility statement in the XWiki Store listing before you schedule that work.
When a user opens an attachment, XWiki passes the document to the connector, which hands the editing session to Collabora Online through the WOPI protocol. Collabora Online then calls back to XWiki to fetch the file and, as people save, to write changes back to the attachment. Two network paths therefore matter: the user's browser must reach the Collabora Online server, and the Collabora Online server must reach XWiki at an address it can resolve and trust. Both paths are easy to get wrong when XWiki sits behind a reverse proxy or when the office server lives in a separate network zone, so test each path with one attachment before you open the feature to a group of users.
Collabora Online is built on LibreOffice technology and is integrated into existing platforms through WOPI, which is the same mechanism that lets other WOPI hosts use it. The server code is licensed under the Mozilla Public License 2.0 (MPL-2.0), a file-level copyleft license, so have your legal or compliance team review your obligations if you modify its source files. Collabora's free CODE edition is described by Collabora as suited to testing, home use or small teams and not recommended for production. For production, the Collabora Online pricing page lists a Business plan at 3 euros per user per month for up to 99 users, so confirm which plan and support terms your quote assumes.
Settle three decisions before installation. First, decide whether the Collabora Online server runs in the same network zone as XWiki or in a separate one, because that choice changes firewall rules, certificate handling and the address you enter in the administration page. Second, name the people who may change that server address and who approves the change. Third, decide whether a user may create new office files from a page, since a created file becomes an attachment that depends on the page's rights. Ask the connector's maintainers which permissions it checks for view and edit actions, and test with a user who has view-only rights before you rely on the access model.
What you need before connecting XWiki to Collabora Online
These five inputs decide whether the Collabora Connector can be installed and tested without rework. Each one has an owner on your side, and the team should close every item before a change request is raised. Most delays come from unclear ownership of DNS, certificates and the Collabora Online server, so agree those owners first.
XWiki version and release line
The Collabora Connector Application requires XWiki 15.10 or later. Choose the release line before work starts. The current official Docker image tags are 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS. The XWiki platform owner makes this choice, and the team must confirm connector compatibility with that line before anything goes into production.
Separately deployed Collabora Online server
The connector does not include an office server. A Collabora Online instance must run separately, and its address is entered in the connector's administration page. The infrastructure team that will host it owns this item. Confirm the deployment method (Docker images, system packages or Kubernetes) and the edition. Collabora describes its free CODE edition as suited to testing, home use or small teams, and not recommended for production.
Reachable, TLS-protected server address
The XWiki server and users' browsers must both reach the Collabora Online address over HTTPS, because WOPI passes document traffic between the hosts. The network and security team owns this item. Confirm firewall rules, that the certificate chain is trusted by the XWiki Java runtime and by client browsers, and any proxy or load balancer in front of Collabora. On Kubernetes, the load balancer must route by the WOPISrc parameter.
DNS names for both hosts
Give the XWiki host and the Collabora Online host stable, fully qualified names that resolve from the XWiki server and from user networks. The DNS or platform team owns this item. Confirm that both names appear in the certificate's subject alternative names, and that internal and external resolution agree if users reach XWiki from outside your network. Renaming a host later means updating the connector address and reissuing certificates.
Connector license terms in the XWiki Store
The Collabora Connector Application is listed in the XWiki Store under the Pro name, so read its license and usage terms there before purchase or installation. Procurement or legal owns this item, with the XWiki platform owner. Confirm which terms apply to your XWiki edition and support plan, and file the approved terms with the change record so later audits can trace the decision.
How the WOPI session flows between XWiki and the Collabora server
When a user clicks edit on an office attachment, the XWiki Collabora Online integration does not open the file inside XWiki itself. XWiki, through the Collabora Connector Application, hands the browser a WOPI-based session that points to the Collabora Online server configured in the application's administration page. The browser then loads the editor from that server, and the server calls back to XWiki over WOPI to read the file and, as the user saves, to write changes back. Understanding this three-party exchange is the foundation for every network, routing and sizing decision on this page.
Two network paths have to work, and teams often verify only one of them. The user's browser must reach the Collabora server to load the editor interface, and it must also reach the XWiki host, because the editor frame and its session calls are tied to the WOPI host address that XWiki supplies. The Collabora server must separately reach the XWiki host to fetch and store the document. If the server is in a private network segment, confirm that it can resolve and open a connection to the XWiki address as it is presented to the browser, including any reverse proxy or TLS terminator in front of XWiki. Ask your network team to test both directions from the actual hosts rather than from a workstation.
The Collabora server does not hold the authoritative copy of the document. It works on a session copy that it retrieves through the WOPI callbacks, and the attachment in XWiki remains the record of truth. This has direct consequences for backup and recovery. Restoring XWiki from backup restores the attachments, while a Collabora server restart or replacement does not, by itself, change stored content. Plan your backup scope around XWiki and its database and attachment storage, and treat the Collabora server as replaceable compute, as long as you confirm the exact save behavior during an interrupted session with the vendor's documentation for your release.
Several decisions follow from this flow. You need to choose the public address for the Collabora server, the address XWiki uses to reach the Collabora discovery endpoint, and the callback address the server uses to reach XWiki, and these are often different. You also need to confirm which XWiki version you run, since the Collabora Connector Application requires XWiki 15.10 or later according to the XWiki Store listing. Document these addresses and the version in your design record before testing, because a mismatch in any one of them produces an editor that fails to open with errors that look unrelated to the network.
For the first test, pick one small .docx or .xlsx attachment and walk the full path: open the editor, confirm the document loads, make an edit, save, reload the XWiki page and check that the change appears in the stored attachment. Repeat the test from a user outside the office network if remote staff will edit. Record which hostnames and ports each step used. This test log becomes the baseline for your operations runbook and for any later change to the proxy, the certificate or the Collabora version.
Setting up the XWiki Collabora Online integration in order
This sequence connects a supported XWiki version to a self-hosted Collabora Online server over WOPI, so users can edit office attachments and create new office files inside wiki pages. Each step ends with a check that tells you whether the previous step worked before you move on.
Confirm the XWiki version
The XWiki administrator checks the running version in the administration area before anything else. The Collabora Connector needs XWiki 15.10 or later, so an older instance must be upgraded first, and the upgrade should follow your own change process. Done means the version shown is 15.10 or higher and the wiki loads normally after any upgrade. If you are unsure which line you run, confirm it with your XWiki administrator before you install the connector.
Install the Collabora Connector Application
The XWiki administrator installs the Collabora Connector Application from the XWiki Store through the extension manager, on a staging instance first where one exists. The connector provides the WOPI handling that lets XWiki hand attachments to Collabora Online. Done means the extension appears in the installed extensions list without errors, and its administration page opens for a user with administrator rights. Check the wiki's extension log if the install reports a dependency problem.
Deploy the Collabora Online server
The platform or infrastructure team deploys the Collabora Online server using Docker images, a system package or Kubernetes, depending on your standards. The free CODE image (collabora/code) is suited to testing, home use or small teams, and Collabora does not recommend it for production, so use a supported deployment for production. For Kubernetes with more than one replica, confirm that your load balancer routes requests by the WOPISrc parameter so all users editing one document reach the same pod. Done means the server responds to a basic request from a machine on the XWiki network.
Configure TLS and the server address
The platform team configures TLS on the Collabora Online server and sets the address that browsers and XWiki will use to reach it. Confirm the exact configuration keys and certificate requirements in the Collabora Online documentation for your chosen deployment method, and make sure the certificate is trusted by both users' browsers and the XWiki server. Done means the server address opens over HTTPS with a valid certificate, and the discovery page for WOPI loads from the XWiki host. Failed certificate validation here will also block later steps.
Enter the server address in the connector
The XWiki administrator opens the Collabora Connector administration page and enters the Collabora Online server address exactly as configured in the previous step. Save the settings, then check that the connector accepts the address without a validation error. Done means the saved value is still shown after you leave and return to the page. If the save succeeds but editing later fails, check the XWiki logs for connection errors to that address, which usually point to DNS, proxy or certificate issues.
Open a test attachment in edit mode
An XWiki administrator uploads a small test document, spreadsheet or presentation to a test page and opens it for editing from the attachment view. Use a test space, not production content. Done means the Collabora editor loads inside the wiki page and the document opens with its content. Make a visible change, save it, then reload the page to confirm the saved change persists in the attachment. If the editor frame stays blank, search the Collabora and XWiki logs for failed WOPI calls.
Create a new office file
From the same test space, an administrator uses the connector's option to create a new office file, then types a line of text and saves it. This confirms that the connector can create files as well as open existing ones, which the Collabora Connector supports. Done means the new file appears as an attachment on the page, opens in the editor again, and keeps the text after a reload. If creation fails while opening existing files works, check the permissions of the test user and the logs for the create request.
Which XWiki attachments and file types map to Collabora documents
This table maps each XWiki object involved in office editing to the behavior it controls and the person who sets it. Read it before you plan a test wiki, because the connector, the Collabora Online server and page-level rights each need a named owner. The main takeaway is that the supported file extension list is not supplied here, so confirm it against the XWiki Store page and your chosen Collabora Online release before you promise users any format.
| Object | What it controls | Who sets it | What to confirm |
|---|---|---|---|
| Office attachments on a page | Word processing, spreadsheet and presentation attachments open in Collabora Online for browser editing over WOPI | Page author uploads files, wiki administrator installs the connector | Exact extension list for your connector version in the XWiki Store |
| Supported document, spreadsheet and presentation formats | Which extensions the connector sends to Collabora Online, and which remain plain downloads | Wiki administrator, based on the connector version installed | Editing behavior for each listed extension on your Collabora Online release |
| Other attachment types | PDFs, images, archives and other files that are not on the supported list | Page author attaches, wiki administrator sets view rights | How these files behave in your test wiki after the connector is enabled |
| New office files created from the wiki | New documents, spreadsheets and presentations created in Collabora Online and saved as attachments | Page author creates files, wiki administrator configures the connector | Which file types the create option offers in your release |
| Collabora Online server address | The address of the separately deployed Collabora Online server that the connector calls | Wiki administrator enters it in the connector administration page, server administrator supplies it | The address resolves and is reachable from both XWiki and user browsers |
| Minimum XWiki version | The Collabora Connector requires XWiki 15.10 or later | Platform owner chooses the XWiki version to deploy | Your planned XWiki release is 15.10 or later |
| Collabora Online server settings | Server-side WOPI access, TLS and request routing for the editing server | Server administrator | Routing that keeps all users of one document on the same pod in Kubernetes deployments |
| Editing rights on pages and attachments | Whether a user can open an attachment for editing or only view it | Wiki administrator sets page and space rights | View-only and edit users behave as expected on a sample attachment |
Choosing a Collabora Online license for XWiki users
Choose the Collabora Online edition before you size the server, because the edition decides whether you get support commitments that a production wiki needs. CODE, the free Collabora Online Development Edition, is released on average once a month as a rolling release. Collabora describes it as suited to testing, home use or small teams and not recommended for production. For a proof of concept that connects the XWiki Collabora Connector to a test server, CODE is a reasonable starting point. For attachments that business teams depend on every day, plan for a paid tier from the start so that you do not have to migrate the server later.
According to the Collabora Online pricing page, the Business plan costs 3 euros per user per month for up to 99 users. The plan includes long term support, a service level agreement, signed security updates and customer portal access. Those four items matter most to a wiki team: long term support lets you hold one server version while XWiki and the browser stack change around it, signed security updates give your security team something to verify, and the service level agreement defines what Collabora commits to when something breaks. To estimate the recurring fee, multiply your expected named editors by 3 euros and by 12 months, then confirm with Collabora whether the count is based on users with editing access, total accounts, or another measure.
The Enterprise plan applies to 100 or more users and is quoted with volume discounts. It adds integration support, customization services and roadmap input. Integration support is relevant if your XWiki instance sits beside other WOPI hosts, identity providers or a reverse proxy that you manage separately, because the vendor can help with that boundary. Ask Collabora to state in writing which of these services apply to your user count, how many support contacts are included, how customization requests are billed, and whether the quote covers test and production servers as separate instances. Do not assume the per-user rate applies unchanged above 99 users.
Network, routing and sizing for a production Collabora Online server
A production Collabora Online server behind the XWiki Collabora Connector depends on three decisions: how traffic reaches the right pod, how many pods run, and what resources each one gets. The cards below cover the rules from the official Helm chart and the points to validate before the server takes live editing traffic.
Disable autoscaling and set replicas by hand
The official Collabora Online Helm chart disables horizontal pod autoscaling because scaling events break collaborative editing and copy and paste. Replica counts are therefore a fixed decision made by your team, not a metric the cluster adjusts for you. Check who owns that number, how it changes during peak periods, and how a planned change is rolled out without disrupting users who have documents open.
Route by the WOPISrc parameter
Every user editing the same attachment must land on the same Collabora pod, so the load balancer or ingress must route on the WOPISrc parameter that identifies the document. Without this rule, co-editors can be split across pods and lose their shared session. Confirm the routing rule with your ingress team, test it with two browsers editing one XWiki attachment, and confirm that the rule survives certificate renewals and ingress reloads.
Recommended per-pod limits and requests
The Helm chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Requests determine scheduling, so a node without that headroom will not accept the pod. Check these values against your node sizes and against the other workloads in the same cluster, and record who approves any change to them.
Supported ingress controllers
The Helm chart documentation names three supported ingress controllers: Nginx, HAProxy and OpenShift Router. Choose one of these for the routing rule above and confirm its version and configuration with your platform team before go-live. If your organization standardizes on a different ingress, plan a proof of concept that demonstrates WOPISrc routing before you commit to it.
Validate sizing against your own load
The recommended limits are a starting point, not a capacity plan for your organization. Actual sizing depends on how many people edit documents at the same time, the size and complexity of your office files, and how long sessions stay open. Measure concurrent editors and document sizes during a pilot, then set replica counts from those figures. Ask the Collabora team which volumes they have tested before you rely on any published guidance.
Controller for large deployments
Collabora offers the Collabora Online Controller for large deployments, which is the product line to evaluate once a single managed set of pods no longer fits your user base. Ask Collabora what the Controller changes in routing, scaling and support before you design around it, and confirm whether it is needed at your expected volume. Keep the decision in the sizing review so it is made with the pilot data in hand.
Why XWiki Collabora Online editing fails and how to fix it
This table lists six common reasons XWiki Collabora Online editing fails, with the likely cause, the check to run and the fix for each. Work through the rows in order, because network and certificate faults stop the connector before load balancing or version issues can appear. The main takeaway is that most failures trace to addresses, routing or versions that a few requests from the affected hosts can confirm.
| Symptom | Likely cause | Check to run | Fix |
|---|---|---|---|
| Connector cannot reach the Collabora server | Wrong server address in the connector administration page, an untrusted certificate, or a firewall blocking traffic from XWiki | Request the Collabora server address from the XWiki host and confirm the certificate chain is trusted by the Java runtime | Correct the address, install the internal CA certificate in the trust store, and open the port between the two hosts |
| Editors open but sessions drop | Load balancer ignores the WOPISrc parameter, or scaling sends users editing one document to different pods | Confirm the balancer routes on WOPISrc and that all sessions for one document reach the same pod | Route by WOPISrc and set replica counts manually, because the Helm chart disables autoscaling for this reason |
| Collabora cannot call back to XWiki | The XWiki host name is not resolvable or reachable from the Collabora server, so document load and save fail | From the Collabora container, request the XWiki WOPI endpoint using the same host name XWiki advertises | Make the host name resolve on both sides through DNS or hosts entries, and allow the route through network policies |
| Blocked content in the editor frame | XWiki is served over HTTPS but the Collabora address or callback uses HTTP, so the browser blocks mixed content | Check the scheme of the configured Collabora address and the XWiki base URL, then review the browser console for blocked requests | Serve both services over HTTPS and set the public URLs in XWiki and Collabora Online so they match |
| Connector cannot be used on this XWiki | XWiki is below 15.10, the first version the Collabora Connector requires | Check the XWiki version in the administration area before installing the connector application | Upgrade XWiki to 15.10 or later, then install and configure the connector |
| Collabora Online runs as CODE in production | CODE is the free edition, released roughly monthly, and Collabora does not recommend it for production | Check the image in use, which for CODE is collabora/code, and confirm the edition and version running | Deploy a supported Collabora Online build, and ask Collabora which plan covers long term support and security updates |
Security settings for XWiki and Collabora Online traffic
These settings cover the connections that carry office files between XWiki, the browser and Collabora Online. Each card addresses one control: certificate trust, which hosts may send WOPI requests, administrative access, patching, the AI assistant and access logging. Items marked for confirmation should be checked against the Collabora Online documentation for your version before go-live.
TLS and trusted certificates
Serve both the XWiki host and the Collabora Online server over HTTPS with certificates that the user's browser and both servers trust. Browsers load the editor from Collabora, and the two servers call each other during WOPI requests, so an untrusted certificate on either side can break editing without an obvious error. Check that the chain includes any internal certificate authority, that the Collabora server trusts the XWiki certificate for document requests, and that renewal is covered in your operations runbook. Confirm the exact trust configuration in the Collabora Online documentation for your install method.
WOPI host allow list
Collabora Online should accept WOPI requests only from hosts it is configured to trust, so limit that list to the XWiki hostname that runs the Collabora Connector. Any other system that can reach the Collabora listener could otherwise request document sessions, so restrict network access to the listener as well. Test the allow list with a document attached to a wiki page, then send a request from an unlisted host, which should be refused. Confirm the option name and its format in the Collabora Online administration documentation for your version.
Server administration interface access
Collabora Online provides an administration console for managing settings, documents and sessions. Keep it off the public listener, reach it only from an administrative network or bastion path, and require strong, unique credentials stored in your secrets manager. Review which accounts can sign in and log administrative logins. Confirm in the Collabora documentation how the console is enabled, which path it uses and whether your deployment method exposes it by default.
Signed security updates and patching
Collabora Online publishes point releases on its supported branches, and the Business plan on Collabora's pricing page includes signed security updates. Decide who receives those updates, how they are tested against your XWiki Collabora Connector version, and when they move to production. Collabora describes CODE, its free edition, as not recommended for production, so confirm whether your deployment needs a supported plan before go-live. Follow the branch and point release schedule that your support policy requires.
AI assistant review before enabling
Collabora Online 26.04 adds an optional AI assistant across Writer, Calc and Impress. The assistant is off by default, and administrators choose the provider and whether it runs externally or on infrastructure they control. Before enabling it, check what document content is sent, where it is processed, how long the provider retains it and whether your data classification rules allow office files with sensitive data to reach it. Keep it disabled for wikis that hold regulated content until that review is signed off.
Logging and reviewing office file access
Office files attached to wiki pages can contain sensitive data, so access should leave a trail. Collect XWiki page and attachment access logs, Collabora Connector and Collabora server logs, and reverse proxy logs, then correlate them by user, document and time. Define who reviews them, how often, and what triggers an investigation. Confirm which WOPI events Collabora records by default and whether document identifiers appear in its logs, because that determines how much detail you can reconstruct after an incident.
Questions buyers ask before adding Collabora Online to XWiki
How much does Collabora Online cost for XWiki users?
Collabora Online is licensed per user through a subscription, and the price depends on how many people will edit office files. According to Collabora's pricing page, the Business plan costs 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access. For 100 or more users, Collabora quotes the Enterprise plan with volume discounts, which adds integration support, customization services and roadmap input. The free CODE edition is not recommended for production. Recurring costs are the subscription and the servers you run. One-time costs are setup, certificates, routing and testing. Ask DeployOpen for a quote that separates the Collabora subscription, infrastructure and implementation so you can compare the items directly.
How long does a Collabora Online setup for XWiki take?
Duration depends on your environment and on the number of server hosts, so no fixed timeline applies to every project. The main effort drivers are your network layout, how TLS certificates are issued and renewed, how the load balancer routes requests, and how much testing your users need before go-live. A single test server with few users takes less work than a multi-host production cluster that must route each document to a consistent pod. Most DeployOpen engagements are fixed-scope, so ask for a written scope that states the environment, the number of hosts, the deliverables and the timeline before work starts. Compare any timeline you receive against that scope.
What must our team provide for a Collabora Online and XWiki integration?
The project moves faster when you name an owner for each system before the scope is signed. You need a named XWiki administrator who can install the Collabora Connector Application and set the Collabora Online server address in its administration page. You need a DNS owner who can create the records for the Collabora hostname, a TLS owner who can supply or issue certificates the browsers and XWiki trust, and a load balancer owner who can configure routing. You also need a representative for the user population, with approximate user counts, the office file types people edit, and a few test accounts. Confirm the XWiki version is 15.10 or later, because the connector requires it.
Can our own team set up Collabora Online for XWiki without a partner?
Yes, a capable team can build a test setup on its own, and this is a common starting point. A test environment lets your administrators confirm that the connector opens, edits and creates documents over WOPI before any production decision. Production is different. Routing by the WOPISrc parameter, replica counts, resource sizing and the network path between XWiki, the browsers and Collabora deserve an independent review before users depend on the service. If your team has no Kubernetes or load balancer experience, plan for that review earlier. DeployOpen can deliver the full implementation or a review of a design your team has already built, and the scope will state which.
Do we need a separate license for the Collabora Connector in XWiki Store?
Yes, check the licensing of the connector before you install it, because the XWiki Store listing is named Collabora Connector Application (Pro). The name suggests that it belongs to XWiki's Pro offering, but the listing terms, the support tier and any per-installation conditions are what govern your use. Confirm the license with XWiki SAS and read the extension page in the XWiki Store before you plan the rollout. Keep this check separate from the Collabora Online subscription, since the two are licensed by different companies. Include the confirmed connector license in your quote request so the scope reflects the cost of the full stack.
Why does Collabora Online need sticky routing behind a load balancer?
Collabora Online must send every user editing the same document to the same pod, so the load balancer has to route by the WOPISrc parameter. According to the official Collabora Online Helm chart README, horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste. Replica counts are therefore set manually and changed through a planned change, not by automatic scaling. Your ingress must be Nginx, HAProxy or OpenShift Router, which the chart supports. Test this routing with two users editing the same file at the same time before you open the service to all staff. Also confirm how replica changes affect documents that are open during a restart.
What resources should each production Collabora Online pod have?
The official Collabora Online Helm chart README recommends production resource limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Treat these as the chart's starting point, not a sizing result for your organization. The right size depends on the number of concurrent editors, the size and complexity of your spreadsheets and presentations, and the number of pods you run. Measure a test environment with realistic documents and users, then compare the measurements with the chart values. Ask any implementation partner to show the sizing method and the load test results, not only the final numbers.
How DeployOpen scopes and supports the Collabora Online integration
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, and this integration follows the same written-scope method. The work covers the XWiki Collabora Connector, a separately run Collabora Online server, the WOPI routing between them and the network paths users depend on.
How we scope
- Written scope names the XWiki version, which must be 15.10 or later for the Connector.
- Confirm which office file types users must edit, such as documents, spreadsheets and presentations, plus new-file creation.
- Fixed-scope engagements record Collabora server hosting, network paths and any ongoing support retainer before work starts.
How we build
- Install the Collabora Connector in XWiki and point its administration page at the Collabora Online address.
- Deploy the Collabora Online server by Docker image, system package or Kubernetes, as agreed in scope.
- On Kubernetes, route WOPI traffic by WOPISrc so all users editing one document reach the same pod.
How we hand over
- Document the server version, TLS endpoints, WOPI host settings and the firewall rules between XWiki and Collabora.
- Provide a runbook covering Collabora updates, replica changes and checks after each XWiki upgrade.
- Record the server license, which is MPL-2.0, and any paid Collabora plan your user count requires.
How we support
- Retainers can cover Collabora Online updates, monitoring of the WOPI path and reviews of XWiki upgrades.
- Use CODE only for testing, since Collabora does not recommend the free edition for production.
- Test each Collabora Online release point against your XWiki version before rolling it out to users.
