Collabora Online Nextcloud integration

The Collabora Online server URL is the address Nextcloud uses to load the editor, and it is the first setting to get right. The Nextcloud administration manual recommends that the Collabora server URL use the same protocol as the Nextcloud installation, and preferably HTTPS. A mismatch can produce a page that loads the editor frame but fails to open documents, or browsers that block mixed content. Before you enter the value in the Nextcloud Office settings, confirm the public hostname and port that clients will reach, check that the certificate covers that name, and test the URL from a user workstation rather than from the Nextcloud server alone. Also decide whether the Collabora endpoint will sit behind the same reverse proxy as Nextcloud or on a separate hostname, because this affects the certificate, the proxy rules and the allow list you configure next.

The WOPI allow list tells the Collabora server which hosts may send it WOPI requests, and the Nextcloud manual recommends restricting those requests to the IP addresses of the Collabora servers. Make that list from the addresses the Nextcloud host actually uses to reach Collabora, not from addresses you assume. If Nextcloud sits behind a proxy or NAT, the address Collabora sees may be the proxy or the NAT gateway rather than the Nextcloud server, so the allow list must match what Collabora observes. Test a full open, edit and save cycle after every change. A changed IP address, whether from a cloud re-provisioning, a new NAT pool or a replaced load balancer, will break editing in a way that can look like a general outage. Record the addresses in your change process and ask your network team to notify the Nextcloud and Collabora owners before any network change.

Group rules control who can open documents in the editor and who can edit rather than only view. In Nextcloud Office, administrators can limit which groups can use the editor and which groups can edit. Map these rules to the Nextcloud group structure you already use for file sharing, not to ad hoc lists. Decide which groups need edit rights, which need view-only access, and which should have no access, then confirm how a user in several groups is treated. Check how group membership changes, such as a departing employee or a role change, reach the editor settings, and whether your directory-based group sync runs before users try to edit. Reviewing these rules alongside your existing sharing permissions avoids a case where a user can edit a file in the browser that policy says should be read-only.

Default file formats determine which document types open and which are created by default in the editor, and they are set in the Nextcloud Office configuration. This guide does not state those default values, so confirm which formats Nextcloud Office opens and creates by default in the current Nextcloud administration manual for your Nextcloud and Collabora versions before go-live. Then test a representative file set in each format: docx, xlsx, pptx, ODF, PDF, RTF, CSV and Visio. Collabora's product documentation lists support for these formats, but support for opening, editing, saving and round-tripping can differ, so test each path a user will take, including creating a new file, saving back to Nextcloud and downloading a copy. Use real business documents from your estate, with fonts and macros as your policy allows, and record which formats need user guidance or a follow-up fix.

Before go-live, run one short test plan covering the server URL, allow list and group rules together. Use one test account per group, confirm that view-only users cannot edit, and confirm that a user outside the permitted groups cannot open the editor at all. Keep a written record of the URL, the allow-list addresses, the group mapping and the tested formats, because these settings will be revisited during Collabora upgrades, network changes and staff moves. If your Collabora server is a dedicated instance rather than a built-in deployment, repeat the protocol and IP checks on that host as well, since each change to the proxy or address path can affect the whole integration.

Verification should prove three things before users rely on the integration: that Nextcloud reaches the agreed Collabora server over the agreed protocol, that only permitted hosts can open WOPI sessions, and that a failure produces a clear error instead of damaged files. Run these checks in a staging instance that mirrors production settings, then repeat the critical ones after go-live and after any change to the server URL, the WOPI allow list or the proxy in front of Collabora. Record each result as you go, because the evidence is what you will attach to the change record. Start with the server URL. In the Nextcloud Office settings, confirm that the Collabora server URL uses the same protocol as the Nextcloud installation, which the Nextcloud administration manual recommends as HTTPS. From a client on the user network and from the Nextcloud host itself, confirm that the name resolves to the expected address and that the certificate chain is trusted by both. Then confirm the WOPI allow list: from a host outside the permitted addresses, attempt to open a document session and verify that the request is refused. Use a test machine that is not in the allow list, and record the exact error returned.

Next, test each format the organization expects to edit. Open and save at least one file of each type you plan to support, including docx, xlsx, pptx, ODF formats, and any PDF, RTF, CSV or Visio files that users will open. For each one, check that the document renders, that edits save back to the same file in Nextcloud, and that the saved file opens correctly in the desktop application your users use. Confirm which formats open in the editor by default and which fall back to download, using the default file format settings you have chosen. Keep a short list of the files and versions you tested, since format results depend on the file as much as on the server. Permissions need separate tests. Using one account from each group that is allowed to edit and one from the view-only group, confirm that the editing account can change content and that the view-only account opens the document without edit controls and cannot save changes. Then test a user outside every allowed group and confirm they cannot open the editor at all. Check that the refusal is consistent when the user opens the file from the web interface, from a shared link and from the desktop client. Where Nextcloud Office group settings are used, record the group names exactly as configured, because a renamed group is a common cause of unexpected access.

Simultaneous editing needs its own test. Have two users open the same document and make edits in different paragraphs or cells, then confirm both changes appear for each user and that the document saves without losing either change. Next, have both users edit the same sentence or cell and confirm how the editor presents the conflict, then verify the saved result against the behavior your users have been told to expect. If you run more than one Collabora server behind a load balancer, confirm that both users reach the same backend for the same document, since routing by the WOPISrc parameter is what keeps co-editing working. Note any difference between the web and desktop clients.

Failure tests matter as much as success tests. Restart the Collabora service while a test document is open with unsaved edits, and confirm that Nextcloud shows a clear error or a reconnect prompt rather than silently discarding work or writing a partial file. Then make the Collabora server unreachable, for example by stopping it or blocking the connection at the proxy, and confirm that Nextcloud reports that the editor cannot be loaded. After service returns, verify that the test file opens, that its version history is intact and that no duplicate or zero-byte copies were created. Check Nextcloud and Collabora logs for each event so you know what an operator would see during a real outage.

Keep the test evidence for change records. For each test, store the date, the Nextcloud and Collabora versions, the configuration values checked, the accounts used, the file names, the expected result, the actual result and a screenshot or log excerpt. Mark any failure with the action taken and the retest result. Ask your implementation partner or internal team to confirm the version of every component in the record, because a result from a different point release does not prove the current configuration. Keep these records with the configuration baseline so that a later upgrade or proxy change can be tested against the same list.