Collabora Online and OpenText Filr integration guide

How Collabora Online and OpenText Filr integration works for editing

An organization that runs OpenText Filr for file sync and share and wants office documents editable in the browser can connect Collabora Online to Filr through the WOPI protocol, so the editor opens files where they already live. The Collabora server runs in infrastructure you control, which means document content is fetched from Filr, edited in your own servers and returned to Filr without moving files to a third-party editing service. The design question is less whether the two products connect and more where each piece sits and who manages it. Collabora lists OpenText as an integration partner on its partner page, so that page is the first place to check the current supported pairing. OpenText Filr is an appliance-based enterprise file sync and share product. It relies on the access rights, quotas, firewalls and backups of the servers around it, and those controls shape how the editor should be reached. Confirm with OpenText's current Filr documentation which WOPI-related settings Filr exposes, how it authenticates the editor's requests and which hostnames and ports it expects to call. Do not assume these settings match another WOPI host, because the Filr-side configuration is the part most likely to differ.

Plan the Collabora server as a separate component next to the Filr appliance. Decide which network segment it sits in, how Filr reaches it and how users' browsers reach it, and where TLS terminates. Ask OpenText and Collabora to confirm the supported Collabora Online version for your Filr release before you size or install anything. Then confirm, in writing, who owns Filr configuration, who owns the Collabora host and who handles patching for each, since security advisories from Collabora apply to the editing server, not to Filr. A short written design review with both vendors' current documentation in hand will catch most mismatches before the first test document is opened.

What Filr and Collabora need before you connect them

Connecting OpenText Filr to Collabora Online touches the Filr appliance, the Collabora server, your DNS and TLS setup, and your directory structure. Settle these five or six items before the first WOPI test, because each one changes the design of the other.

Supported Filr release

Confirm with OpenText which Filr release and appliance build your organization runs, and whether that release is supported with Collabora Online as a WOPI host. The integration is described on Collabora's partner page, but that page does not give a Filr version matrix, so the version check belongs in writing with the vendor before you select a Collabora release. Record the appliance version in your change plan, since upgrades on either side can change the handshake.

Collabora edition and version

Collabora describes the free CODE edition as suited to testing, home use or small teams and not recommended for production. Plan a supported Collabora Online subscription for any production Filr deployment, and pick a branch that Collabora still maintains with point releases at the time of go-live. Ask the vendor which branch they recommend for Filr before you install anything.

DNS and TLS for the Collabora URL

Give the Collabora server a stable fully qualified name with a valid certificate that the Filr appliance trusts. Filr must be able to resolve that name and reach the server over HTTPS, and the certificate chain must be present in the trust store Filr uses for outbound calls. Mismatched names or self-signed certificates without a trust plan are a common cause of failed document opens.

Network paths in both directions

The WOPI flow needs traffic from users' browsers to Collabora, from Collabora back to the Filr host to fetch and save files, and from Filr to Collabora for discovery and session setup. Map each direction, including firewall rules, proxies and any NAT in the path, before go-live. Write the flows down as a table so your network team can approve each port and source address separately.

Existing Filr users and groups

Filr uses the access rights already set on your file servers, so the people who can open a document in Collabora are the people Filr already lets read or change it. Review how users and groups map from your directory into Filr, and identify any shares or rights that are broader than intended. Editing rights deserve the same review as read rights, because a document that opens in the browser can be changed there.

Owner for Collabora patching

Name one team that owns the Collabora server after go-live, including OS and package patches, Collabora release updates and security advisories. Collabora publishes advisories for Collabora Online, so someone must watch them and schedule updates for a server that sits outside the Filr appliance. Agree on who receives vendor notices, who approves a change and how the server is rebuilt if it fails.

Why Filr access rights stay the source of truth for editing

Filr's existing access rights decide who can reach a file, and that decision should carry over to editing. OpenText Filr is an appliance-based file sync and share product that relies on the access rights, quotas, firewalls and backups of the servers it sits on. Collabora Online does not hold its own user directory or document permissions. It renders and edits only what the WOPI host hands it, so the question for your team is which Filr rights map to view and which map to edit. Before rollout, write that mapping down: for each Filr role or share permission, state whether the user should see the document in the browser, edit it, or be denied entirely. Confirm with OpenText how Filr passes permission information to a WOPI client in your Filr version, because the mapping you can rely on depends on that integration path.

