How Collabora Online editing reaches FileCloud files
Users of self-hosted FileCloud want to open Word, Excel and PowerPoint files in the browser and edit them without the content leaving servers the organization controls. The editing path is the WOPI protocol: FileCloud acts as the WOPI host that stores files and checks who may open them, and a Collabora Online server that you operate renders and edits the document in the user's browser. Collabora lists WOPI as its integration method and names FileCloud among its integration partners on the Collabora partner page for FileCloud. That page confirms the relationship, but it does not describe the exact connector, configuration keys or version pairing FileCloud uses. Confirm those details with FileCloud and against FileCloud's own documentation before the build starts, and record the versions you intend to run together.
Collabora Online can open and edit OpenDocument formats and Microsoft formats including docx, xlsx and pptx, and it also handles PDF, RTF, CSV and Visio files, according to Collabora's product page. Format coverage is one of the first things to test with your own files, because fidelity on complex layouts, tracked changes and embedded objects varies. Build a sample set from the document types your staff actually use and open each one through the full path before users depend on it. Treat any format that is not on the supported list as unconfirmed until you have tested it.
FileCloud stays the system of record for files, users, groups and sharing. Collabora Online does not decide who owns a document or who can see it; it receives a session that FileCloud has authorized for a specific file and returns the edited content. This split means permissions, retention and audit trails remain in FileCloud, and your access review should start there. Plan the network path between the two systems as part of the design, including which server URL FileCloud uses to reach Collabora and which address Collabora uses to call back to FileCloud, because a wrong callback address is one of the most common causes of failed sessions. Keep both URLs on HTTPS where your configuration allows it.
What you need in place before connecting FileCloud and Collabora
The FileCloud and Collabora Online connection depends on a few decisions made before any configuration starts: versions, names, certificates, network paths and licensing. Working through these six items first shortens the setup and avoids rework when WOPI traffic is tested.
Supported FileCloud version and admin access
Confirm which FileCloud release your organization runs and whether the Collabora editing option is available for it, since the partner listing alone does not confirm version support. You need an enterprise account with administrator rights to change the document editing settings, install any connector, and read the logs when a document fails to open. Ask FileCloud for the supported version list and the settings path in writing before planning the change window.
Collabora Online release branch
Choose the Collabora Online branch based on how long you need security fixes and vendor support, not only on the newest feature set. The 25.04 branch, for example, was still receiving point releases in 2026, so check the current release notes before committing to a branch. Record the exact version you will deploy, because the FileCloud connection is tested against that build.
DNS names and TLS certificates
Plan a dedicated DNS name for the Collabora server and confirm that FileCloud has a name of its own, both resolvable from the networks that need them. Both sides must use HTTPS with certificates the other side trusts, including any internal certificate authority. Mismatched names or untrusted certificates are a common reason documents fail to open in the browser, so verify certificate chains from each host before the integration step.
Network path from users to Collabora
Users' browsers must reach the Collabora Online server directly, because the editor loads from that server and opens its own connection while a document is being edited. Confirm that firewalls, reverse proxies and any VPN paths allow this traffic for every user group that will edit documents. Inspect the path from a test client on the same network segment as your staff, not only from the admin workstation.
Network path from Collabora back to FileCloud
The Collabora server calls back to FileCloud over WOPI to read and save each document, so the path runs in the reverse direction from the browser path. Confirm that the Collabora host can reach FileCloud on the required address and port, and restrict incoming WOPI requests to known Collabora server addresses where your setup allows it. Document these rules so the security team can review them alongside the browser path.
Confirmed connector and WOPI settings
Before configuration, request the current connector or WOPI setting names, discovery URL format and any required options from FileCloud and Collabora, and confirm they match your chosen versions. Do not rely on older blog posts or forum threads for key names or paths. Store the confirmed values in your change record so that later upgrades can be checked against the same list.
Why WOPI requests decide who can open and edit
In WOPI, FileCloud decides who may open a file and Collabora Online acts only on what FileCloud asks for. When a user opens a document, FileCloud hands the browser a request to the Collabora server that identifies the file and carries the permission context for that session, such as whether the user may view or edit. Collabora then calls back to FileCloud's WOPI endpoints to read the file, check the user, and save changes. The trust boundary therefore sits in two places: the access decisions FileCloud makes when it builds the request, and the question of whether the Collabora server will accept and act on requests from addresses it should not hear from. Before go-live, your team should confirm in FileCloud's documentation how its WOPI settings define user identity, edit rights and session lifetime, because those settings determine what a Collabora server is allowed to do on a user's behalf.
The protocol used in the Collabora server URL matters because it governs the traffic that carries file contents and access tokens between the browser, FileCloud and Collabora. The Nextcloud administration manual, a published reference for Collabora-based office editing, recommends using the same protocol for the Collabora server URL as for the host installation, preferably HTTPS. The same guidance applies by analogy here, but FileCloud's equivalent setting and its certificate requirements must be confirmed in its own documentation before you copy the approach. Mixed protocols can cause browsers to block content and can expose documents and tokens to interception on the path between services, so check both URLs and their certificate chains together in your test environment.
Restricting WOPI requests to known Collabora server addresses reduces exposure because it limits which machines can ask FileCloud for file content. The Nextcloud manual makes the same recommendation, advising administrators to allow only the IP addresses of the Collabora servers. For FileCloud, confirm whether the product offers an equivalent allow list, how it handles addresses behind a load balancer or reverse proxy, and what happens when a Collabora server is replaced or scaled out. Document the allowed addresses as part of the deployment record and review them whenever the Collabora topology changes, since a stale or overly broad list is a common way for a convenience setting to become a standing exposure.
Setting up Collabora Online with FileCloud, step by step
This sequence takes a self-hosted FileCloud environment from version checks to a pilot group editing documents in the browser. Each step ends with a check you can run, so you know the connection, the access controls and the save path work before wider rollout.
Confirm versions and the supported connector
Start by reading Collabora's FileCloud partner page to confirm that the current FileCloud release and the Collabora Online branch you plan to deploy are supported together. Ask FileCloud and Collabora to confirm the pairing in writing, and record the FileCloud version, the Collabora branch and the connector or setting that enables editing. Use a supported Collabora branch for production, since the free CODE edition is not recommended for production use. The step is done when you hold a written compatibility confirmation for the exact versions in your environment.
Deploy the Collabora Online server
Install Collabora Online on infrastructure your organization controls, using Docker images, system packages or Kubernetes, as described on the Collabora Online product page. Place the server on a network segment that FileCloud can reach over HTTPS and that your users can reach through the browser flow. Keep the Collabora server separate from the FileCloud host unless your testing shows the combined setup is acceptable. The check is a successful start of the service and a response from its WOPI discovery endpoint when requested from the FileCloud server.
Configure TLS and the server hostname
Choose the public or internal hostname that FileCloud and users will use for the Collabora server, and issue a certificate that both sides trust. Serve the Collabora URL over HTTPS and use the same protocol as the FileCloud installation, which the Nextcloud administration manual also recommends for WOPI-based editors. Confirm that the certificate chain is complete and that the hostname resolves identically from the FileCloud server and from user networks. The check is a clean TLS handshake from the FileCloud host, with no certificate warnings or name mismatches.
Register the discovery endpoint in FileCloud
In the FileCloud administration area, enter the Collabora discovery URL for your server in the office editor settings, using the exact path and menu described in FileCloud's current administration guide. Save the setting and confirm that FileCloud lists the Collabora editor as enabled and shows the document types it will open. If the settings page offers no discovery field, stop and confirm the supported method with FileCloud before continuing. The check is that FileCloud reports the editor as available and that the discovery URL it displays matches the one you tested in the previous step.
Restrict WOPI sources to FileCloud addresses
On the Collabora server, limit WOPI requests to the IP addresses of your FileCloud servers, following the WOPI host allow list controls in Collabora's configuration documentation. Include every FileCloud node, and any reverse proxy address that forwards requests, so that legitimate traffic is not blocked. Then test from a host outside the list to confirm it is refused. The check is that a request from an unlisted address is rejected, while a document opened from FileCloud still loads in the editor.
Set editing permissions by group
In FileCloud, decide which groups may open documents in the browser editor and which may edit rather than only view them. Confirm whether FileCloud offers group-level control for these two rights in your version. If it does not, enforce read-only access through the existing share and folder permissions and document the workaround. Create one test account in a view-only group and one in an edit group. The check is that the view-only account opens documents read-only and cannot save changes, while the edit account can save.
Run test documents in each format class
Prepare a small set of test files for each format class your organization uses: word processing, spreadsheets, presentations, PDF and any legacy or OpenDocument formats. For each file, open it from FileCloud, make a visible edit, save it, then reopen the file from FileCloud in a new session. Compare layout, tables, fonts and embedded objects with the original. Record any file that loses fidelity so that you can decide on a workaround before pilot use. The check is that every test file saves back to FileCloud as a new version and that the edits appear on reopening.
Open the server to pilot users
Enable editing for a small pilot group that represents the document types and teams you expect to use the editor most. Watch the Collabora and FileCloud logs during the pilot and collect user feedback about opening, editing and saving. Confirm the operating procedure for certificate renewal, version changes and incident contacts before the group starts. Expand access only after the pilot shows no unresolved save or permission problems. The check is that pilot users complete their normal editing sessions without errors, and that the saved versions match what they edited.
How FileCloud users, groups and permissions map to editing rights
This table compares the FileCloud objects that decide who can open, edit and save a document through Collabora Online, and where each one is set. FileCloud permissions remain the source of truth, so treat each row as a checklist to confirm against the FileCloud version your team deploys before go-live.
| FileCloud object or role | What it controls in the editor | Where it is set | What to test |
|---|---|---|---|
| User accounts and authentication | Identity the WOPI host passes to Collabora, which determines whether a session opens at all | FileCloud admin console and its configured identity source | Sign in as a local user, a directory user and an account that is disabled, then confirm each result in the editor |
| Group membership for the editor | Whether a user sees the editing option for Office files, if the integration exposes a group gate | FileCloud group settings and the Collabora integration configuration | Open the editor as a member and a non-member of the permitted group and record both outcomes |
| Edit rights for group members | Whether a user can change content or only view it after opening | FileCloud share or folder permission assigned to the group | Confirm a user with view-only rights cannot save changes and that the save button or equivalent is absent |
| Folder and file sharing permissions | Which documents a user can open in the editor at all, including inherited folder rights | FileCloud folder and file share settings, including inheritance | Test a file inside a shared folder, a file shared directly and a file in a folder the user cannot reach |
| Read-only links | Whether a link recipient can view a document in the browser without edit rights | FileCloud share link options when the link is created | Open the link in a clean browser session and attempt edits, then check the link expiry and password settings |
| Document ownership on save | Which account is recorded as the author or modifier after co-editing and saving | FileCloud version history and audit records | Edit as two users, save, then check version history and audit entries for the correct user names and timestamps |
Security controls that keep documents on your servers
Collabora Online and FileCloud exchange document contents and session tokens on every edit, so the controls below decide who can open, change and reach a document. Each one closes a different path: the transport, the caller, the user group, the network zone and the software itself.
HTTPS on every hop
Serve FileCloud and the Collabora Online server over HTTPS, and use the same protocol for the Collabora server URL as for FileCloud. Mixed protocols let session tokens and document contents travel in clear text between the browser, FileCloud and Collabora. Check the certificate chain on both hosts, and confirm that FileCloud is configured to reach Collabora on the URL you intend to expose to users. This control covers the browser path as well as the server-to-server WOPI calls.
Allow listing WOPI request sources
Restrict WOPI requests so that only the Collabora server addresses can call your file host. The Nextcloud administration manual recommends this for Nextcloud, and the same principle applies to a FileCloud deployment: anything that is not a known Collabora server should not be able to fetch or write documents through the WOPI interface. Ask your FileCloud and network teams which addresses reach the FileCloud WOPI endpoints, and confirm that the list is updated when Collabora servers are added, moved or replaced.
Limiting editing to approved groups
Decide which FileCloud groups may open documents in the browser editor and which may edit rather than only view. Nextcloud Office supports this kind of group-level limit, and FileCloud access rules should map the same way. Start with a narrow group for editing, add view-only access for everyone else, and review membership when people change roles. Confirm with FileCloud how share permissions and editor permissions interact, so a user with read-only share rights cannot gain write access through the editor.
Same network trust zone for Collabora
Place the Collabora Online server in the same network trust zone as FileCloud, and keep its path to the file store inside your own infrastructure. A Collabora server outside that zone adds another system that handles document contents and needs its own access controls. Review firewall rules so that only the required ports and addresses are open between the browser, FileCloud and Collabora, and document the zone in your architecture records for auditors.
Applying Collabora security 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. A vulnerability in the editor can expose documents being edited, so an advisory is a patch decision with a deadline, not a routine update. Subscribe to Collabora's release notes, record the version running in each environment, and agree a window for applying fixes to the Collabora server and FileCloud together.
Verifying package signing keys
Collabora's 25.04 release notes record that package signing keys were updated for RPM and DEB users. When you install or update Collabora Online from system packages, confirm that the package manager trusts the current key before you install, and do not disable signature checks to get past a key error. Keep a record of the key fingerprint your team verified, and treat an unexpected key change as an incident to investigate with Collabora before continuing the update.
Common failures when connecting FileCloud to Collabora Online
This table pairs common symptoms seen when FileCloud is connected to Collabora Online with their likely causes and first fixes. Treat each cause as a hypothesis, and confirm it against the FileCloud and Collabora logs before changing configuration. The main takeaway is that most failures trace back to URL scheme, certificate trust, WOPI allow lists or permission mapping, and each one is checkable.
| Symptom | Likely cause | Fix to confirm in logs |
|---|---|---|
| Documents do not open at all | The FileCloud server cannot reach the Collabora discovery URL, or the discovery endpoint is not answering on the expected host and port. | Test reachability from the FileCloud host to the Collabora server, confirm the discovery URL in FileCloud settings, and check the Collabora server logs for incoming WOPI requests. |
| Editor loads but documents never save | WOPI callbacks from Collabora back to FileCloud fail, often because the FileCloud address Collabora uses is not reachable from the Collabora server. | Check that the callback address resolves and is reachable from the Collabora host, then review FileCloud logs for rejected PutFile or CheckFileInfo calls. |
| Browser shows mixed content or certificate errors | FileCloud is served over HTTPS while the Collabora URL uses HTTP, or the Collabora certificate is not trusted by the browser or the FileCloud host. | Use the same protocol for both services, install a certificate chain trusted by the FileCloud host, and confirm the certificate names match the URLs configured. |
| WOPI requests are blocked | The WOPI host allow list on the Collabora server does not include the FileCloud server address, or a reverse proxy changes the source address seen by Collabora. | Add the FileCloud address to the allow list, verify the address Collabora sees in its logs, and check proxy headers before changing other settings. |
| Users can view but cannot edit | The user's FileCloud permission is read-only for that folder, or the editing group setting in the integration does not include the user. | Compare the user's effective FileCloud permissions on the file with the group settings for editing, then retest with a known editor account. |
| Documents open read-only after group changes | Group membership changed in FileCloud, but the editor session or cached permission data still reflects the earlier state. | Close existing editing sessions, ask the user to reopen the file, and confirm the new membership appears in the FileCloud logs for the access check. |
Where the Collabora server should run for FileCloud
This option suits organizations whose FileCloud servers already run in one data center with dependable, low-latency links between systems. Keeping the Collabora server beside FileCloud shortens the WOPI path, simplifies certificate and firewall management, and keeps document traffic inside one controlled network segment.
- Network path: Place the Collabora server on the same internal segment as FileCloud so editor requests and WOPI callbacks take a short, known route. Confirm which address FileCloud uses to reach the editor and which address Collabora uses to call back.
- Sizing: Size the server for the peak number of simultaneous editing sessions, not the total user count. Ask Collabora to review sizing against your expected concurrency before you choose a subscription tier.
- Access restriction: Limit WOPI requests to the FileCloud server addresses, and use HTTPS for both the FileCloud and Collabora URLs.
- Single point of failure: One server is simple to operate but stops all editing if it fails. Document restart, recovery and rollback steps before go-live.
Check that FileCloud and the Collabora server agree on hostnames, HTTPS and certificate chains before you test a live document.
This option suits organizations that need the editor in another network zone, either for spare capacity at a second site or to separate document editing from the FileCloud tier for security or ownership reasons. The trade-off is that every editing session now crosses a zone boundary, so latency, firewall rules and certificates need explicit design.
- Latency and timeouts: Measure round-trip time between FileCloud and the editor hosts under load. Editing depends on fast responses, so slow links show up as sluggish sessions before they show up as errors.
- Firewall rules: Open only the paths required in each direction, and confirm them with both network teams. Keep a written record of each rule and its owner.
- Sizing per host: Size each host for the concurrency it will carry, and confirm whether the two zones share load or one acts as standby.
- Multiple hosts: When more than one host serves editing, put a load balancer in front that routes by the WOPISrc parameter, so all users editing one document reach the same server.
Agree on the zone design, latency targets and firewall ownership with your network and security teams before you commit to this placement.
This option suits platform teams that already run Kubernetes and want the editor deployed, configured and upgraded the same way as their other workloads. The official Collabora Online Helm chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replica counts are set manually.
- Manual replicas: Set the replica count in your values file and change it only during planned windows. Changing replicas during active sessions can disrupt editing.
- WOPISrc routing: Configure the ingress so requests are routed by the WOPISrc parameter, which keeps all users editing one document on the same pod. Nginx, HAProxy and the OpenShift Router are supported ingress options.
- Per-pod resources: The chart recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Treat these as starting points and confirm them against your expected concurrency.
- Ingress and TLS: Plan certificates, hostnames and the FileCloud-facing URL alongside the ingress controller you already operate.
Review the current chart README and your ingress design with your platform team before you write the values file.
Questions buyers ask about FileCloud and Collabora Online
What drives the cost of adding Collabora Online to FileCloud?
The main cost components are the Collabora Online licence or edition, the servers that run Collabora Online, and the services work to connect it to FileCloud and test it. According to the Collabora 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. Enterprise is quoted for 100 or more users with volume discounts and adds integration support, customization services and roadmap input. Your user count, the plan you choose, the number of environments, and how much testing your document types need are the factors that move the total most.
Which costs are one-time and which recur after go-live?
One-time costs cover planning, installing Collabora Online, configuring the WOPI connection from FileCloud, setting up TLS, and testing with your own documents. Recurring costs cover the Business or Enterprise subscription if you choose one, hosting for the Collabora servers, monitoring, and applying point releases and security fixes. Collabora publishes point releases on its release notes, so someone must own that cycle after handover. Re-testing after each FileCloud or Collabora upgrade is also a recurring activity that is easy to leave out of the budget.
Can our own team set up Collabora Online with FileCloud without a partner?
Yes, a team can do this internally if it has administrators comfortable with Linux, Docker or Kubernetes, reverse proxies, DNS and certificates, and admin access to FileCloud. The harder parts are usually the WOPI connection, correct HTTPS endpoints, and restricting WOPI requests to the Collabora server addresses. Confirm in FileCloud's own documentation how it configures WOPI-based editing in your version, because the setup steps depend on that release. A partner adds value when you want a fixed scope, written acceptance tests, and a handover that your staff can operate without the original builders.
How long does a FileCloud and Collabora Online integration take?
The duration depends on the factors that set the work, not on a fixed number. Expect the schedule to be driven by the number of environments (test, staging and production), the sizing needed for expected concurrent editing, the network path between FileCloud and the Collabora server, and how long certificate, DNS and firewall changes take to approve in your organization. The volume and variety of test documents also matters. Ask any provider for a schedule tied to a written scope with named milestones, and ask which of those milestones depend on your internal approvals.
What must our organization provide before the integration starts?
Before work starts, you should prepare the following items:
- Administrator accounts for FileCloud and the servers that will host Collabora Online
- Firewall and routing changes that allow traffic between FileCloud and the Collabora server
- DNS names and TLS certificates for the Collabora server URL, using HTTPS
- Agreed WOPI restrictions, such as allowing only the Collabora server IP addresses to send WOPI requests, as the Nextcloud administration manual recommends for its own WOPI setup
- Test documents in the formats your staff use, including docx, xlsx, pptx, odt and PDF
Also name the people who approve changes and who will test editing with real files.
Do our documents stay inside our own infrastructure with this setup?
Collabora Online is self-hosted, so the editing server runs on servers you control, and documents move between FileCloud and that server during editing. The location of your data is set by your deployment choices, so confirm the design in writing. Check where FileCloud stores files and temporary copies, whether any traffic leaves your network, and whether the optional AI assistant in Collabora Online 26.04 is enabled. According to the Collabora Online 26.04 announcement, that assistant is off by default, and administrators choose whether the AI provider is external or runs on their own infrastructure. Keep it off unless your data policy allows it.
What should a written quote for this integration include?
A useful quote states the scope, deliverables and acceptance criteria in writing before work starts. Ask for the FileCloud version and Collabora Online edition assumed, the number of environments, the sizing basis, the test document list, and the milestones with the approvals each one needs. The quote should separate what the provider does from what you buy, including any Collabora subscription, hosting and certificates. Ask what handover documents you receive, how changes are priced after go-live, and what support terms apply. DeployOpen works to a fixed scope agreed in writing, and a quote follows from that scope.
How DeployOpen scopes and delivers the FileCloud integration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Collabora Online and FileCloud, that means agreeing the scope in writing first, building the WOPI connection in your environment, and handing over a documented system your team can run.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We confirm which FileCloud version, deployment model and user groups will use Collabora editing.
- We map where the Collabora server will run, including network paths, TLS and restricted zones.
- A written quote follows from the agreed scope, so you can compare it against your own team's effort.
How we build
- We configure the FileCloud and Collabora Online connection over WOPI in your cloud account, data center or air-gapped network.
- We restrict WOPI requests to known Collabora server addresses and align protocols and hostnames across both systems.
- We test editing of the document formats your users rely on, including Microsoft and OpenDocument files, before rollout.
How we hand over
- You receive configuration records, network and TLS notes, and the access settings for editing groups and viewers.
- We document the test results, known format limits and the steps to confirm each release of both platforms.
- Your team is walked through day-to-day checks, so editing problems can be diagnosed without a support call.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover Collabora Online point releases and FileCloud upgrades, with the connection retested each time.
- Ask any partner to confirm which Collabora release line and security update process they will follow for your servers.
