Collabora Online and Kolab integration: what Kolab Now provides and what self-hosting adds
A Kolab team that wants documents editable in the browser without leaving infrastructure it controls starts from a useful fact: Collabora Online is an integrated component of Kolab Now, the Swiss-hosted Kolab email and groupware service, and Kolab chose Collabora to offer a FOSS collaboration stack that can be completely self-hosted. Collabora Online is a browser-based office suite built on LibreOffice technology, and it reaches host platforms through the WOPI protocol, so the editor is a separate service that a groupware platform calls when a user opens a document. That separation is what makes a self-hosted version possible, but it also means the Kolab side and the Collabora side each need their own configuration, certificates and network paths.
Before any build work starts, confirm the exact Kolab connector and configuration steps with Kolab and against the Collabora partner page for Kolab. The partner page establishes the relationship but does not, in the material available to us, give the settings a self-hosted administrator needs. Ask Kolab which components of Kolab Now's editing feature are open for self-hosting, which Kolab release and Collabora release they were tested against, and how document storage, user identity and sharing permissions are passed from Kolab to the editor. Those answers decide whether the work is a configuration exercise or a custom integration, and that decision drives the scope you agree in writing.
Self-hosting adds responsibilities that Kolab Now carries for its customers. Your team will own the Collabora server, its TLS certificates, the allow list of WOPI hosts, updates and monitoring, and the network path between users, Kolab and the editor. Plan for the WOPI traffic to reach the Collabora server from the Kolab side and for browsers to reach it directly. Document these ownership lines in the design before go-live, so that when a user reports a failed open or a save error, the team knows whether the fault sits in Kolab, in the editor or in the network between them.
Prerequisites for a Collabora Online and Kolab integration
Most delays in this integration come from items settled before setup starts, not from the editor itself. The cards below cover the decisions, network paths and ownership a team should settle first. No Kolab or Collabora version numbers are given here, so confirm compatible versions with both vendors before you commit to a design.
Confirmed Kolab version and model
Confirm with the Kolab vendor which Kolab release and deployment model you run, whether that is Kolab Now or a fully self-hosted installation. The Collabora Online connection, the web front end settings and the supported way to reach the editor depend on that answer, so write the version down before reading any configuration guide. Ask the vendor whether the Collabora integration is supported on your exact release.
Reachable Collabora Online server
Place a Collabora Online server where the Kolab web front end can reach it over the network, and confirm the Kolab web front end can reach the Collabora server's discovery and WOPI endpoints. Decide whether the server runs from a Linux package, Docker or Kubernetes, since that choice affects how you test reachability and how you patch it later. Test from the web front end host itself, not from your workstation.
HTTPS with valid certificates
Issue valid TLS certificates for the Kolab web front end and for the Collabora Online server, and make sure each side trusts the certificate presented by the other. Browsers load the editor from Collabora, so an untrusted certificate there breaks editing for every user even when the server side looks healthy. Confirm the protocol you use for the Collabora server URL matches the protocol of the Kolab installation, and prefer HTTPS on both.
DNS names for both services
Assign stable fully qualified names to the Kolab web front end and the Collabora Online server, and create the matching records in your internal or public DNS zones. Certificates must match these names, and the editor URLs that Kolab hands to browsers depend on them. Changing a name after go-live means reissuing certificates and reconfiguring both sides, so settle the naming scheme early.
Firewall and routing rules
Document every flow the integration needs: browsers to the Collabora Online server, the Kolab web front end to the Collabora server, and the Collabora server back to the Kolab web front end for WOPI requests. Restrict WOPI traffic to the Collabora servers' addresses where your network allows it, as Nextcloud's guidance does for its own WOPI host. Ask your network team to confirm any proxy or load balancer in between preserves the requests unchanged.
Named owner for the Collabora lifecycle
Assign one team to own the Collabora Online server after go-live, covering version selection, security updates, certificate renewal, backups of its configuration and monitoring. Decide whether you use the free CODE edition, which the vendor describes as not recommended for production, or a supported subscription, and record who approves that choice. Without a named owner, the editor often drifts behind the Kolab release it serves.
Kolab Now or a fully self-hosted Kolab: who runs which part
Collabora Online is an integrated component of Kolab Now, the Swiss-hosted Kolab email and groupware service, as described on the Collabora partner page for Kolab. The provider operates the groupware platform and the Collabora servers behind the editor, so your work shifts from running infrastructure to confirming what the service covers and where the data sits. You do not patch the Collabora server, size its pods or manage its certificates, so your questions focus on scope and evidence.
- Provider runs: the groupware platform, the Collabora Online servers and the connection between them.
- You own: user lifecycle in any directory you connect, sharing policy, and which groups may open documents for editing.
- Confirm in writing: whether document editing is included in your plan, the support scope for editing faults, the update cadence for Collabora Online, and the country or data center where documents and metadata are stored.
- For the Collabora server: you have no direct access to its configuration, so ask how security advisories are applied and how sessions are routed so all editors of one document reach the same server.
Check these items against the written service description before you rely on in-browser editing for regulated documents, and attach the answers to the contract.
In a fully self-hosted Kolab deployment, your organization or a team you appoint runs every component, including the Collabora Online server, inside infrastructure you control. The partner page describes Kolab's choice of Collabora to offer a FOSS collaboration stack that can be completely self-hosted, which is what makes this model possible. Availability, sizing, TLS, backups and updates for each part become your responsibility, and the integration becomes a configuration and operations task.
- You run: the Kolab servers, the Collabora Online server or cluster, the reverse proxy and the certificates between them.
- Sizing and routing: size Collabora for concurrent editing. The Helm chart README says horizontal pod autoscaling is disabled because scaling breaks collaborative editing, so replicas are set manually and load balancers must route by WOPISrc.
- Updates: Collabora describes its free CODE edition as not recommended for production, so production servers need a supported release channel. The pricing page lists a Business plan with long term support, a service level agreement and signed security updates, which is a useful baseline when you ask any supplier what they will provide.
- Confirm in writing: the Kolab and Collabora versions you will run, who receives security advisories, and who answers when an editing session fails.
Before go-live, verify that opening and co-editing works for every document type your staff use, over the same network path your users take.
Some organizations keep Kolab and Collabora Online inside their own accounts or data centers but hand day-to-day operations to an outside team. The servers remain under your control, while the operator carries out installation, monitoring, patching and incident response within a written scope. This model can suit teams without staff for out-of-hours response, but the contract must name exactly which systems and tasks are covered.
- Operator runs: the tasks named in the written scope, such as installation, monitoring, updates and documentation.
- You own: the hosting, the accounts and keys, data classification, and decisions on which features are enabled.
- Confirm in writing: the systems in scope, response expectations for editing outages, maintenance windows, and how the operator stores and rotates credentials and logs.
- For the Collabora server: access through administrative consoles and orchestration tools should be granted per person and logged, and the WOPI allow list must be updated whenever the Kolab or other WOPI host addresses change.
Ask for the access model and escalation path in writing, then rehearse one editing incident with both teams before relying on the arrangement.
Setting up Collabora Online for Kolab, in order
This sequence takes a Kolab deployment from an agreed integration method to a Collabora Online server that opens and saves documents from Kolab in the browser. Each step closes with a check you can run before moving on, so problems surface while the scope is still small.
Confirm the integration method with Kolab
Before you install anything, confirm with Kolab which integration path applies to your deployment: the integration built into Kolab Now, or a configuration for a fully self-hosted Kolab installation. Collabora's partner page describes Kolab as an integration partner, but the exact configuration steps, supported versions and required settings for your Kolab release should come from Kolab in writing. Record the agreed method, the Kolab version and the names of the people who will own each side. You are done when this decision is written down and the Kolab contact has confirmed it.
Deploy the Collabora Online server
Install Collabora Online on servers or a cluster you control, using a method from Collabora's documentation: Docker, system packages or Kubernetes. Use the production edition for anything users rely on, since the free CODE edition is positioned for testing and small teams rather than production. For Kubernetes, follow the official Helm chart, which recommends production resource limits of 8 CPU cores and 8000 MiB of memory per pod with requests of 4 cores and 6000 MiB, and which leaves horizontal autoscaling off. Check that the server starts and that its local health endpoint responds before continuing.
Place the server behind TLS and a reverse proxy
Publish the Collabora server under a dedicated hostname with a valid certificate, and terminate TLS at a reverse proxy such as Nginx, HAProxy or your existing ingress. The Collabora server URL should use the same protocol as the Kolab side, and HTTPS is the expected choice for production. If you run more than one Collabora pod, configure the load balancer to route by the WOPISrc parameter so that every user editing a document reaches the same pod. You are done when the hostname loads over HTTPS from a client network with a trusted certificate chain.
Point Kolab at the Collabora discovery endpoint
Using the configuration method agreed in step one, set the Collabora server URL on the Kolab side so Kolab reads the WOPI discovery information that the Collabora server publishes. Confirm the exact setting name and location in the Kolab documentation for your release, because the names differ between deployments. Make sure the Kolab server can reach the Collabora hostname on its public or internal address, and that the certificate it presents is trusted by Kolab. You are done when a request from the Kolab server to the discovery endpoint returns the list of supported file types and the editor opens a test document.
Restrict WOPI traffic to known server addresses
Limit which systems can send WOPI requests to the Collabora server. The Nextcloud administration manual recommends the same approach of restricting WOPI requests to the IP addresses of the Collabora servers, and the same principle applies to a Kolab deployment. Build the allow list from the addresses of your Kolab servers and any proxies in between, and confirm with Kolab which addresses its integration calls from. Test one allowed and one disallowed source. You are done when the allowed source opens documents and the disallowed source is refused, and the allow list is saved in your configuration record.
Run an end-to-end document test
Test the full path with a set of representative files before opening the integration to users. Open a document in each format your users work with, including Microsoft formats such as docx, xlsx and pptx alongside OpenDocument files, and check that the editor loads, text and layout display correctly, and changes save back to Kolab. Test a second user editing the same file to confirm co-editing reaches the same server. Also confirm the editing permissions match what Kolab grants for view and edit. You are done when every test file opens, saves and reopens without error, and the results are recorded for your go-live sign-off.
How Kolab users, groups and documents map to Collabora permissions
This table compares how identity, group membership, file ownership, access tokens and file formats are handled on the Kolab side and on the Collabora Online side. Read each row as a question to answer before rollout, and note the owner who decides it. The main takeaway is that Collabora enforces what the WOPI host tells it, so the Kolab-specific mapping must be confirmed with Kolab and tested in your own environment.
| Item | Kolab side | Collabora side | Decision owner |
|---|---|---|---|
| User identity | Accounts from the Kolab directory or identity source, confirm which attributes the file and editing service receives | Collabora sees only the user identity and display name passed by the WOPI host in each session | Identity or directory team with the Kolab administrator |
| Group membership for editing | Confirm whether Kolab groups can restrict who opens the editor and who may edit, as Nextcloud allows by group | Collabora applies the view or edit permission the WOPI host grants per session, it does not hold its own group list | Groupware administrator and information security owner |
| File ownership and sharing | Confirm how Kolab storage records owners and share links for documents opened in the editor | Collabora does not decide ownership; it follows the file permissions and sharing state the host reports | Groupware administrator with document owners |
| Document access tokens | Confirm how the Kolab integration issues the WOPI access token and how long it stays valid | Collabora uses the token to authorize each request, so token lifetime and transport affect exposure | Security engineering with the Kolab integration team |
| WOPI host restriction | Confirm which network paths between Kolab and Collabora are permitted, following the Nextcloud pattern of allowing only the Collabora server addresses | Collabora accepts WOPI requests from hosts on its allow list, so the list must match the Kolab host addresses | Network security team |
| File formats in scope | Confirm which Office and OpenDocument types users can create and open from Kolab storage | Collabora supports docx, xlsx, pptx, ODF, PDF, RTF, CSV and Visio files according to its product page; test each format used | Records or business owner with the editing team |
Security controls for Collabora Online in a Kolab deployment
Collabora Online sits between the groupware user and the document store, so its exposure depends on which hosts can call it, how traffic is protected, and how quickly its packages are patched. The controls below cover the connection itself, the people who can reach the editor, the logs you need, and the release decisions that change what the editor can do.
Restrict WOPI requests to known addresses
The WOPI host must be told which servers may reach the Collabora server, and the Collabora server should only accept WOPI calls from the host addresses you expect. In a Kolab deployment, confirm which component performs the file calls for your setup (the groupware front end, a file or storage layer, or both), then list those addresses explicitly. Test that a request from an unlisted address is refused before you rely on the restriction.
Use HTTPS on both ends
Use the same protocol for the host and the Collabora server URL, and prefer HTTPS for both. A mismatch between the two causes connection failures that teams often work around by weakening settings, so fix the scheme in the configuration rather than downgrading the host. Confirm that certificates are valid for the names users and the host actually use.
Keep on a patched release line
Track Collabora's security advisories and run a release line that still receives fixes. The 25.04 branch shows why this matters: release 25.04.7.5, dated January 29, 2026, fixed CVE-2026-23623, and the same release notes record updated package signing keys for RPM and DEB users. Verify package signatures during each update and assign an owner for watching advisories.
Limit who can open and edit
Nextcloud Office lets administrators limit which groups can use the editor and which groups can edit rather than only view. Where Kolab-backed files are opened through a host that supports group restrictions, map those groups to your directory and grant edit rights only to the teams that need them. Review group membership on the same schedule as your other access reviews.
Log access at the proxy
Collabora requests usually pass through your reverse proxy, so the proxy is where you can see which document sessions were opened and from which addresses. Keep access logs with the WOPISrc value where your proxy can capture it, and retain them according to your policy. Confirm with your security team which log fields are needed for investigations and check that logs do not capture document content.
Review the AI assistant before enabling
Collabora Online 26.04 adds an optional AI assistant across Writer, Calc and Impress. It is off by default, and administrators choose the AI provider and whether that provider is hosted externally or on their own infrastructure. Before enabling it, decide whether document content may leave your environment, document that decision, and confirm it with your Kolab and Collabora contacts for your version.
Common failures when connecting Kolab to Collabora Online
This table pairs the failures teams most often hit when Kolab hands documents to Collabora Online with the likely cause and a check to run first. Work down the rows in order, since a blocked connection or mixed protocol usually hides the later symptoms. Each fix is a verification step, so confirm the cause before changing any setting.
| Symptom | Likely cause | Fix and check to run |
|---|---|---|
| Editor does not load | The Collabora discovery URL is unreachable from the groupware or the browser, or the WOPI host is not registered | Request the discovery endpoint from the groupware server and from a client browser. Confirm it returns the expected capabilities, then check DNS, firewall rules and the reverse proxy route for the Collabora hostname. |
| Blocked frames or mixed content warnings | The groupware is served over HTTPS while the Collabora server URL uses HTTP, or the reverse proxy rewrites the scheme incorrectly | Compare the scheme of the groupware URL and the Collabora URL. Use HTTPS for both, then check the browser console for blocked mixed content and confirm forwarded protocol headers reach Collabora. |
| WOPI requests blocked by an allow list | The Collabora server does not accept requests from the groupware's address, often after a change of outbound IP or a load balancer | Check the Collabora logs for WOPI allow list warnings. Confirm the groupware's outbound address as seen by Collabora, and add that address or host to the allow list, then retest. |
| Certificate chain errors on the Collabora URL | The server certificate lacks an intermediate certificate, or the groupware's trust store does not include the internal certificate authority | Test the chain from the groupware host with an OpenSSL client. Install the full chain on the proxy and the internal CA in the groupware trust store, then confirm the connection succeeds without verification errors. |
| Users see view-only mode | Group rules limit editing to a narrower set of groups than intended, so most users only receive read access | Review the group settings for editing in the groupware's Collabora configuration. Test with one account from each group that should edit, and confirm the permission the editor reports before widening access. |
| Documents fail to open | The file type is outside the formats the Collabora build supports, or a file is corrupt or uses a legacy variant | Open a sample file of each type in a test account, note which fail, and check the Collabora logs for the rejected format. Confirm the format against Collabora's supported list before deciding on conversion. |
| Editor opens but changes do not save | The WOPI callback to the groupware is blocked or uses a URL the Collabora server cannot reach | Edit a test file and watch the save request in Collabora and groupware logs. Confirm the callback host and protocol match the public address the groupware advertises. |
How to test document editing before Kolab users rely on it
Test document editing in three parts before any Kolab user is told it works: functional tests, permission tests and failure tests. The functional tests cover the basic cycle for each format your staff actually use. Open, edit, save and reopen a document in docx, xlsx, pptx and an OpenDocument format such as odt, using the Kolab web client and the Collabora Online editor it hands the file to. Confirm the document opens in the expected editor, the save reaches the Kolab storage location, and a second session sees the saved change. Record the exact Kolab and Collabora versions you tested, since the integration path depends on both.
The permission tests check that the access rules you designed behave as written. Use one account in a group allowed to edit and confirm it can change and save a file. Then use an account outside that group and confirm it can only view the document or cannot open it at all, depending on the policy you chose. Also check that a shared link does not grant more rights than the sharing user holds. Keep the test accounts and group memberships documented so the results can be repeated after upgrades or configuration changes.
The failure tests show what users see when editing breaks, which is where support tickets come from. Stop the Collabora Online server, try to open a document, and confirm the Kolab side shows a clear error rather than a blank page or a spinner that never ends. Then restart the server and confirm editing resumes without manual cleanup. Check format fidelity against real company documents, not only sample files, because layout and macro behavior differ between documents. Finally, have the service owner sign off the written results before go-live, and keep that record with the configuration so it is available to auditors and to whoever runs the next upgrade.
Questions buyers ask about Collabora Online and Kolab integration
Do Kolab Now users need to deploy anything themselves?
No, Kolab Now users do not deploy Collabora Online themselves. Collabora describes Collabora Online as an integrated component of Kolab Now, the Swiss-hosted Kolab email and groupware service, and says Kolab chose it to offer a free and open source collaboration stack. Users open and edit documents through the Kolab Now interface, and your team does not need to operate the editing servers for that service. Confirm with Kolab Now which editing features, file types and support terms apply to your account, and who answers questions about document editing. Deploying Collabora Online yourself only becomes relevant if you run Kolab in your own infrastructure, which is a separate project.
What drives the effort of a self-hosted Kolab and Collabora setup?
The effort depends on how much of the stack you run and how many people depend on it. The main drivers are:
- The Kolab version and the Collabora Online branch you choose, since each has its own packages and configuration.
- The deployment method: Docker images, system packages or Kubernetes, with the Collabora Online Controller offered for large deployments.
- Network paths between Kolab and the Collabora servers, including TLS, DNS and any reverse proxy or load balancer.
- Concurrency, meaning how many people edit at once, which sets how many Collabora servers you need.
- Identity and group data, so that only the intended users can open and edit documents.
- The file formats your users work with, and the fidelity tests those formats require.
- The number of environments (test, staging, production) and the change process around them.
What must our team provide for a self-hosted Kolab and Collabora setup?
Your team provides the infrastructure and the decisions, and the engineers who build and run the setup use them. Expect to provide:
- Servers or cluster capacity for the Collabora Online servers and any load balancer, in infrastructure you control.
- DNS names for the Kolab and Collabora endpoints, resolving from every network that needs them.
- TLS certificates for each hostname, with a plan for renewal.
- Identity and group data from your directory, so access rules match your organization.
- Test documents that reflect the formats and templates your staff actually use.
- Named owners for change approval, test sign-off and ongoing updates.
Confirm the host-side settings, such as which systems may send WOPI requests to the Collabora servers, against the documentation for your Kolab version.
Can our internal team set up Kolab with Collabora without a partner?
Yes, an internal team can do the work if it already runs Kolab and has skills in Linux administration, DNS, TLS, reverse proxies and container or Kubernetes operations, plus time for testing. The harder part is often the work after go-live. Collabora publishes security advisories for its editor. For example, the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and that package signing keys were updated for RPM and DEB users. Someone must track advisories, schedule updates and retest document editing after each one. Ask whether your team can absorb that work alongside its existing duties, and whether a second person can take over the editing servers when the main administrator is away.
How long does a self-hosted Kolab and Collabora integration take?
The duration depends on the Kolab version, the size of the environment and how much of it is new. The factors that move the timeline most are whether Kolab and Collabora are already running and in which versions, whether you need a new Collabora server or can reuse an existing one, how many hosts, hostnames and certificates are involved, how many test cycles your document and access checks need, and the change window and approvals in your organization. Ask for the timeline in the written scope. DeployOpen works to fixed scopes agreed in writing before work starts, so the timeline should follow from that scope.
Does the Collabora support plan change who answers integration questions?
Yes. 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 for 100 or more users is quoted with volume discounts and adds integration support, customization services and roadmap input. Integration support decides whether the vendor's team helps with questions about connecting Collabora Online to a host such as Kolab. Confirm which plan fits your user count, what the service level agreement covers, and who is named to answer integration questions. Vendor support and partner implementation work are separate agreements, so write down who owns each part.
What should we ask a partner for in a quote?
Ask for a written scope that names the Kolab and Collabora versions in scope, the deployment method and each environment to be built. The quote should also list:
- Hosts, hostnames, certificates and the network paths tested between them.
- The configuration work on each side and who makes each change.
- Test cases, including the document formats and templates your staff use, with acceptance criteria.
- Handover documentation and a runbook for future updates.
- Support after go-live, whether one-off or on a retainer, and what it covers.
- Assumptions and the inputs you must provide, so any change to price or timeline is visible.
DeployOpen does not publish a price list. A quote follows from the written scope, so the clearer the scope, the clearer the quote.
How DeployOpen scopes, builds and supports Collabora Online for Kolab
DeployOpen plans, implements, integrates and supports self-hosted open-source platforms inside your own infrastructure, and Collabora Online with Kolab follows the same method. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope.
How we scope
- The written scope names the Kolab deployment, the Collabora Online version and how each server is reached.
- It records which user groups may open documents and which may edit them in the browser.
- Engagements are fixed-scope, and ongoing support can be added as a retainer.
How we build
- We install Collabora Online in your infrastructure and configure the WOPI connection from Kolab to it.
- We confirm that load balancers route each document by its WOPISrc parameter so co-editors reach the same server.
- We restrict WOPI requests to known Collabora server addresses and use HTTPS for the server URL.
How we hand over
- Handover includes configuration records, network diagrams and test results for opening and co-editing documents.
- We document the Collabora version in use, the update procedure and the security advisories your team must monitor.
- Your team receives runbooks for restarts, certificate renewal and version updates within the agreed scope.
How we support
- Support can be provided as a retainer covering monitoring, patch application and version upgrades.
- Collabora point releases and security advisories are reviewed and applied under the terms of the agreed scope.
- Confirm with Kolab and Collabora which release branch and support tier your deployment depends on before go-live.