The main risk is granting editor access in the editing layer in a way that Filr itself would not enforce. If a user can open a file for editing but Filr's own rules would only allow read access, the result is a gap between what the storage platform intends and what the editor permits. Treat this as a defect to test for, not an edge case. Review which groups are allowed to open files in the editor and which are allowed to edit, the same way you would review who can download or share. Keep editing rights narrower than or equal to the rights the storage layer already grants, and document any exception with its owner and reason.

Permission inheritance is where this usually breaks. Files in shared folders often inherit rights from a parent folder, and a change made high in the tree may or may not reach a file that was shared directly. Before rollout, build a test set that covers a file inheriting edit rights, a file inheriting view rights, a file with a direct share that overrides its folder, and a file moved from one folder to another. For each case, open the document in Collabora Online as users in each relevant group and confirm the editor matches the Filr permission. Repeat the test after any change to group membership or folder structure, and record the results as evidence for your access review.

Setup sequence: from Collabora server to first edit in Filr

This sequence takes a Filr environment from no document editing to a verified first edit in a pilot group, with each step closed by a check you can record. It keeps the Collabora server and the Filr appliance under your control so that access rights and version history stay where your team already manages them.

Confirm Filr release and WOPI support
Your Filr administrator and the OpenText vendor contact confirm in writing which Filr release supports WOPI-based editing with Collabora Online, and which settings that release documents. Use the Collabora partner page for OpenText as the starting reference, then record the Filr version, the Collabora Online branch you plan to run and any known constraints. Do not assume a release supports the integration until OpenText confirms it. The step is done when you hold a signed-off compatibility note that names both versions.
Install the Collabora server by chosen method
Your platform team installs Collabora Online using the method you selected, whether Docker images, system packages or Kubernetes, on hosts in your own network. Pick a supported branch rather than the free CODE edition if the server will serve production users. Confirm that the server starts, that its logs show no startup errors and that the service listens on the expected port. The check is a local response from the server's capabilities or discovery endpoint on the internal network, which confirms the service is reachable before any Filr traffic is involved.
Configure TLS and the public Collabora URL
Your network team puts the Collabora server behind a TLS-terminating reverse proxy or ingress, then sets the public URL that Filr will use. Use HTTPS, and make sure the certificate chain is trusted by the Filr appliance, since an untrusted certificate is a common cause of failed editor loads. Record the exact URL, including any path prefix, because it must match what Filr is configured with later. The check is a successful HTTPS request to the discovery endpoint from a host on the Filr network, returning a valid certificate and the expected response.
Restrict WOPI host addresses to the Filr appliance
Your security team configures the Collabora server to accept WOPI requests only from the address or addresses of the Filr appliance, using the WOPI host allow list controls in your Collabora configuration. Confirm the appliance addresses with your Filr administrator, including any load balancer or NAT address that Filr traffic will appear to come from. Keep the list under change control because a missing entry blocks editing and an overly broad entry widens exposure. The check is that a request from an address outside the list is refused, and a request from the Filr appliance is accepted.
Enable the integration in Filr
Your Filr administrator enters the Collabora server URL and any related settings in the Filr configuration, using the settings that OpenText documents for the confirmed release. Apply the change in a non-production appliance first if you have one, and note the configuration values exactly as entered. Restart or reload services only where OpenText's documentation says to do so. The check is that Filr reports the editor integration as enabled, and that the configuration values match the record kept in the earlier steps.
Test with a pilot group
Your Filr administrator selects a small pilot group with access to a set of test documents, including .docx, .xlsx and .pptx files that represent your real formats. Each pilot user opens a document in the browser, makes a tracked edit, saves, and checks that the save appears in Filr with the expected new version number. Repeat the test with two users editing the same document to confirm co-authoring behaves as you expect. Record any failures with the Filr and Collabora log entries, then expand access only after the pilot passes. The check is a documented pilot result showing successful opens, saves and version increments for every format in scope.

