How Collabora Online editing connects to ownCloud Infinite Scale
If your team runs ownCloud Infinite Scale (oCIS) and wants browser-based document editing on servers you control, the integration runs over WOPI through the oCIS collaboration service. That service is the bridge between oCIS and a document server such as Collabora Online. It does not start by default in supervised mode, so you have to launch it yourself with ocis collaboration server. It listens on port 9300 by default. Treat that launch step as a deployment decision, not a footnote: it determines how the service is supervised, restarted and monitored alongside the rest of your oCIS services.
The collaboration service expects the target document server to be running before it starts, and it can be started several times, each instance carrying its own configuration for one web office server. Where you run Collabora Online, and how many instances you start, shapes the WOPI addresses oCIS hands to clients. Decide early whether each document server gets its own collaboration service instance, record the WOPI endpoints and ports in your configuration plan, and confirm the exact configuration keys against the version of oCIS you deploy, since the documentation is versioned and the current release line may differ from the one you test on.
DeployOpen plans, implements, hardens and supports this integration inside your own environment, including the start order, network paths between oCIS and Collabora Online, and the checks that prove editing works before go-live. The scope boundary is your infrastructure: DeployOpen does not operate your identity provider, storage backend or client devices unless that work is agreed in a written scope. Before the work starts, confirm which oCIS and Collabora Online versions you will run, who owns the service supervision for the collaboration process, and which team signs off on the WOPI configuration.
Prerequisites before connecting oCIS to Collabora
Connecting ownCloud Infinite Scale to Collabora Online touches versions, network paths, identity and storage at once. Settle these five decisions before any configuration, because each one changes how the collaboration service is started, addressed and tested.
Confirm the oCIS version
Pin one oCIS release before you plan the integration. The published releases you will see are v8.2.1 and v9.0.0-rc.1, and the second is a release candidate. Check the collaboration service documentation for the version you run, and confirm with your Collabora release which oCIS versions it has been tested against. Do not assume a Collabora branch works with every oCIS release.
A running Collabora Online server
The collaboration service needs the target document server running before it starts, so Collabora Online must be up and healthy first. Decide where it runs (Docker, system packages or Kubernetes), which Collabora release it uses, and whether one server or several will serve oCIS. Confirm the supported Collabora release with your oCIS version before installation.
Network paths and TLS for WOPI
Map every connection: browsers reach Collabora, Collabora reaches oCIS for WOPI callbacks, and oCIS reaches Collabora for discovery. Each address must resolve from the network that needs it, and TLS certificates must match the names you publish. Keep the collaboration service's default port 9300 in view when you write firewall and reverse proxy rules.
Identity provider choice
Choose between the embedded LibreGraph Connect identity provider and an external OpenID Connect provider such as Keycloak. The embedded option suits basic deployments with no external identity system. An external provider fits organizations that already run central sign-in, but it adds token configuration and a dependency that must stay available for editing sessions.
Storage backend selection
Select S3, NFS or PosixFS for file storage before go-live, because it determines how documents are read and written during co-editing. Confirm that the storage platform stays reachable from every oCIS instance that runs the collaboration service, and that its latency and locking behavior suit document saves. Changing backends later means planning a data move.
Separate service per document server
Each collaboration service instance is started with its own configuration for one web office server. Plan one instance per document server you intend to use, with a named configuration for each. Decide this before go-live, since mixing configurations or pointing two instances at one server complicates troubleshooting and rollback.
Configuring the collaboration service step by step
This sequence connects a running Collabora Online server to ownCloud Infinite Scale through its collaboration service, so that each web office server has its own service instance and a working test document opens in the browser. Each step ends with a check you can record before moving on.
Confirm the Collabora Online server is reachable
The infrastructure team confirms that the Collabora Online server is running and that the oCIS host can reach it over the network and ports you have chosen. Request the Collabora discovery endpoint from the oCIS host and confirm that it returns the WOPI discovery document. Because the collaboration service checks that the document server is running before it starts, this check must pass before you continue. Record the exact server URL, since you will reuse it in later steps.
Plan one collaboration service instance per office server
Decide how many web office servers will serve oCIS and assign each one its own collaboration service instance and configuration file. The oCIS documentation states that the service can be started several times, with its own configuration for each web office server. Write down the server address, the instance name and the configuration location for each one. Confirm with your oCIS version's documentation which configuration keys apply, because key names can change between releases. The output is a short table that the operator can check against the running services.
Set the WOPI app and public URLs
In each instance configuration, set the WOPI app URL to the Collabora Online server and set the public URL so that the WOPI addresses resolve to the oCIS side. Use the addresses that browsers and the Collabora server can both reach, and keep the protocol consistent across the chain. Check the collaboration service page of the ownCloud Infinite Scale documentation for the exact variable names in your version. The check is a configuration review in which each address resolves from the browser and from the document server, with no mixed HTTP and HTTPS paths.
Start the service and confirm port 9300
Start each instance with the command
ocis collaboration server, using that instance's configuration. The collaboration service does not start by default in supervised mode, so the command must be run explicitly, and it listens on port 9300 unless you change it. Confirm that the process stays up and that the log shows the service listening on the port assigned to that instance. If you run several instances on one host, each one needs its own port, so verify that no two instances share a port before you start the next one.Verify each instance answers on its port
From the oCIS host and from a client network segment, open a connection to port 9300 for each instance and confirm that it accepts the connection. Review the service logs for errors about the document server, WOPI discovery or certificate trust. If an instance fails, check that the Collabora server from the first step is still running, since the service will not start cleanly against a server that is down. The output is a log trail for each instance with no connection or discovery errors.
Open a test document in the browser
Sign in to the oCIS web interface as a test user, upload a small document in a format that Collabora Online supports, and open it from the file list. Confirm that the editor loads inside the browser, that the document displays its content, and that a change can be saved and reopened. Repeat the test for each web office server so that every instance is exercised at least once. A successful open and save on every instance is the completion check for this sequence, and any failure should be traced back to the step where the related configuration was set.
Running the collaboration service on single-node or Kubernetes oCIS
On a single host, oCIS runs as one binary of microservices, and the collaboration service is not started unless you start it. Your process supervisor needs its own unit for ocis collaboration server, separate from the unit that runs the main oCIS server. Because the service needs the target document server to be running before it starts, the collaboration unit should wait for Collabora to be reachable rather than assuming startup order.
- Separate unit: Define a second service unit that runs
ocis collaboration server, so a restart of the collaboration process does not require restarting the file services. - Ordering: Make the unit depend on the Collabora service and on network availability, then confirm the order with a reboot test.
- Restart policy: Set the supervisor to restart the process on failure, and check that a crash loop is visible in your logs and monitoring.
- Several web office servers: The service can be started more than once, each with its own configuration for one web office server. Give each instance its own configuration file and a port that does not clash with the default 9300.
- Addressing: Point each instance at the Collabora URL that the oCIS host can reach, and confirm that the WOPI address resolves to the same server from the browser's side.
Before go-live, confirm the unit starts after a host reboot, that port 9300 listens on the expected interface, and that the supervisor shows the service as running only after Collabora has answered.
On Kubernetes, the collaboration service runs as its own workload, and the orchestrator handles restarts. Restarts are not the hard part. The harder problem is startup order and addressing, because the service expects the document server to be up before it starts, and Kubernetes does not enforce that order between separate deployments on its own. Check the chart version you deploy against the oCIS release you run, and confirm how the chart exposes the collaboration service and its port in your chart version.
- Startup dependency: Use readiness and startup checks on the Collabora workload, and confirm how the oCIS chart behaves when Collabora is not yet reachable.
- Addressing: Address Collabora through a cluster Service name or an internal ingress host, and make sure the WOPI address that users see resolves to the same Collabora endpoint.
- Session affinity: Collabora's chart disables horizontal pod autoscaling and expects replicas to be set manually. Its load balancers must route by the
WOPISrcparameter, so all users editing one document reach the same pod. - Resources: The Collabora chart README gives a production reference of 8 CPU cores and 8000 MiB of memory per pod as limits, with requests of 4 cores and 6000 MiB. Treat these as starting values and confirm them against your sizing.
- Network policy: Allow traffic from the oCIS pods to Collabora on the port in use, and confirm that the policy does not block the return path.
Before go-live, confirm the pod reports ready only when it can reach Collabora, and that a document opened from one browser session stays on one Collabora pod for its whole editing session.
Whichever environment you choose, the same questions decide whether the integration works for users. Confirm each item in your own environment and record the answer with the configuration that produced it. The collaboration service only connects documents to editing when the Collabora server, the WOPI address and the oCIS side agree on the same endpoint and protocol.
- Collabora health: Confirm that the Collabora server answers its health endpoint and that it is running before the collaboration service starts.
- Reachability: Test from the oCIS host or pod to the Collabora URL, and from a user's browser to the WOPI address. Both paths must succeed.
- Protocol and TLS: Use the same protocol for the Collabora URL and for oCIS where your integration guidance requires it, and confirm the certificate chain is trusted by both sides.
- Port and listener: Confirm the collaboration service listens on the port you planned, which is 9300 by default, and that no other process uses it.
- Test documents: Open a Word, Excel and PowerPoint file from a test space, edit it with two users, and confirm that both sessions reach the same Collabora instance.
If any item fails, fix the startup order or the address first, because most failures here come from the collaboration service starting before its document server is ready.
How users, files and permissions map between oCIS and Collabora
This table compares each identifier or permission that crosses the boundary between Oracle-free oCIS storage and Collabora Online, and shows where the WOPI host decides what a user can do. Read each row as a question to answer for your version before go-live, because the exact mapping depends on your identity provider setup and the release you run.
| Mapping | What oCIS holds | What Collabora receives and how to confirm it |
|---|---|---|
| User identity | The user as defined by the embedded LibreGraph Connect identity provider or your external OpenID Connect provider, such as Keycloak | A WOPI request identifying the user for the session. Confirm in the oCIS and Collabora documentation for your version which claims or user fields are passed |
| Roles and group membership | Roles and group memberships assigned in oCIS, which decide who can reach a space | Access is enforced by oCIS before the file is handed over, so Collabora should only see authorized sessions. Confirm which roles gate editing in your setup |
| File reference | A file identified by its space and resource path inside the storage backend (S3, NFS or PosixFS) | A WOPI file ID that oCIS generates and maps back to the stored file. Confirm the ID format and how renames and moves are handled |
| Storage path | The physical location of the blob in the chosen backend, which Collabora should never address directly | No direct path access. Collabora works through the WOPI endpoints only, so storage paths stay private. Confirm this in your network tests |
| Edit or view permission | The share or role grant on the file, such as read-only or editable | The WOPI host sets whether the session can write. Confirm that read-only shares open in view mode in your version |
| WOPI source address | The address oCIS uses to reach Collabora and the address Collabora uses to reach oCIS | The WOPISrc parameter in each request, which load balancers must also use for routing. Confirm the URL format in the Collabora documentation |
| Session and lock state | Sharing or lock changes made in oCIS while a document is open | Collabora keeps its own session for co-editing. Confirm how revoked shares and lock conflicts are reflected during an active session |
Securing WOPI traffic between oCIS and Collabora
WOPI connects oCIS and Collabora Online in both directions, so each link needs its own controls. The cards below cover network restriction, transport encryption, certificate trust, group-based access and patching, and each one names what to verify in your environment before go-live.
Restrict WOPI requests by address
Limit which hosts can send WOPI requests to the Collabora server so that only your oCIS collaboration service can reach its editing endpoints. Nextcloud's administration manual recommends the same kind of allow list for its WOPI host, and the principle carries over to oCIS. Confirm that the addresses you allow match the outbound path oCIS uses in your network, including any NAT, proxy or load balancer, because a mismatch shows up as failed sessions rather than a clear error.
Use HTTPS for both URLs
Serve the oCIS collaboration endpoint and the Collabora Online URL over HTTPS, and keep the protocol consistent between the two sides. The Nextcloud administration manual makes the same point for its Collabora server URL, and it applies here as well. Check that the WOPI source URL oCIS sends and the public address users reach are both HTTPS, and that no redirect downgrades a request on the way.
Establish certificate trust between services
oCIS must trust the certificate that Collabora presents, and Collabora must trust the certificate oCIS presents when it calls back. Private certificate authorities are common in regulated networks, and a missing intermediate or an untrusted root is one of the most frequent causes of a collaboration service that starts but cannot open documents. Ask your team which CA issues each certificate, where the trust bundle lives on each host, and how renewal is tested before expiry.
Limit who can open and edit
Access control for documents sits in the host application, not in Collabora alone, so decide which groups may open the editor and which may edit rather than only view. Nextcloud Office exposes both settings, and the equivalent decision for an oCIS deployment is who holds edit rights on a space. Test with a user from each group to confirm that view-only users cannot save changes through the editor.
Patch from published advisories
Collabora publishes security advisories for Collabora Online, and its 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and updated the package signing keys for RPM and DEB users. Subscribe to the release notes, map each advisory to the branch you run, and schedule point releases on a fixed cycle. Verify that your package source still trusts the current signing keys before the next update window.
What to test before users open real documents
Start the collaboration service only after the Collabora document server is running and reachable, because the Infinite Scale collaboration service requires the target document server to be up before it starts. Run ocis collaboration server once per web office server, each with its own configuration, and confirm that each instance listens on port 9300 or on the port you set. Then test with throwaway documents in a non-production space: open, edit and save a Writer document, a Calc workbook and an Impress presentation, and reopen each one to confirm the saved changes persisted. Include the formats your users actually send, such as docx, xlsx and pptx, and compare the output against the original, because a file that opens but saves with lost formatting will cause problems later. Record which file types fail so you can decide whether to restrict them before rollout.
Check permissions with at least one account that has view-only access and one that can edit. The view-only user should open a document in read mode and should not be able to save changes or see an edit toolbar, and you should verify that the share permission in oCIS, not only the browser UI, is what enforces this. Also test a user with no access to the file, and a link shared outside your identity domain if you allow that. Then restart the Collabora server while a document is open in two sessions. Note how long editing takes to resume, whether unsaved edits survive, and what the user sees. Confirm the restart behavior with your own environment, because the reconnection path depends on your proxy and load balancer settings.
Finish with logging checks. Confirm that the oCIS collaboration service logs WOPI requests and errors to the location your operations team reads, and that the Collabora server logs show the same document sessions. Make sure that failed starts, a stopped document server and rejected WOPI calls each produce a visible entry, since these are the first signals an operator will need. Keep this test log with the configuration you tested so that any later Collabora or oCIS upgrade can be checked against the same cases.
Why the oCIS to Collabora connection fails and how to fix it
This table lists the failures teams most often hit when connecting ownCloud Infinite Scale to Collabora Online, with the likely cause and a general fix for each. Read it top to bottom during go-live checks, or jump to the symptom you are seeing.
| Failure | Likely cause | Fix in general terms |
|---|---|---|
| Editor does not open and the collaboration service is absent | The collaboration service was never started, because it does not start by default in supervised mode | Start it explicitly with the collaboration server command, then confirm the process is running before testing a document |
| Port 9300 unreachable or service fails to bind | Port 9300 is blocked by a host firewall or security group, or another process already uses it | Confirm the port is free on the host, open it only between the oCIS host and the users or proxy that need it, and change the listening configuration if a conflict is unavoidable |
| Service starts but documents do not load | Collabora Online was not running or not reachable when the collaboration service started | Start and verify the document server first, then start the collaboration service, because the service expects the target document server to be up |
| Editor loads from the wrong location | WOPI addresses in the collaboration configuration point at a wrong host, port or internal name that users cannot reach | Set the WOPI and public addresses to names that the browser and the Collabora server can both resolve, and test each address from a client network |
| Browser shows mixed content or certificate errors | oCIS, the reverse proxy and Collabora use different protocols, or the certificate does not match the host name in the URL | Use HTTPS consistently for the public and WOPI-facing addresses, issue certificates that match those names, and trust the internal certificate authority on every component that calls the other |
| Some users see the editor and others get access denied | Permission mismatches between oCIS spaces or shares and the rights the user holds in the storage or identity provider | Compare the user's space role and share permissions, confirm the identity provider claims oCIS expects, and test with one account per role |
| Edits do not save or open read-only unexpectedly | The WOPI host does not accept write requests from the editor, often from a proxy rule or an allow list that blocks the Collabora server's address | Review proxy rules for the WOPI endpoints and allow the Collabora server addresses you have confirmed with your vendor documentation |
Questions buyers ask before connecting oCIS to Collabora
What does it cost to connect oCIS to Collabora Online?
The cost is mostly the people and infrastructure needed to do the work, not a licence fee for the connection itself. The integration uses the WOPI protocol and the oCIS collaboration service, so the main cost components are the Collabora servers you run, the oCIS environment they connect to, and the labor to configure, test and document both. Effort rises with the number of document servers, the identity setup (embedded identity provider or an external OpenID Connect provider such as Keycloak), network paths and TLS, and how many users must edit at the same time. Ask any partner for a quote built from a written scope that names each of these items, and separate one-time work from recurring costs such as updates, monitoring and support. Any Collabora subscription cost is a separate line item, covered in the production licensing question below.
How long does an oCIS and Collabora integration take?
Duration depends on scope, and no fixed timeline applies to every environment. A single document server connected to an existing oCIS instance with working HTTPS and a reachable network path is a much smaller task than a multi-server setup with external identity, separate sizing for each document server, and a formal test plan. Time is also driven by how many users and document types you need to validate, and by whether your oCIS and Collabora servers already exist or must be built first. Ask for a timeline in the written scope, with each milestone tied to a deliverable such as a working WOPI connection, a file format test and a go-live check.
What does our team need to provide before the work starts?
Your team needs to provide access and decisions, not only hardware. Typical inputs are: a running oCIS environment or a plan to deploy one, the hostnames and TLS certificates you intend to use, the network rules between oCIS, Collabora and users, the identity provider and the user groups that may open or edit documents, and the storage backend in use (S3, NFS or PosixFS). You also need named owners for DNS, firewall changes, certificate renewal and the Collabora package or container lifecycle. Confirm these inputs with your own environment before scope is agreed, since missing answers on network and identity are the most common causes of delay.
Can our team connect oCIS to Collabora using only the official documentation?
A capable team can often follow the official oCIS collaboration service documentation and the Collabora documentation to make a first connection, especially in a lab. The documentation covers the key facts you need: the collaboration service must be started separately with the command ocis collaboration server, it listens on port 9300 by default, and the target document server must already be running before it starts. Where teams usually need help is in production details: running one collaboration service configuration per document server, matching WOPI addresses to the way your network routes traffic, TLS, access rules, testing with real file formats, and keeping the setup working through upgrades. Decide early which of these you will own internally.
Do we need a paid Collabora Online plan for production?
Collabora's pricing page sets the paid terms, and production use is where the choice matters. 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 is quoted for 100 or more users with volume discounts and adds integration support, customization services and roadmap input. The free CODE edition is a rolling release that Collabora describes as suited to testing, home use or small teams and not recommended for production. Before deciding, confirm with Collabora which terms apply to your user count, your support needs and your update policy, and compare that cost with the internal effort of tracking and applying updates yourself.
What breaks most often when oCIS and Collabora are connected?
The most common failures are configuration mismatches rather than product defects. Typical examples are a collaboration service started against a document server that is not yet running, a WOPI address that does not match the hostname or protocol the users reach, blocked port 9300 or document server traffic between hosts, mismatched TLS, and a second document server that shares a configuration with the first. Plan a verification step for each connection: confirm the service starts, confirm the document server responds, open and save a file from each user group, and test the formats your users rely on. Keep these checks in your runbook so the same tests run after every upgrade.
How do security and access controls apply to the integration?
Access is governed in two places: the oCIS side decides which files and users reach the editor, and the document server side decides who can open or edit through the WOPI session. Plan both together. Restrict which hosts may call the document server, use HTTPS for the document server URL and the oCIS endpoint, and limit editing rights to the groups that need them. Review the Collabora security advisories as part of patching, since they are published for Collabora Online and affect how you schedule updates. Confirm with your security team which controls your framework requires before the build starts, and record evidence of each control as it is put in place.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this integration, we start from your oCIS and Collabora topology, agree the work in writing, and deliver a tested, documented setup that your team can run after go-live.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists each oCIS collaboration service instance, the Collabora server it targets, and the WOPI addresses in use.
- We confirm the document server version, network paths, ports including 9300, and TLS arrangements with your team before any build.
How we build
- We configure one collaboration service per document server, each with its own configuration, and confirm the target server is running first.
- We set up start order and service management so the collaboration service launches reliably under your supervisor or orchestrator.
- We test document opening, editing and saving across representative files and user groups before sign-off.
How we hand over
- You receive configuration, network and port documentation, and a record of the tests run and their results.
- We document the startup sequence, the restart steps, and the checks your operators should run after an update.
- Knowledge transfer sessions cover day-to-day operation, so your team can troubleshoot the integration without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainers can cover reviewing oCIS and Collabora release changes before you apply them to your environment.
- Confirm response expectations, included upgrade work and out-of-scope items in the written retainer before signing.
