How Open-Xchange and Collabora Online integration works in practice
Collabora Online is a WOPI-based editor that OX App Suite can reach through the wopi-server, which lets users open and edit office documents in the browser while the files stay in infrastructure you control. The exact supported method, configuration keys and capability flags must be confirmed against Open-Xchange's documentation for your target release before the build starts, because they depend on the OX version you run and can change between releases. In practice, the integration comes down to a few URLs, trust settings and a shared understanding of how OX hands a document to the editor. The WOPI host (OX) gives Collabora a reference to the file, Collabora reads and writes it through the WOPI endpoints, and the user's browser loads the editor interface from Collabora's host.
Collabora Online is built on LibreOffice technology, and the Collabora Online server code is licensed under MPL-2.0, which matters if your legal team reviews each component's license before deployment. OX App Suite already includes its own Documents module for editing office files, so the team must decide which editor serves which users before configuration begins. For example, one option is to keep the built-in Documents module for users who edit files in Drive and attachments, and reserve Collabora for users who need specific formats or features. This is an illustrative split, not a recommendation. Confirm with Open-Xchange whether the Documents module is covered by your license agreement, since the Operations Guide notes that certain modules may carry separate fees.
The deployment shape follows from the decision about which editor serves which users. Collabora provides an official Helm chart for Kubernetes, and its README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste. Replica counts are therefore set manually, and your load balancer must route requests by the WOPISrc parameter so that everyone editing the same document reaches the same pod. Confirm that your ingress controller supports this routing. The chart supports Nginx, HAProxy and the OpenShift Router, and you should check that choice against the ingress option your OX App Suite cluster uses, which may be Istio or ingress-nginx depending on the OX release.
Sizing and licensing are the last checks before the build plan is final. The Collabora chart recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, but these figures are a starting point to validate against your expected number of concurrent editors. Collabora's free CODE edition is positioned for testing, home use or small teams and is not recommended for production. Collabora's published Business plan price is 3 euros per user per month for up to 99 users, and the Enterprise plan for 100 or more users is quoted with volume discounts, so ask Collabora for a written quote that states support terms, update commitments and any integration services. These subscription costs recur separately from your implementation work.
What you need in place before you connect Collabora to OX App Suite
Connecting Collabora Online to OX App Suite depends on decisions made before any configuration. The platform baseline, data stores, Collabora deployment and routing, DNS and TLS, licensing and release ownership each affect the others, so settle them in this order.
OX App Suite v8 platform baseline
OX App Suite v8 is delivered as Helm charts that reference container images, so the Kubernetes cluster comes first. Plan for Helm 3.17.0 or newer and a Kubernetes version within the N-1 or N-2 range that OX supports. Istio is required, with support for the latest release plus two prior versions. Where Istio cannot be used, the basic ingress-nginx option applies. Confirm which routing option your chosen App Suite release documents before you design the Collabora hostnames.
Redis, MariaDB and persistent storage
OX App Suite v8 uses Redis 7.4.x for caching and session storage, deployed by default through the littlered operator, with unmanaged or custom Redis configurable. MariaDB with the InnoDB engine is the primary data store, on 10.6.x, 10.11.x, 11.4.x or 11.8.x, and Galera Cluster is supported. Persistent files need a distributed file system: NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Confirm these choices against the requirements page for your release.
Collabora deployment method and routing
Collabora Online can run from Docker images, system packages or Kubernetes, and the Helm chart supports Nginx, HAProxy and OpenShift Router ingress. Choose one deployment method and one ingress controller before you write the WOPI URL configuration. The chart disables autoscaling because scaling breaks collaborative editing, so replica counts are set by hand. Your load balancer must route by the WOPISrc parameter so every user editing a document reaches the same pod. Test this with two sessions on one document.
DNS and TLS for both hostnames
OX App Suite and Collabora Online each need their own hostname, and both must resolve to the ingress entry points your team operates. Plan certificates for both names, with a renewal process that a named team owns. Because the two services exchange WOPI requests, check that each side trusts the certificate the other presents. Ask your network team to confirm that DNS resolves correctly from inside the cluster as well as from user networks.
Collabora licensing decision
CODE, the free Collabora Online Development Edition, is suited to testing, home use or small teams, and Collabora does not recommend it for production. 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. The Enterprise plan covers 100 or more users and is quoted with volume discounts. Ask for a quote based on your exact user count and the support terms each plan includes.
Release line and cadence owner
Choose a Collabora Online release line before the first deployment. According to the Collabora 25.04 release notes, the 25.04 branch was first released on June 19, 2025, and was still receiving point releases, with 25.04.13 on September 21, 2026. Collabora Online 26.04 was announced on July 23, 2026, and adds an optional AI assistant that is off by default. Name one person who owns the update cadence, tracks point releases and schedules integration tests against each OX App Suite upgrade.
How the WOPI handshake moves a document between OX and Collabora
The WOPI handshake is the sequence that lets Collabora Online edit a file it does not store. In the WOPI model, the host application holds the document and decides who may open it. OX App Suite plays the host role here. When a user opens an office file, the host gives the editor a WOPISrc URL, which identifies the file and tells the editor where to call back, and an access token, which is a scoped credential for that user and that file. The browser then loads the editor frame from Collabora, so the user sees Collabora's interface inside OX. Your first task is to confirm, from the OX documentation for your release, exactly how the host passes these values to the browser and to Collabora.
Once the frame is loaded, Collabora works through the host's WOPI endpoints. It asks the host for file metadata, fetches the file contents, and later saves changes back through the host. Each call carries the access token, so the host can refuse requests that are expired or out of scope. The OX-side wopi-server is the component that brokers this exchange. Its exact role, the endpoints it exposes and the capability flags it reports to the editor must be taken from the OX documentation for the release you deploy. Do not assume that a flag or endpoint from another WOPI host behaves the same way in OX. Ask the OX team to show you the call sequence for one open, one edit and one save.
The handshake also constrains your network design. Collabora's backend must reach the host's WOPI endpoints using the address in WOPISrc, and the browser must reach Collabora. The Collabora Helm chart documentation says that load balancers must route by the WOPISrc parameter so that everyone editing one document reaches the same pod, and that horizontal autoscaling is disabled for this reason, so replica counts are set by hand. This means the ingress you choose, whether Nginx, HAProxy or the OpenShift Router, must preserve that parameter. Plan the public hostnames for both services now, because a mismatch between the address OX advertises and the address Collabora can resolve is a common cause of failed opens.
Test the handshake before users depend on it. Open the same document from two accounts and confirm that both sessions land on one Collabora pod and see each other's changes. Force an expired token during a long session and confirm how the editor reports the failure and whether unsaved work is recoverable. Check that a save failure at the host is surfaced to the user rather than silently dropped. Record the findings alongside the OX release and Collabora version you tested, because the OX endpoints and flags are release-specific and will need retesting on upgrade.
Configuration sequence for the OX and Collabora connection
This sequence takes the OX App Suite and Collabora Online connection from a confirmed integration path to a tested setup in which documents open, save and stay on one pod per file. Each step names the check that closes it, so the platform team can sign off before users are added. The order matters because routing and Redis decisions affect every later test.
Confirm the integration path for your target version
Start by reading the OX App Suite documentation for the exact v8 release you plan to run, and note the Collabora Online version and deployment method that the integration guidance supports. The platform owner and your OX contact should agree on this in writing, because version pairing decides which chart, configuration keys and capability flags apply. Check the OX requirements for the Helm 3.17.0 minimum and the supported Kubernetes versions, and record whether the cluster uses Istio or the basic ingress-nginx option. This step is done when the team holds a version matrix, approved by the owner of the OX platform, listing every component version.
Deploy Collabora Online from a supported method
Deploy Collabora Online with the official Helm chart or another method that Collabora documents for Kubernetes, into the namespace planned for the cluster. Set resource requests and limits from the chart README, which recommends requests of 4 cores and 6000 MiB of memory and limits of 8 cores and 8000 MiB per pod, then adjust them after load testing in your own environment. Choose an ingress controller that the chart supports (Nginx, HAProxy or OpenShift Router) and confirm it matches your cluster. The check is that the pods reach the ready state and that the Collabora service answers a basic request from inside the cluster.
Set replicas manually and route by WOPISrc
Set the Collabora replica count by hand in the values file, because the chart disables horizontal pod autoscaling. The README states that scaling breaks collaborative editing and copy and paste. Configure the load balancer or ingress so that requests are routed by the WOPISrc parameter, which keeps all users working on one document on the same pod. Ask your ingress team to confirm that routing by this parameter works in the controller version you run, and test the behavior rather than assuming default round-robin routing. The check is that two browser sessions opening the same file reach the same pod, while a different file can land on another pod.
Configure Redis for OX and check Collabora state
On the OX side, confirm the Redis instance used for caching and sessions. The OX v8 requirements specify Redis 7.4.x, deployed by default through the littlered operator, and unmanaged or custom Redis setups are configurable. Record the endpoint, persistence and access settings, and confirm that the OX middleware can reach it from its namespace. Then ask Collabora and your own testing whether Collabora keeps any state that needs a store of its own, and decide whether it needs a separate Redis instance or none. The step closes when the OX middleware logs show a clean Redis connection and the team has a written answer on Collabora state.
Set discovery, WOPI host URLs and capability flags
In the OX configuration, set the Collabora discovery URL and the WOPI host URL that Collabora calls back to. Use the exact keys and value formats from the OX documentation for your version, and use the public names your ingress publishes. Use internal service names only where both components can resolve them, and keep TLS on every URL. Enable only the capability flags that the documentation lists for the document types you plan to test, and leave optional features, such as the AI assistant added in Collabora Online 26.04, disabled until your governance approves them. The check is that the discovery request returns the expected editing capabilities.
Test one document type at a time
Test word processing, spreadsheet and presentation files in separate passes, starting with a small text document, then a spreadsheet, then a presentation, so that any failure points to one document type. For each type, open the file, edit it, save it, then reopen it in a second session and confirm that the save persisted. Confirm that the same pod serves all users editing one file by checking pod logs during a two-user session, then repeat the open and save test after a rolling restart of the Collabora pods. Record the OX, Collabora and chart versions with each result, and add users only after all three types pass.
Which OX and Collabora objects must line up
This table lists the identifiers, credentials, document formats, shared state and hostnames that OX App Suite and Collabora Online must agree on before a document opens in the browser. Read each row as one object seen from both products, with the last column naming what to verify. Where the supplied sources do not document a mapping, confirm it with Open-Xchange or Collabora before the build starts.
| Item | OX App Suite side | Collabora side | What to confirm |
|---|---|---|---|
| File identity | Each document is addressed by its file ID in OX storage, which the wopi-server uses to build the WOPISrc URL. | Collabora identifies the document from the WOPISrc parameter and requests file content from that URL. | File ID format, exact WOPISrc construction, and whether the ID changes on move or copy. |
| User identity and access token scope | The wopi-server issues an access token tied to the signed-in user and the requested permission. | Collabora sends the token back to the WOPI host on each file request and relies on it for access. | Token lifetime, permitted actions (view or edit), and behavior when the token expires mid-session. |
| Document types (Writer, Calc, Impress) | OX Documents sends office files to the wopi-server based on file extension and type. | Collabora edits Writer, Calc and Impress documents, built on LibreOffice technology. | Supported extension list for the exact OX and Collabora releases in use, including templates and legacy formats. |
| Redis session data | OX v8 uses Redis 7.4.x for caching and session storage, deployed by default through the littlered operator. | The supplied sources do not document any Redis use by Collabora Online. | Whether Collabora needs its own store, and whether OX Redis can be shared without key collisions. |
| Public hostnames | The App Suite hostname and the wopi-server callback URL must resolve and be reachable from Collabora. | Browsers load the editor from a public hostname served through Nginx, HAProxy or OpenShift Router ingress. | Whether browser-facing and WOPI callback hostnames differ, certificate trust between them, and DNS from each network zone. |
| Routing and replica affinity | OX sends each WOPISrc request to the Collabora endpoint configured for the deployment. | Collabora's Helm chart disables autoscaling and requires load balancers to route by WOPISrc. | Ingress rule that keeps all editors of one document on the same pod, and manual replica settings. |
| Release pairing | OX v8 runs on Kubernetes with Helm 3.17.0 or newer, and its LTS line is documented separately. | Collabora 26.04 was announced in July 2026, and the 25.04 branch still receives point releases. | Which Collabora branch OX supports with the chosen OX release and LTS line. |
| Capability flags | OX middleware configuration turns the Collabora integration on and sets the endpoint and related options. | Collabora's discovery endpoint advertises the actions and file types the server supports. | Exact flag names, where they are set, and which discovery values OX reads at startup. |
Why Collabora pods must be sized and routed for collaborative editing
Collabora pods cannot scale automatically, so the replica count is a fixed value that your team sets, and the routing layer must keep every session on a document on the same pod. The Collabora Online Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replicas are changed by hand. Capacity planning therefore happens before go-live, not through a metrics rule that reacts during peak hours. Ask for the replica count in each environment, the number of concurrent editing sessions you expect at peak, and the named person who changes the value during an incident. Record those answers in the written scope so the operations runbook reflects them.
The chart requires that load balancers route by the WOPISrc parameter, so all users editing one document reach the same pod. WOPISrc identifies the document that the WOPI host passes to Collabora, which means the path from OX App Suite through the wopi-server must carry it unchanged. Any layer that rewrites, drops or ignores that parameter, or that balances requests round robin, can split co-authors across pods. The typical symptoms are edits that seem to disappear for one user, or copy and paste that fails only for some sessions. Test this with two or more users on one document while traffic is spread across several pods.
The 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 values as the vendor's starting point, not as a sizing result for your organization. Multiply the per-pod requests by the planned replica count to find the capacity you must reserve, and confirm that your node pools can place those pods without leaving them unschedulable. This reserved capacity recurs in the infrastructure you pay for, so the quote should show the compute and memory it assumes. Confirm with Collabora whether these values hold for your document mix and file sizes.
OX App Suite v8 requires Istio where it can be used, with ingress-nginx as a basic option where Istio cannot be used. The Collabora chart README lists Nginx, HAProxy and OpenShift Router as supported ingress options and does not list Istio. Whether the OX Istio gateway or ingress path keeps WOPISrc-based routing intact is therefore a design item to test, not an assumption to carry into the build. Decide the ingress path early, then run a multi-pod editing test that covers TLS termination, request retries and gateway upgrades. Keep the results as acceptance evidence, and repeat the test after any change to the gateway or the Collabora replica count.
Securing the OX to Collabora connection
The editor connection is a trust relationship between two systems, so it needs controls at each layer: certificates, the WOPI host allow list, token behavior, network policy and the editor's patch cadence. The cards follow the request path from the browser to the editor. OX SSO through OpenID Connect or SAML is configured separately from the editor connection and needs its own review.
TLS on both hostnames and the path
Open-Xchange and Collabora Online each serve their own hostname, so each needs a valid certificate that clients and the other system trust. Check the certificate chain that the OX middleware presents to Collabora, and the reverse path Collabora uses to call back to the WOPI host, including any internal certificate authority. Confirm in the OX and Collabora documentation for your versions which connections must use HTTPS and which can stay inside the cluster, and record that decision before go-live.
Limit which WOPI hosts are trusted
Collabora only opens documents for WOPI hosts it has been configured to accept, so the allow list is a setting you own and must review. List the OX hostnames that may request editing sessions and nothing broader, including test or staging instances that should not reach production. Review the list after every change to OX ingress or DNS, because a stale entry can keep an old host authorized. Confirm the exact setting name and format in the Collabora documentation for the release you run.
Token lifetime and scope
WOPI access tokens grant a session on a document for a limited time, so their lifetime and scope determine how long a leaked token stays useful. Take the lifetime and scope behavior from the Open-Xchange documentation for your version, then confirm how Collabora validates tokens and whether the values can be shortened. Test expiry with an open editing session, a closed session and a token reused after it expires, and record the results before rollout.
Network policy between namespaces
Kubernetes network policies decide which pods can reach Collabora and which can call the OX middleware. Allow traffic only from the namespaces and pods that need it, and deny the rest by default. Collabora's Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing, so replica counts are set by hand, and the load balancer must route by the WOPISrc parameter so everyone editing one document reaches the same pod. Confirm that your ingress controller and network plugin enforce the policies you write.
Decide on the AI assistant
Collabora Online 26.04 adds an optional AI assistant across Writer, Calc and Impress. It is off by default, and the administrator chooses the AI provider and whether that provider is hosted externally or on infrastructure you run. Make this decision with your data protection and legal owners before rollout, because document content may leave your environment if an external provider is selected. Keep the assistant disabled until the decision and the provider's terms are written down and reviewed.
Patch cadence for point releases
Collabora publishes point releases within a branch, such as the 25.04 line, which was first released on June 19, 2025 and was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026. Set a patch window for the editor, apply point releases within it, and test document editing against OX after each one. Ask in writing how security fixes reach you, whether through the community channel or a commercial plan, and confirm how long the branch you run will receive them.
Common failures when OX App Suite cannot open documents in Collabora
This table lists five failure patterns seen when OX App Suite cannot open, save or keep editing documents in Collabora Online, with a likely cause and a check to run for each. The checks are starting points for diagnosis, not guaranteed fixes, so confirm each one in your own environment and logs. Begin with the first symptom you see, because a blank frame usually points to URL or trust problems before session or resource problems.
| Symptom | Likely cause | Check to run |
|---|---|---|
| Documents open with a blank frame | Wrong discovery or WOPI host URL in the OX configuration, or clients do not trust the Collabora certificate chain | Fetch the discovery document from a user network. Confirm both URLs match the public Collabora address and the certificate chain is trusted. |
| Saves fail or recent changes are lost | Access token or WOPISrc value does not match between the editing session and the save request | Compare the WOPISrc value in Collabora logs with the file identifier OX sends. Confirm token expiry settings are consistent across hosts. |
| Editing sessions break when users share a document | Load balancer does not route by WOPISrc, or horizontal autoscaling changes the pod count during editing | Confirm the ingress routes by the WOPISrc parameter so all editors reach one pod. Check that autoscaling is off and replicas are set manually. |
| Sessions are slow or stall under load | Pod requests set below the chart's recommended values (4 cores and 6000 MiB memory, per the Collabora Helm chart README) | Compare pod requests with the recommended 4 cores and 6000 MiB. Check limits against the recommended 8 cores and 8000 MiB for production. |
| Session errors that point to Redis | Redis version outside the 7.4.x line that OX App Suite v8 requires, or Redis unreachable from the OX or Collabora pods | Confirm the Redis version matches the OX App Suite v8 requirement of 7.4.x. Test network connectivity from both pod networks and review authentication and TLS settings. |
Questions buyers ask before connecting OX App Suite to Collabora
How much does connecting OX App Suite to Collabora Online cost?
The cost has two parts: Collabora licensing and the integration services. Collabora licenses per user. According to the Collabora Online pricing page, the Business plan lists at 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. The Enterprise plan, for 100 or more users, is quoted with volume discounts and adds integration support, customization services and roadmap input. The free CODE edition is not recommended for production. On the services side, DeployOpen's quote follows from the written scope, which covers configuration, routing, testing and support. Ask for licensing and services as separate lines, so you can see which costs recur each month and which are one-time. Also ask about the Kubernetes capacity Collabora pods will need in your infrastructure.
How long does an OX App Suite and Collabora integration take?
No fixed duration applies to every environment, so the timeline comes from the written scope. Four factors set most of it. The first is the number of document types you enable, such as text, spreadsheets and presentations, each with its own checks. The second is ingress complexity. OX App Suite v8 requires Istio, with a basic ingress-nginx option where Istio cannot be used, and routing Collabora through an existing gateway takes more verification than a new setup. The third is your current Istio version and how it is managed. The fourth is testing scope, including the number of user groups, the editing scenarios you need to prove and the release and change windows you must work within. Ask the provider to show which of these factors it assumed and what would change the schedule.
Can our internal platform team connect OX App Suite to Collabora without a partner?
Yes, if your team has Kubernetes skills and OX App Suite operations experience. The OX documentation for your target release is the reference for every setting, so confirm the version first. Expect to need Helm 3.17.0 or newer, the Redis 7.4.x setup that OX App Suite v8 uses for caching and sessions, and either Istio or the ingress-nginx option. The Collabora Online Helm chart README sets two rules your team must follow: horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, and the load balancer must route by the WOPISrc parameter. Many teams find the routing and testing work takes the most time. If your team lacks one of these skill sets, a partner can cover that part under a fixed-scope agreement.
What does our team need to provide before integration work starts?
Confirm these items before the work starts, because missing access often delays the schedule more than the technical work itself. You will need access to the Kubernetes cluster where OX App Suite and Collabora will run, with permissions to create the required objects in the target namespaces. You will need DNS names for the Collabora endpoint and the TLS certificates that cover them. Provide a test user set that includes people from each group who edit documents, so you can check permissions and editing behavior before rollout. Also provide your release calendar and change windows, including who approves production changes. Finally, name an owner for OX administration decisions, such as which document types users may open and which default editor applies. The written scope should list each of these as a client dependency.
Should we keep OX Documents, switch to Collabora, or run both?
The right choice depends on the document types your users need, the features each editor supports for those types, and how you want to pay for and support each one. OX Documents is part of OX App Suite for editing office files. Collabora Online is a browser-based office suite that connects to platforms through the WOPI protocol. Running both means users need a clear default and a clear rule for when to use each, and you will maintain two editing paths. Before deciding, test your most important files in both editors using your own documents. Confirm feature coverage with the OX documentation for your release and with Collabora's product documentation. A pilot group is a practical way to compare them before you commit to one approach.
Why does Collabora Online need the same pod for every editing session?
All users editing one document must reach the same Collabora pod, so your load balancer must route on the WOPISrc parameter. The Collabora Online Helm chart README explains that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so you set replica counts manually and plan capacity for peak use. Supported ingress options in the chart include Nginx, HAProxy and the OpenShift Router, so check how your Istio gateway or ingress-nginx setup applies this routing. The same README recommends production resource limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Test routing with two users editing the same file before you open the service broadly, and check that a pod restart does not drop active sessions without warning.
Does connecting Collabora change how we plan OX App Suite upgrades?
Yes, because each component follows its own support calendar, and both must stay compatible. The OX support commitment states that a standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months, and v8.47 (FCS 2026-03-18) is the current LTS. Collabora publishes Online releases on its own schedule, and the 25.04 branch was still receiving point releases in 2026. Plan one upgrade window that covers OX App Suite, Collabora, Redis, Istio and the Helm charts. After each upgrade, rerun the document editing tests from your pilot group. Ask your provider how it tracks both support calendars and what it checks before each change.
How DeployOpen scopes and delivers the OX and Collabora integration
DeployOpen scopes the OX App Suite and Collabora Online integration as a written, fixed-scope engagement covering the WOPI connection, Redis, capability flags and URL configuration. We build it inside your own infrastructure, test document editing end to end, and hand over documentation. Ongoing support and upgrades are available as a retainer.
How we scope
- The written scope names the OX App Suite v8 cluster, the Collabora Online deployment and the WOPI host configuration.
- We confirm prerequisites first, including the Helm 3.17.0 or newer requirement and the Kubernetes and Istio versions in use.
- The scope records which Collabora Online edition and support plan you choose, so licensing questions are settled before build.
How we build
- We configure Redis for OX App Suite using the 7.4.x line from the v8 requirements, then confirm the setup.
- Capability flags and public URLs are aligned on both sides, so browsers reach the WOPI endpoints and documents open.
- Collabora replicas are set manually, and the load balancer routes by WOPISrc so one document stays on one pod.
How we hand over
- Deliverables include the configured values, the Helm release settings and a record of every URL and capability flag.
- Test results cover opening, editing and saving documents from OX App Suite in Collabora Online, across the agreed browsers.
- Operating notes cover scaling limits, the Collabora update path and what to check after each OX or Collabora release.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing after handover.
- Retainer scope can cover Collabora Online version updates, OX App Suite release changes and integration regression checks.
- Changes to either side are retested against the documented configuration before they reach production.