How Filr users, groups and rights map to editor permissions

This table compares each Filr element with what Collabora Online receives or enforces, and the decision your team must make for it. Read each row as a question to answer in your own environment, and treat cells marked as items to verify as unconfirmed until tested in your Filr release.

Filr element	What Collabora receives or enforces	Decision for your team
User identity	The WOPI host passes a user identifier and display name when it opens a document. Confirm in your Filr release which identity value is sent and whether it matches the account name Collabora sees (verify in your release).	Decide whether Filr or the Collabora server is the source of truth for names in document history and comments.
Group membership	Collabora does not read Filr groups directly. Group-based access reaches the editor only as the permission Filr grants when it opens the file (verify how Filr evaluates group rights for WOPI requests).	Decide which Filr groups may open files in the editor, and test a user from each group before rollout.
Folder share rights	Filr's existing share rights are the access rules that apply. The editor should only open a file when Filr has already authorized the request. Confirm this behavior in your release.	Decide whether to keep existing share rights unchanged or tighten them for files opened through the editor.
Read-only versus edit access	Collabora applies the edit or view mode that the WOPI host sends in the file information. Confirm in your Filr release whether a read-only share results in a read-only session (verify in your release).	Decide which shares allow editing and whether view-only shares must be enforced in the editor, then test both.
File locks or version handling	Collabora's handling of locks and saved versions depends on what Filr returns for lock and version requests. Confirm how concurrent edits, save conflicts and version history are recorded (verify in your release).	Decide the expected behavior when two users edit one file, and whether Filr keeps a version for each saved change.
File types opened	Collabora Online supports OpenDocument formats and Microsoft formats such as docx, xlsx and pptx, plus PDF, RTF, CSV and Visio. Confirm which types Filr routes to the editor in your deployment (verify in your release).	Decide the list of file types that open in the editor and test each one with representative documents.

Securing the WOPI path between Filr and Collabora

The WOPI connection between Filr and Collabora Online carries document content and edit sessions, so it needs the same controls as any other trust boundary. The cards below cover network reach, transport, patching, access rights, placement and logging, and they are meant to be settled in the design before the Collabora server goes live.

Restrict WOPI requests to Filr

Limit which hosts can call the Collabora server so that only the Filr appliance addresses can make WOPI requests. Confirm with your Filr and Collabora administrators which appliance addresses or load balancer addresses reach the Collabora server, and record them. The Nextcloud administration manual recommends the same kind of allow list for its own WOPI setup, which is a useful parallel practice, but Filr's exact configuration steps should be confirmed with OpenText and Collabora documentation.

Use HTTPS on both sides

Match the protocol on both ends of the WOPI path. The Filr server URL and the Collabora server URL should use the same protocol, and HTTPS is the preferred choice in the Nextcloud guidance that this practice parallels. Plan certificates for the Collabora hostname, decide how the trust chain reaches the Filr appliance, and check that browser sessions to the editor are also encrypted end to end.

Keep the server patched

Track Collabora security advisories and apply point releases to the branch you run. Collabora publishes advisories, and its 25.04 release notes record a fix for CVE-2026-23623 in 25.04.7.5, along with updated package signing keys for RPM and DEB users. Confirm which branch your Collabora server runs, install only packages verified with the current signing keys, and set a test and rollout routine for each point release.

Limit who can use and edit

Decide which Filr user groups may open documents in the editor and which may edit rather than only view. Map these decisions to Filr's existing access rights so that the editor does not grant more than the file share already allows. Test with a read-only account, an editing account and an account with no access, and confirm that the editor respects each result.

Place Collabora inside your boundary

Run the Collabora server inside your own network boundary, with firewall rules that allow inbound WOPI traffic from Filr and the client connections your users need, and deny other paths. Document which ports and source addresses are open in each direction. Involve your network and firewall team early, because the placement affects how Filr reaches Collabora and how browsers reach it for editing sessions.

Log access to documents

