How Collabora Online connects to SharePoint Server for in-browser editing
If your estate runs on-premises SharePoint Server and you need browser editing and co-authoring on infrastructure you control, the binding is a WOPI host configuration: SharePoint acts as the WOPI host and a self-hosted Collabora Online server acts as the editor that SharePoint calls over the WOPI protocol. Collabora Online is integrated into existing platforms through WOPI, so the design questions are the same ones you would ask for any WOPI host: which server SharePoint trusts for discovery, how requests reach the editor, and which users can open or edit documents. The researched material for this page does not document a SharePoint-specific connector or the exact SharePoint Management Shell commands, so do not treat any command in an internal runbook as settled until it has been checked.
Before the build, confirm three things in writing with Collabora and Microsoft: which SharePoint Server version and cumulative update you run, whether the Collabora Online release you plan to deploy supports the WOPI binding you intend to use for that version, and which SharePoint-side commands register the editor and its file types. Also confirm the ports and hostnames Collabora's discovery endpoint must expose, and whether SharePoint needs to reach the editor directly or through a reverse proxy. Record each answer against the version it applies to, because these steps are version-specific and a mismatch usually shows up only when a user opens a file.
Plan the TLS and network path early, since it drives most of the testing. Use HTTPS on the Collabora server URL and make sure the certificate chain is trusted by every SharePoint front end, not just the one you test on. Decide whether to restrict WOPI requests to the editor's source addresses, as the Nextcloud administration manual recommends for its own WOPI setup, and check that load balancers and firewalls do not break the WOPI callbacks. Test with the existing libraries you already use, including previews, co-authoring with two users on one document, and documents in the formats your teams rely on, and treat any failure in that test as a blocker for go-live.
What the SharePoint farm and Collabora server need before binding
Binding SharePoint Server to Collabora Online is mostly a matter of having the right versions, names, certificates and network paths in place before any PowerShell runs. The cards below cover the items to confirm on both sides, so the WOPI binding can be tested once instead of debugged across several changes.
Supported SharePoint Server version
Confirm the SharePoint Server version and cumulative update level your farm runs, and check it against the WOPI hosting guidance for the Collabora release you plan to use. Record the build number of every front end, because a patch gap between servers can produce intermittent failures that look like network faults. Ask the Collabora integration team to confirm which SharePoint builds they have validated before you commit to a target.
Collabora Online release branch
Choose the Collabora Online branch before you install anything, using the release notes as the reference. The 25.04 branch was still receiving point releases in 2026, and 26.04 is the newer branch that adds an optional AI assistant that is off by default. Pin the exact point release in your change record so that later security updates are applied as deliberate upgrades.
Edition for production
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. A farm-facing editor needs a supported edition with a defined support path, so plan on the Business or Enterprise plan for production. The Business plan includes long term support, a service level agreement, signed security updates and customer portal access, so confirm those terms in writing before go-live.
DNS names and trusted TLS certificates
Assign fixed DNS names to the Collabora server and to the SharePoint web applications that will host WOPI traffic, and issue certificates that both sides trust. SharePoint must trust the certificate chain presented by Collabora, and the browser must trust the names users open. Use HTTPS on both ends, and confirm that internal certificate authorities are installed on every front end, since a missing root certificate is a common cause of binding failures.
Network paths between front ends and Collabora
Map the traffic flows before the change window: browsers reach the Collabora server on its public or internal HTTPS port, and each SharePoint front end must reach the Collabora discovery endpoint and the WOPI callback addresses. Check firewalls, reverse proxies and load balancers in both directions. If Collabora sits behind a load balancer, confirm that it routes by the WOPISrc parameter so that everyone editing one document reaches the same server.
Farm administrator account
Name one account with farm administrator rights to run the SharePoint Management Shell commands, and confirm that it can change the trusted WOPI settings on every server in the farm. Document who approves the change and who holds the credential afterward. Keep a separate operator account for day-to-day support so that routine activity does not run under the farm account.
Why WOPI discovery and callbacks decide who can open and edit
WOPI works as a negotiation between three parties: SharePoint (the WOPI host), the browser user, and Collabora Online (the editor). The first thing that has to succeed is discovery. Collabora Online publishes a discovery document at its own address that lists, for each file extension, which actions the editor supports, such as view, edit, preview or embedded view, and the URL template the host must use to launch each one. SharePoint reads that document and only offers an action for a file type when the editor advertises it. Before go-live, the team should fetch the discovery document from the SharePoint servers themselves, not from a workstation, and confirm that every extension in use in your libraries, including legacy Office formats and PDF, is listed with the actions you expect. A missing or unreachable discovery document produces a file that opens nowhere, which is often mistaken for a permissions problem.
Once a user opens a document, the host issues an access token for that session and passes it to the editor along with the WOPISrc value that identifies the file. The editor then calls back to the host to read the file contents (CheckFileInfo and GetFile), and to write changes (PutFile), while lock calls (Lock, Unlock, RefreshLock) govern whether one user or several can change the document at a time. Collabora Online's own co-authoring runs on top of these calls, so the lock behavior you see in the browser is the host's answer, not an independent Collabora decision. The access token is scoped to a session, so token lifetime, the proof key settings and the HTTPS callback path all affect whether a long editing session keeps working. Confirm the callback URL is reachable from the Collabora server and that the server certificate is trusted by it.
Because the host makes the permission decisions, the editing rights a user receives are whatever SharePoint's permission model says for that library, item and user. Read-only, edit and no-access outcomes can differ between a document library, a folder with broken inheritance, and a site with custom permission levels. Do not assume that a group with edit rights on one library behaves the same on another. For each library that will use Collabora Online, test with a reader, a contributor and a user with no access, and check open, edit, save, co-authoring with a second user, and what happens when a third user tries to take a lock. Record the results per library so that permission changes made later can be retested against a known baseline.
Configuring the binding in the order that avoids rework
This sequence confirms the Collabora server is reachable and correctly identified before any SharePoint setting changes, so each later step builds on a verified foundation. The result is a pilot library where view, edit and co-authoring have been tested in turn.
Confirm the Collabora server serves its discovery document
The Collabora server administrator confirms that the Collabora Online server answers over HTTPS on the hostname you plan to publish, and that its discovery document is served at the discovery path. Use a browser or a command-line client from a machine on the SharePoint network, not from the Collabora host itself, so the test reflects what SharePoint will see. Confirm the certificate is trusted by the SharePoint servers, not only by your workstation. Done means the discovery document loads without certificate warnings and lists the file extensions the server supports.
Confirm SharePoint can reach the discovery URL
The SharePoint administrator tests connectivity from each SharePoint front-end server to the Collabora discovery URL, including any proxy, firewall or DNS path those servers use. Check name resolution from the SharePoint hosts specifically, because a name that resolves on your workstation may not resolve on a server. Done means every SharePoint front end fetches the discovery document successfully over the same URL you will register, with no interception or certificate errors.
Record the WOPI host addresses to allow
The network team lists the outbound addresses that the Collabora server will use when it calls back to SharePoint to fetch and save files, and the inbound addresses that SharePoint front ends present to Collabora. Restrict WOPI traffic to those addresses at the firewall or reverse proxy, as the Nextcloud administration manual recommends for its own Collabora setup. Record the list in your change record with an owner and a review date. Done means the allowed list is written down, matches what the firewall rules enforce, and has been tested with one request from an address outside the list that is refused.
Apply the SharePoint WOPI binding with verified commands
The SharePoint administrator applies the WOPI binding in the SharePoint Management Shell, using the command set published for the SharePoint Server version in use. Do not copy command examples from older guides or from this page; open the vendor documentation for your exact build, check each parameter, and run the commands first in a non-production farm if one exists. Record the exact commands and the output of the status query before and after. Done means the binding reports the Collabora discovery endpoint as active and the farm configuration matches the recorded change.
Map file extensions to the editor actions
The SharePoint administrator maps each file extension that the pilot will use to the view and edit actions advertised in the discovery document, leaving unused extensions unmapped. Start with the Office formats the business needs, such as docx, xlsx and pptx, and confirm that PDF and other formats behave as intended. Keep macro-enabled and legacy formats out of the pilot unless they are required and reviewed. Done means a list of mapped extensions exists, the discovery document confirms each action, and any unmapped extension opens in its default handler.
Test view-only access on a pilot library
The SharePoint administrator creates a pilot document library with a small set of test files and a pilot group with read-only rights. A tester opens each file type in the browser and confirms the document loads in the Collabora editor in view mode, with the expected title, permissions and no unexpected prompts. Check that the browser console and the Collabora server logs show no WOPI errors. Done means every test file opens read-only for the pilot group and the logs are clean before any edit right is granted.
Test edit and co-authoring before wider rollout
After view access passes, the administrator grants edit rights to a pilot group and two or more testers open the same document at the same time. Each tester makes changes, saves, and confirms that the other sees updates and that no changes are lost or overwritten silently. Check the save path back to SharePoint for each file type, including version history. Done means edits save to the library, co-authoring results match the test script, and the findings, including any file that failed, are recorded before the pilot is widened.
Which SharePoint objects map to which WOPI and Collabora values
This table pairs each SharePoint object the integration touches with the WOPI or Collabora value it becomes, who owns that value, and the test that shows the mapping works. Read it as a checklist: confirm each row in a pilot library before widening access. The main takeaway is that the document identifier, the user identity and the permission flags must agree across both systems, or editing will fail or expose the wrong file.
| SharePoint object | WOPI or Collabora value | Owner | Test that proves the mapping |
|---|---|---|---|
| Document identifier | WOPISrc parameter carrying the file URL that Collabora Online requests from the host | Both | Open a pilot file from the library and confirm the Collabora session loads the same file and version shown in SharePoint |
| User identity | User ID and display name in the WOPI access token issued by SharePoint Server | SharePoint admin | Sign in as two test accounts and confirm each session shows the correct name in document history or comments |
| Read or edit permission | Permission flags in CheckFileInfo such as read-only and user can write | SharePoint admin | Use a view-only account and verify that typing, saving and paste are blocked in the editor |
| File formats | Supported types such as docx, xlsx, pptx, PDF, RTF, CSV and Visio, checked against the Collabora file type list | Collabora admin | Open one sample file per format in the pilot library and record any that fail to load or save |
| Version and save state | Version identifier and save or PutFile behavior returned to SharePoint after each edit | Both | Edit a file, save, then confirm SharePoint creates the expected new version and keeps the prior one |
| Lock state | Lock identifier and lock or unlock calls between the editor and SharePoint | SharePoint admin | Open a file in one session and confirm a second user sees it as locked and cannot overwrite it |
| Co-authoring state | Concurrent session handling on the same WOPISrc, routed to one Collabora node | Collabora admin | Have two users edit the same file and confirm both changes persist after both sessions close |
Security controls for the SharePoint to Collabora link
The link between SharePoint Server and Collabora Online carries document content, user identity and edit rights, so each control below narrows a different part of that path. Together they cover who can reach the WOPI endpoint, how traffic is protected, who may edit, and how the editor stays patched.
Restrict WOPI requests by address
Limit which hosts can call the Collabora Online server so that only the SharePoint servers that broker WOPI traffic can reach it. The Nextcloud administration manual recommends this pattern for its own Collabora link, so use it as a comparison point. For SharePoint, confirm with your server team whether the WOPI host and Collabora server support an address allow list in your version, and if not, enforce the same limit at the firewall or reverse proxy.
Use HTTPS on both sides
Serve the SharePoint farm and the Collabora Online server over HTTPS, and make the protocol in the Collabora server URL match the protocol SharePoint uses. A mismatch causes blocked content or failed WOPI calls and often leads teams to weaken settings to make the link work. Check certificate chains and hostnames from the SharePoint servers themselves, not from a workstation.
Separate view and edit rights by group
Decide which SharePoint groups may open documents in the browser editor and which may edit them, rather than granting both to every library member. Map these groups to the document libraries that hold sensitive content, and test with a read-only account before go-live. Confirm with your SharePoint administrator how the WOPI permissions returned for each user are enforced in your farm version.
Track Collabora security advisories
Subscribe to Collabora's release notes and advisories and map each one to the Collabora Online version in your estate. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, which shows that fixes arrive in point releases on a branch you may already run. Record the advisory, the fixed version and the date you applied it.
Keep package signing keys current
If you install Collabora Online from RPM or DEB packages, the 25.04 release notes record that package signing keys were updated for those users. Import the current keys from the vendor, and make the repository configuration fail on unsigned or wrongly signed packages. Confirm the key fingerprints against Collabora's published instructions before rotating them in your configuration management.
Single server or Kubernetes: how the routing choice changes the binding
A single Collabora Online server is the simplest binding. SharePoint Server calls one discovery endpoint on one host, and every editing session lands on that same server, so there is no routing decision to make. You can install it from system packages or run the free CODE Docker image, which is published as collabora/code for x86-64, ppc64 and arm64. CODE is described by Collabora as suited to testing, home use or small teams and not recommended for production, so a production single server should be a supported Collabora Online deployment rather than CODE.
- Fewer moving parts: The WOPI host URL, the TLS certificate and the allowed SharePoint Server addresses all point at one name, which makes troubleshooting shorter.
- Capacity ceiling: All concurrent editing sessions share one host's CPU and memory, so the number of simultaneous editors you can support is set by that host, not by a cluster.
- Maintenance window: Patching or restarting the server interrupts every open editing session, so plan downtime with the document owners.
- Packaging choice: Package-based installs and Docker containers both work, but the team that will apply updates and signing-key changes must know which method was used.
- Recovery path: Recovery depends on reinstalling or restoring one host, which is quick to describe but must be rehearsed.
Before committing to this model, confirm with your own testing that one host handles the number of concurrent editors your libraries will generate. Check the firewall path from SharePoint Server to the Collabora host on the ports you configure.
On Kubernetes, the official Collabora Online Helm chart changes the binding in two ways. First, horizontal pod autoscaling is disabled, because the chart documentation states that scaling breaks collaborative editing and copy and paste. Replica counts are therefore set manually in your values, and you must change them deliberately as load grows. Second, the load balancer must route by the WOPISrc parameter, so every user editing the same document reaches the same pod. Without that routing, co-authors can land on different pods and lose the shared session. The chart supports Nginx, HAProxy and OpenShift Router ingress, and you should confirm the exact routing configuration for your chosen ingress with the chart README.
- Manual replicas: Set the replica count in your Helm values and record who owns changes to it, since autoscaling will not adjust it.
- WOPISrc affinity: Configure the ingress so requests for the same
WOPISrcvalue are sent to the same pod, and test this with two browsers on one document. - Recommended production limits: The chart recommends limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. These are starting values from the chart, not a sizing result.
- Sizing by test: Real concurrency depends on document types, edit patterns and file sizes, so measure concurrent sessions with representative libraries before setting replica counts.
- Ingress and TLS: The SharePoint Server side still needs a trusted HTTPS endpoint for the Collabora URL, and certificate handling changes with the ingress you choose.
Check that your ingress controller's affinity behavior is tested under a pod restart, because a restart that moves sessions is the failure most likely to surface only in production.
Failures that appear during SharePoint binding and how to fix them
This table pairs each common failure during the SharePoint Server to Collabora Online binding with its likely cause, a check you can run and the fix. Work through the rows in order, since discovery reachability and certificate trust must pass before editing behavior can be judged. Use it as a first-line checklist, then follow the troubleshooting topic for deeper diagnosis.
| Failure | Likely cause | Check to run | Fix |
|---|---|---|---|
| Editor does not load because discovery URL is unreachable from SharePoint | The discovery URL resolves or routes differently from the SharePoint servers than from user browsers, or a firewall blocks the path | Request the discovery URL from each SharePoint farm server, not from a workstation, and confirm the response is returned | Correct DNS, routing or firewall rules between the farm and the Collabora server, then re-run the binding commands |
| Browser shows a certificate error or the farm rejects the Collabora server | The certificate chain is incomplete or issued by a CA the farm servers do not trust | Inspect the full chain presented on the discovery URL and confirm each farm server trusts the root and intermediates | Install the missing intermediate certificates or add the internal CA to the farm trust store, then restart the affected services |
| Mixed content or refused connections after the binding | The discovery URL uses HTTP while SharePoint or the browser is served over HTTPS, or the reverse | Compare the scheme and port in the discovery URL with the scheme users see in the address bar | Use HTTPS end to end for the Collabora server URL and align the protocol in the SharePoint binding configuration |
| Documents open read-only unexpectedly | The file lock or permission model does not allow edit for that user, or the library or file type is set to view mode | Open the same file as a user with edit rights and check the file's checked-out state and library settings | Review SharePoint permissions and library policies, then confirm the editing action is enabled for the file type |
| Co-authors land on different editing sessions | The load balancer does not route by the WOPISrc parameter, so requests for one document reach different Collabora pods | Send two requests with the same WOPISrc through the load balancer and confirm they reach the same backend | Configure WOPISrc-aware routing as described in the scaling and sizing topic, and keep replica counts fixed as the Helm chart documents |
| Files of certain types do not open in the editor | The file extension is not mapped in the discovery response, or the format is outside what the editor supports | Compare the file extension with the list in the discovery response and test a sample file in the editor directly | Confirm supported formats for your Collabora version, enable the mapping, and test representative files before rollout |
Questions buyers ask before binding SharePoint to Collabora Online
What drives the cost and effort of binding SharePoint Server to Collabora Online?
The main drivers are the size of the SharePoint farm, the number of document libraries and content types that need editing, the amount of certificate and network work, and the depth of testing. A farm with one web application and a few libraries takes far less effort than a multi-farm estate with many site collections, custom permissions and strict change control. Costs have two parts: the internal time your SharePoint and network staff spend on access, certificates and approvals, and the external effort for planning, configuration, testing and documentation. Ask any partner for a quote built from a written scope that lists farms, libraries, file types, certificate sources, network paths and test cases. The Collabora server itself is a separate cost, covered in the licensing question.
Can our own team bind SharePoint Server to Collabora Online without outside help?
A capable internal team can do it if it has SharePoint farm administrators who can run the SharePoint Management Shell, a Collabora Online server administrator, and someone who owns TLS certificates and firewall changes. Before starting, confirm the exact commands, parameters and supported versions for your SharePoint release and your Collabora Online release, because the binding steps are version specific and should not be taken from memory or from older guides. Plan a test farm or a test library first, record each change, and agree a rollback path. Teams that lack one of these skills, or that must prove the setup to an auditor, often bring in a partner for the planning and verification steps.
How long does the binding take to complete?
The duration depends on the scope written into the plan, not on a fixed number of days. The largest variables are how many farms and libraries are in scope, how long certificate issuance and firewall approvals take in your organization, and how much co-authoring and file format testing you require before users see the editor. A good plan separates the work into a test binding, a pilot with named libraries and a production rollout, and sets a checkpoint after each one. Ask for the timeline as a written schedule with dependencies on your change windows and on people who must approve access. Any duration you are given should be traceable to that scope.
What do we need to provide for the SharePoint and Collabora binding?
You will need to provide access that is enough to run the work, and you will need to decide several things early. The usual inputs are:
- Administrative access to the SharePoint farm, including the account that can run the SharePoint Management Shell
- Access to the Collabora Online server, its configuration and its logs
- Test document libraries with representative Word, Excel and PowerPoint files, and named testers
- TLS certificates for the Collabora server and the names that users will open it under
- Network changes between SharePoint servers, users and the Collabora server, including the ports agreed for WOPI traffic
- Named approvers for change windows and for the security review of the WOPI allow list
Confirm each item with your security and network teams before the work is scoped.
How does Collabora licensing apply to a self-hosted SharePoint binding?
Collabora Online is licensed separately from SharePoint, and the cost depends on how many users you need to support and whether you want a subscription. The Collabora Online pricing page lists the Business plan at 3 euros per user per month for up to 99 users, and that plan 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 by Collabora, so confirm which edition fits your environment before you bind it to a live farm. Recurring subscription fees apply per user for as long as you keep the plan, and the binding work itself is typically a one-time cost.
Can DeployOpen support the SharePoint and Collabora binding after go-live?
Yes, ongoing support is available as a retainer after the initial work is delivered. A retainer can cover monitoring of the Collabora server, reviewing security advisories and applying patches within your change process, checking the binding after SharePoint or Collabora updates, and handling issues that come up in daily use. Because the binding depends on version-specific commands and on your certificates and network paths, ask for the support scope in writing, including how changes are tested before they reach production and who you contact out of hours. Support terms are agreed in the written scope, so compare them with your internal staffing before you decide.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including on-premises SharePoint Server and Collabora Online. For this binding, the work starts with your farm topology, your library and permission model, and the network path between SharePoint and the Collabora server, before any command is run.
How we scope
- Engagements are fixed-scope, with the written scope covering servers, farms, libraries and file types in the binding.
- We confirm which SharePoint servers, web applications and document libraries will open files through the WOPI binding.
- We agree the Collabora Online server URL, ports, TLS approach and the users or groups allowed to edit before work starts.
How we build
- We register the Collabora discovery URL with SharePoint using the SharePoint Management Shell in a documented, repeatable sequence.
- We configure firewall rules and TLS so SharePoint can reach the Collabora server and the browser can reach both over HTTPS.
- We test previews, in-browser editing and co-authoring against your existing libraries, including the file formats you rely on.
How we hand over
- You receive documentation of the commands run, the ports and certificates in use, and the configuration values for each farm.
- We provide a test script and a checklist so your team can repeat the verification after changes or patches.
- Knowledge transfer covers how to remove or change the WOPI binding, which is the rollback path your operators need.
How we support
- Ongoing support, Collabora Online upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover reviewing Collabora Online security advisories and planning how each update reaches the SharePoint binding.
- Ask any provider to confirm in writing which SharePoint and Collabora versions their binding has been tested against.