Enable logs on the Filr appliance, the Collabora server and any reverse proxy in front of them, and forward them to the log platform your security team uses. Logs should show which user opened which document, from which host, and when, so that investigations can connect editing sessions to Filr access events. Confirm retention periods and log fields with your security team before rollout.

Planning the Collabora server next to the Filr appliance

The Docker route fits a team that already runs container hosts and wants a self-contained Collabora Online service placed next to the Filr appliance on the same network segment. Collabora publishes the free CODE image as collabora/code for x86-64, ppc64 and arm64, and the product page describes Docker as one of the supported deployment methods. Your team operates the container host, image pinning, restarts, log collection and the update cycle for the image.

Image source: Confirm whether the CODE image or a supported Collabora Online build fits your support requirements, since CODE is described as not recommended for production.
Host sizing: Concurrent editors and the size of documents they open drive memory and CPU use, so size the host from measured load rather than a default.
Network placement: Plan which address Filr and browsers reach, and which WOPI host addresses the Collabora server must trust.
Update process: Plan how you will track point releases and security advisories and apply them in a window that suits your change process.
Storage and logs: Decide where container logs go and how long they are kept for troubleshooting.

Before committing, confirm with your Filr team which WOPI host and discovery settings the appliance needs and whether your container host meets your hardening baseline.

Common failures when Filr cannot open documents in Collabora

This table pairs common symptoms with their likely causes and first fixes when OpenText Filr cannot open or save documents through Collabora Online. Work through the rows in order, since a failed connection or allow list check often hides the later problems. Confirm each fix against current OpenText and Collabora documentation before changing a production system.

Symptom	Likely cause	Fix to check
Editor does not load	Filr cannot reach the Collabora server URL, or the Collabora discovery endpoint is not reachable from the user's browser	Test the discovery URL from the Filr appliance network and from a user workstation, then correct routing, DNS or firewall rules between the two
WOPI host rejected by the allow list	The Filr host address is not on the Collabora server's WOPI host allow list, so the server refuses the request	Add the Filr appliance address as it appears to the Collabora server, then restart the service and confirm the allow list entry matches exactly
Mixed HTTP and HTTPS causing protocol errors	Filr is reached over HTTPS while the Collabora server URL or callback uses HTTP, or a proxy rewrites the scheme	Use the same protocol for both sides, preferably HTTPS throughout, and check proxy headers so callbacks carry the correct scheme
Certificate trust failures between appliance and server	The Collabora server presents a certificate that the Filr appliance does not trust, often a private or internal certificate authority	Import the issuing certificate chain into the appliance trust store as OpenText documents for custom certificates, and confirm the chain is complete
Users see view-only access unexpectedly	The Filr access rights or the editing permission mapped to the user do not grant edit rights, or the file is locked or read-only at the source	Review the user's rights on the file in Filr, check any lock state, and confirm the integration passes edit permission for that user and folder
Edits not saved back	The callback from Collabora to Filr fails, usually because of an unreachable host, a certificate error or a blocked return path	Check the return path from the Collabora server to Filr, review server logs for failed save requests, then retest with a test file in a non-production folder
Documents open on the wrong pod in a multi-server setup	The load balancer does not route by the WOPISrc parameter, so users editing one document reach different Collabora instances	Configure the load balancer to route by WOPISrc, as the Collabora Helm chart requires, and test with two users editing the same document at the same time

What does a Filr and Collabora integration cost and take?

What drives the cost of a Filr and Collabora integration?

The cost follows the number of hosts, the network path between Filr and the Collabora server, and how much of the work is design versus configuration. Cost components are the planning and architecture work, the Collabora server build and hardening, the Filr-side configuration, testing with your real document sets, and handover documentation. Costs rise when Filr is served to several sites, when TLS certificates and internal DNS need changes, when firewall rules must be approved by a separate team, or when users need format fidelity checks across many file types. Ask any quote to list each component, who performs it, and whether it is one-time or recurring.

Can our own team run a Filr and Collabora integration without a partner?

Yes, if your team already runs Filr and has experience with Linux servers, reverse proxies, TLS and container or package-based software. The work needs someone who understands Filr's appliance model, the access rights already defined on your servers, and the WOPI connection between the two systems. Teams without that mix often spend the most time on network reachability and certificate issues rather than on the editor itself. A partner can cover the parts you lack, or review your design before build. Compare the internal effort against the written scope you would otherwise have to produce yourself.

How long does the integration take, and what sets the schedule?

Duration depends on how many environments you have, how quickly network and security reviews can happen, and how many document types must be tested. The main schedule drivers are approval of firewall changes between Filr and the Collabora server, availability of certificates and DNS records, the size of the test document set, and whether a staging environment exists before production. Most engagements are fixed-scope, so the timeline is agreed in writing before work starts. Ask for the timeline as a list of milestones with dependencies on your teams, not as a single number.

What does the client need to provide before the work starts?

Plan to provide the following before design begins:

An inventory of the Filr appliance version, deployment layout and the servers that already enforce access rights, quotas, firewalls and backups
Network diagrams showing how users, Filr and any proposed Collabora host reach each other
Certificate and DNS ownership, with the name of the team that issues them
A test set of representative documents in the formats your users edit
Named contacts for security review, change approval and Filr administration
A staging environment, or a decision on where test copies will run

If any item is missing, ask the quote to state the assumption it relies on so the schedule can be corrected.

How does Collabora licensing affect the budget for Filr integration?

Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, which includes long term support, a service level agreement, signed security updates and customer portal access, according to the Collabora Online pricing page. Plans for 100 or more users are quoted with volume discounts. Licensing is a recurring cost that scales with users, separate from the one-time integration work. The free CODE edition is positioned for testing and small teams, and Collabora does not recommend it for production, so confirm which edition your architecture requires before you compare quotes. Ask whether the integration quote assumes a subscription and whether support terms apply to the Filr deployment.

Can Collabora Online run on the servers we already operate?

It can run on existing infrastructure if the host has enough capacity, the operating system or container platform is supported, and firewall rules allow the connections Filr needs. Collabora Online is deployed from Docker images, system packages or Kubernetes, and the server should be separate enough from Filr that editing load does not disturb file sync. Confirm the sizing against your expected concurrent editing, not total user count. Collabora's Helm chart documents production resource levels for Kubernetes pods, which give a reference point when you size a container deployment. Treat co-location as a design decision to review, not an assumption.

What happens after go-live, and who maintains the integration?

After go-live, someone must own certificate renewal, Collabora updates, security advisories, Filr appliance updates and monitoring of the WOPI connection. Collabora publishes security advisories and point releases for its branches, so the operations process needs a patch cadence and a test step before production. Ask the quote whether it includes handover documentation, runbooks and training, and whether ongoing support, upgrades or testing are offered as a separate retainer. Support terms should name who responds to an incident and how a Filr or Collabora upgrade is tested before it reaches users.

How DeployOpen scopes and delivers the Filr and Collabora integration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Collabora Online and OpenText Filr, we start from a written scope that sets out how Filr and the Collabora server will be placed, networked and handed over.

How we scope

We confirm your Filr appliance version, the existing server access rights it relies on, and where the Collabora server will run.
We record the Filr users, groups and document types in scope, along with the file formats editors must open and save.
Engagements are fixed-scope, so deliverables, responsibilities and timelines are agreed in writing before any build work begins.

How we build

We configure the WOPI connection between Filr and Collabora Online, including reachability, TLS and the discovery URL your servers use.
We set up the Collabora server in your chosen environment, with routing, sizing inputs and firewall rules written down for review.
We test editing, saving and access checks with real Filr accounts and sample documents from your existing libraries before sign-off.

How we hand over

You receive configuration records, network diagrams, test results and step-by-step runbooks for administrators who run the integration.
We walk your platform and security teams through access rights, allow lists and how each control was verified.
Evidence and documentation are prepared so your own auditors or certification bodies can assess the controls, since we do not issue attestations.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so updates to Filr or Collabora Online can be planned.
When a new Collabora Online release arrives, we can review its impact on your Filr integration and schedule the upgrade in your environment.
Retainer scope, response expectations and review cadence are written into the agreement so your team knows what to expect.

Collabora Online and OpenText Filr integration