How Collabora Online editing connects to GroupOffice
A team running GroupOffice that wants Word, Excel and PowerPoint style editing in the browser can add it without moving files to a third-party service. GroupOffice, built by the Dutch company Intermesh, integrates Collabora Online across its files, projects, contacts and email modules, and Collabora publishes a tutorial for integrating it with GroupOffice 26 using Docker. The connection itself follows the WOPI protocol, in which GroupOffice acts as the WOPI host that stores documents and Collabora Online renders and edits them in the browser. The exact connector settings, container arrangement and order of steps belong to Collabora's Collabora Online and GroupOffice integration page, so follow that tutorial and check each step against the GroupOffice 26 release you run rather than working from memory or from older guides.
Two licensing and support facts shape the plan. The Collabora Online server code is licensed under the Mozilla Public License 2.0, so the code you deploy is open source and can be inspected and modified under those terms. The free CODE image, however, is positioned by Collabora for testing, home use and small teams and is not recommended for production. Before a pilot becomes a production service, confirm with Collabora which edition and support level fits your user count and whether the Business or Enterprise plan applies, since the pricing page ties plan choice to the number of users. Ask your DeployOpen or internal team to confirm these points against the current Collabora pricing and release information at the time of rollout.
Prerequisites for the Collabora Online and GroupOffice integration
Four components have to be in place before the editor can open a document from GroupOffice: a running GroupOffice 26 instance, a Docker host for Collabora Online, encrypted connections between the servers and browsers, and a network path that lets each side reach the other. Check each one with your own team before you follow the tutorial, because the same choices decide whether editing works on the first attempt and whether it stays secure afterward.
A running GroupOffice 26 instance
The integration is documented for GroupOffice 26, so confirm your installation is on that release before you add the editor. Note which modules hold documents you expect to edit, such as files, projects, contacts and email attachments, because access to each module shapes who can open files. Take a backup and a snapshot of the current configuration first, since you will change settings that control how GroupOffice calls out to the editor. Confirm the resource needs of GroupOffice itself with your own sizing review, not from this page.
A Docker host and image choice
The tutorial uses Docker, so you need a host that runs containers and that your team can patch and monitor. Choose the image deliberately. The free CODE image (collabora/code) is a rolling release that Collabora describes as suited to testing, home use or small teams and not recommended for production. For production, compare the Business plan and the Enterprise plan on the pricing page, which lists long term support, a service level agreement and signed security updates for the Business plan. Ask the vendor which plan covers your user count before you commit.
HTTPS and certificates on both servers
Plan valid certificates for the GroupOffice site and for the Collabora server, and keep both on HTTPS. Browsers and the WOPI exchange both depend on trusted TLS, and mixed protocols between the two servers cause hard-to-trace failures. Decide who issues and renews the certificates, whether from an internal certificate authority or a public one, and make sure the Collabora hostname resolves to the address your users and GroupOffice will reach. Confirm which certificate authority your browsers and servers trust before you start the build.
Network paths in both directions
Two separate paths must work. GroupOffice must reach the Collabora server so it can request the editor and pass document access, and every user browser must reach the Collabora server directly to load the editing interface. Map the firewall rules, proxies and DNS entries for both paths, including any internal network segments that separate office users from the server room. Test each path with a plain connection check from the same network your users are on, not only from the administrator's workstation.
WOPI IP restriction
Nextcloud's guidance recommends restricting WOPI requests to the IP addresses of the Collabora servers. Apply the same discipline here: decide which addresses GroupOffice will call from, and limit which hosts can send WOPI requests to the Collabora server. Record the addresses in your change log, because a later change to a load balancer or NAT gateway can silently block editing. Ask whether your network setup places GroupOffice and Collabora on the same address range, since that changes the rule you write.
Configuring GroupOffice 26 with Collabora Online step by step
This sequence takes an administrator from a bare Docker host to a GroupOffice 26 installation where users open and edit office files in the browser through a Collabora Online server you run. Each step ends with a check so problems surface before users depend on the editor.
Prepare the Docker host
The administrator confirms that a Linux host with Docker is available, that the host can reach GroupOffice and that GroupOffice can reach the host on the port Collabora will use. Use the host requirements and Docker version stated in Intermesh's Collabora tutorial for GroupOffice 26, since those requirements are set by that source and not by this page. Check that the Docker engine runs and that the host resolves the name you plan to give the Collabora server. The step is complete when a test container starts and the host name resolves from the GroupOffice server.
Start the Collabora container
Run the Collabora Online container using the image and run options from the Intermesh tutorial. The free CODE image is published as collabora/code for x86-64, ppc64 and arm64, but copy the exact image tag, environment variables and port mapping from the source tutorial rather than from memory. Note that CODE is positioned for testing, home use or small teams and is not recommended for production, so choose a supported edition for live use. The step is complete when the container is listed as running and its logs show no fatal startup errors.
Set the server domain and TLS
Set the domain name that users and GroupOffice will use to reach Collabora, and configure TLS so the browser and GroupOffice both talk to the server over HTTPS. Copy the domain-related environment variables and certificate handling exactly from the Intermesh tutorial, because the names and expected values come from that source. Use the same scheme that GroupOffice uses, so mixed HTTP and HTTPS does not block editing. The step is complete when the server answers over HTTPS with a certificate that the browser trusts and the domain matches the name you configured.
Point GroupOffice at the discovery endpoint
In GroupOffice, enter the Collabora URL in the office or document editor settings so that GroupOffice can read the WOPI discovery endpoint that Collabora publishes. Copy the exact settings path and field values from the Intermesh tutorial, since menu labels differ between GroupOffice releases. Save the configuration and reload the administration page. The step is complete when the discovery endpoint loads in a browser and GroupOffice reports the editor as available.
Restrict WOPI access to your GroupOffice server
Limit which hosts can send WOPI requests to Collabora so that only your GroupOffice server can use it. Nextcloud's administration manual recommends the same idea, restricting WOPI requests to known IP addresses and using matching protocols. Apply the allow list method that the Intermesh tutorial and your Collabora edition support, and record the addresses you allowed. The step is complete when a request from an address outside the allow list is refused and a request from GroupOffice succeeds.
Enable editing per module
In GroupOffice, decide which modules offer document editing, such as files, projects, contacts and email attachments, and switch editing on for those modules only. Give editing rights to the groups that need them and keep view-only access for groups that only read documents. The Intermesh tutorial and the Collabora integration page describe which modules are covered, so confirm the list against your GroupOffice 26 installation. The step is complete when a test user in an editing group can change a document and a user in a view-only group cannot.
Test with documents in Writer and Calc
Create or upload a test .docx file and a test .xlsx file in GroupOffice, then open each in the browser. Confirm that Writer and Calc load, that two test users can see each other's changes, and that saved changes persist after a reload. Keep the test files, since they become the baseline for later upgrades and format checks. The step is complete when both files open, edit and save without errors across two sessions.
Running Collabora alongside GroupOffice on one host or a separate server
Running GroupOffice and the Collabora container on one machine is the fastest way to prove that editing works with your modules, files and users. Traffic between the two stays on the local Docker network, which keeps the setup simple and lets a small team confirm the WOPI handshake before committing hardware. The trade-off is that both services compete for the same CPU, memory and disk, so a heavy editing session can slow the groupware for everyone on the host.
- Network path: GroupOffice reaches the Collabora container over an internal Docker network, while browsers reach Collabora through a reverse proxy on the public name.
- Certificates: One certificate chain usually covers both services, but the Collabora server URL must match the protocol GroupOffice uses, so confirm HTTPS on both sides before testing.
- Failure isolation: A crash, out-of-memory event or disk fill affects the groupware and the editor together, so treat the pilot as non-production.
- Operations: The team that runs the GroupOffice host also runs the Collabora container, which keeps ownership simple but concentrates on-call duties.
- Limits: Confirm with the Collabora documentation for your release how many concurrent sessions the host can take before you move to a dedicated server.
Before you leave the pilot, check that the editor opens, saves and reloads documents from each module you plan to use, and record the host resources you saw under a realistic test load.
A dedicated Collabora server keeps editing load away from the groupware and lets each side be patched, restarted and sized on its own schedule. GroupOffice calls the Collabora server over the network, so the connection path, firewall rules and certificate handling become part of the design rather than an afterthought. Ownership usually splits between the team that runs GroupOffice and the team that runs the document service, and the handoff needs to be written down.
- Network path: Allow only the GroupOffice host to reach the Collabora server on the WOPI port, and restrict WOPI requests to known source addresses as the Nextcloud administration manual recommends for its own WOPI setup.
- Certificates: Issue a certificate for the Collabora hostname, use HTTPS between browsers and Collabora, and make sure GroupOffice trusts the issuing authority.
- Failure isolation: An outage on the Collabora server leaves documents readable in GroupOffice but blocks editing, so define how users are told and how the groupware falls back.
- Operations: Name a separate owner for the Collabora server, its patching and its security advisories, and agree on who receives alerts for each.
- Scaling: If you run more than one replica, the Collabora Helm documentation requires load balancers to route by the WOPISrc parameter so everyone editing one document reaches the same pod. Scaling is covered on the sizing page.
Before go-live, test the handshake from the GroupOffice host to the Collabora server, not only from a browser, and confirm the failure behavior with the team that will answer the alert.
Most organizations start on one host to validate the integration, then move the Collabora container when editing becomes a daily workload. The decision depends on expected concurrency, how much downtime the groupware can absorb, and whether separate teams own the two systems. Write the choice down with the reasons, so the move later is planned instead of improvised.
- Concurrency: Estimate peak editing sessions with the people who run the business processes, then compare that figure with the sizing guidance for your Collabora release.
- Downtime tolerance: Ask the groupware owner how long a loss of editing can last before users need a workaround.
- Ownership: Decide whether one team operates both machines or two teams share responsibility, and document the escalation path.
- Security scope: A separate server adds a network boundary to review, which can matter for audits and for restricted environments.
- Migration path: Confirm that you can move the container and update the GroupOffice Collabora address without re-creating documents.
Ask Intermesh and Collabora to confirm the GroupOffice 26 settings for your topology before you choose, because the supported configuration determines what you can actually run.
How GroupOffice modules map to Collabora editing and permissions
This table compares each GroupOffice area where users work with files, showing how a document opens in Collabora, which permission check applies, and what to confirm. The Intermesh integration page confirms editing across files, projects, contacts and email, but it does not document each module's permission behavior in detail, so treat the last column as a test list. The main takeaway is that module-level access should be verified in a test tenant before you promise it to a client.
| GroupOffice area | How a document opens in Collabora | Identity and permission check | What the operator must confirm |
|---|---|---|---|
| Files | Documents in the file manager open in the Collabora editor from the browser through WOPI, as described on the Intermesh integration page. | GroupOffice user session and the folder or file rights set in the file module. Confirm whether view and edit rights are enforced separately. | Test that a read-only share cannot save changes, and that edit rights on a folder carry to files inside it. |
| Projects | Project files attached to a project open in the editor from the project's file area, per the Intermesh page's project coverage. | Project membership and the file rights inherited from the project. Confirm whether removing a member revokes an open editing session. | Test a user removed from a project and check whether they can still save an open document. |
| Contacts | Documents linked to a contact record are listed as files and opened through the same file path, if linked files are supported in your version. | Contact-level visibility and the rights on the underlying file. Confirm which rights apply when a contact is shared with another user. | Confirm with Intermesh whether contact-linked files inherit contact permissions or only file rights. |
| Email attachments | Attachments saved to the file store can be opened in Collabora. Opening an attachment directly from a message may need a save step first. | The mailbox owner's account and the rights on the saved file. Shared mailboxes need separate checks. | Test an attachment in a shared mailbox and confirm who can open and edit the saved copy. |
| Browser session and WOPI host | Collabora receives a WOPI request from GroupOffice and returns the editor page to the browser. | The WOPI access token issued by GroupOffice for each session. Confirm token lifetime and revocation behavior in your version. | Confirm the Collabora server URL, HTTPS use and which hosts may call the WOPI endpoints on your network. |
| Collabora server access | The editor loads from your Collabora server, so users need network reach to it from their browsers. | Collabora does not decide who may open a file. It relies on the host's access token and checks. | Confirm firewall rules, TLS certificates and whether the WOPI host allow list covers the GroupOffice address. |
| Co-editing across modules | Two users opening the same file from different modules should reach the same document session on the same Collabora node. | Same file, same rights. Confirm this in a single server test before adding load balancing. | Test co-editing from a file view and a project view, and note any cases where sessions do not join. |
| Module coverage in your version | Coverage can change between GroupOffice releases, so the list above is a starting point. | Confirm each module's rights model against the GroupOffice 26 documentation for your installation. | Record test results per module and make them the basis for the client's acceptance criteria. |
Security controls for GroupOffice and Collabora Online
Once GroupOffice hands documents to Collabora Online, the security of the editing path depends on how the two systems trust each other. The controls below cover who can reach the Collabora server, how traffic is protected, who may edit rather than only view, and how patches and installers are verified. Some GroupOffice-specific settings must be confirmed against the current GroupOffice documentation before you rely on them.
Restrict WOPI requests by server address
Only the GroupOffice host should be able to send WOPI requests to Collabora, and only Collabora servers should be able to call back into GroupOffice. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers, and the same principle applies to any WOPI host. Check the WOPI allow list on the Collabora side and the firewall rules between the two systems, then confirm with a test from an address that should be blocked.
Match protocols end to end
Use HTTPS on both sides. The Collabora server URL and the GroupOffice address should use the same protocol, and HTTPS is the preferred choice for both. A mismatch can cause mixed-content blocks in the browser or documents that fail to open. Confirm the certificate chain the browser sees for the Collabora host, because the WOPI callbacks rely on the server trusting that certificate.
Separate edit rights from view rights
Access to open a document in the editor and the right to change it are different decisions. The Nextcloud administration manual describes limiting which groups can use the editor and which groups can edit rather than only view, and GroupOffice should be checked for an equivalent setting per module, such as files, projects and email attachments. Test with a read-only account in each module, since a document opened for viewing in one module may still be writable through another path.
Track Collabora security advisories
Collabora publishes security advisories for Collabora Online. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, which shows why point releases on your branch matter. Subscribe to the release notes, record which build runs in production, and schedule a window to apply fixes. Ask your GroupOffice contact which Collabora versions they test against before you update the editor.
Verify package signing keys on install
Collabora signs its RPM and DEB packages, and the 25.04 release notes record that the signing keys were updated for RPM and DEB users. Before installing or updating from a package repository, import the current key from Collabora's documentation and confirm its fingerprint against that source. Do the same for Docker images by pinning a tag and checking the digest. Repeat the check after each key rotation, because a stale key blocks updates or invites trust in the wrong key.
Confirm GroupOffice-specific controls
Some controls depend on GroupOffice features, such as how its file module passes documents to the editor, which users may open Collabora from each module, and how its Docker setup stores and forwards credentials. These details must be confirmed against the current GroupOffice documentation for your version, not inferred from Nextcloud. Ask Intermesh or your implementation partner to document each setting, then test the editor in every module you plan to enable.
Troubleshooting Collabora Online connections in GroupOffice
This table lists six common failures when GroupOffice hands documents to Collabora Online, with the likely cause, the check to run and the fix for each. Work through the rows in order, since the first two checks (reachability and protocol) explain many of the others. Where a cause depends on the GroupOffice or Collabora release in your environment, confirm it with Collabora support or the Intermesh documentation before changing production settings.
| Symptom | Likely cause | Check to run | Fix and when to escalate |
|---|---|---|---|
| Documents will not open | GroupOffice cannot reach the Collabora discovery URL, or the Collabora server cannot reach GroupOffice to fetch the file over WOPI | From the GroupOffice server, request the Collabora discovery page. From the Collabora host, request the GroupOffice WOPI endpoint. Check DNS names and firewall rules in both directions. | Correct the hostname, port or firewall rule and reload the integration settings. If both directions succeed but the editor still fails, confirm the expected GroupOffice configuration with Intermesh documentation. |
| Editor loads but cannot save | The WOPI host does not accept writes for that user or file, or the Collabora server cannot post changes back to GroupOffice | Open the same document as a user with edit rights, then check the GroupOffice and Collabora logs for PutFile or save errors around the time of the failed save. | Confirm the user's permissions in the module that holds the file, then confirm the callback address GroupOffice gives Collabora is reachable from the Collabora host. Escalate to Intermesh if the callback address is correct but writes still fail. |
| Mixed HTTP and HTTPS causing blocked frames | GroupOffice is served over HTTPS while the Collabora server URL uses HTTP, so the browser blocks the editor frame as mixed content | Compare the scheme of the GroupOffice URL and the Collabora URL in the browser console and in the integration settings. | Serve both over HTTPS with valid certificates and use the HTTPS Collabora address in GroupOffice. Mixed content cannot be fixed with a browser setting, so do not rely on user-side exceptions. |
| WOPI requests rejected by an allow list | The WOPI host allow list on the Collabora server does not include the GroupOffice address, often because the outbound IP or hostname differs from what was configured | Search the Collabora server log for WOPI host or allow list warnings and note the address it reports. Compare that address with the one GroupOffice actually uses, including any proxy or NAT. | Add the exact address or host the log reports to the allow list, then restart and retest. Keep the list as narrow as your network allows. Confirm the syntax for your Collabora version with Collabora's documentation. |
| Certificate trust errors between servers | The Collabora server does not trust the certificate presented by GroupOffice (often a private or internal CA), or the chain is incomplete | From the Collabora host, test the TLS connection to GroupOffice and read the verification error. Check whether the certificate includes the intermediate chain and whether the hostname matches. | Install the internal CA certificate in the trust store used by the Collabora container or host, or serve the full chain. Do not disable verification in production. Confirm the trust store location for your Docker or package install with Collabora support. |
| Missing fonts in rendered output | The Collabora server lacks the fonts used in the document, so layout and pagination differ from the desktop version | Open a document that renders incorrectly and list the fonts it embeds or requests. Compare with the fonts installed in the Collabora container or host. | Install the required fonts in the Collabora environment and restart the service. Check licensing for any proprietary fonts before installing them. Confirm font handling for your release with Collabora support if the problem persists. |
What a Collabora Online and GroupOffice integration costs and requires
What drives the effort of a GroupOffice and Collabora Online integration?
The main drivers are how many GroupOffice modules need editing (files, projects, contacts and email each raise the testing load), how many users will open and co-edit documents, and what infrastructure already exists. Existing TLS certificates, DNS records for the Collabora hostname, and firewall rules between GroupOffice and the editor all add work if they are missing. Running Collabora on the same Docker host as GroupOffice is simpler than a separate server, but a separate host changes network paths, certificates and sizing. Ask for the effort breakdown by module, user count and host layout, so each variable is priced separately.
Can a small team set up GroupOffice with Collabora using only the tutorial?
A technically capable team can often follow the Collabora tutorial for GroupOffice 26 on Docker, provided it has Docker experience, control of DNS and TLS, and time for testing. The tutorial covers the core wiring, but it does not replace checks for your own environment, such as certificate trust, the hostname the browser uses, and whether each GroupOffice module opens and saves documents correctly. Teams without that experience usually find the testing and access rules take longer than the initial setup. Decide in advance who owns the server after go-live, since updates and certificate renewals recur.
How much does a Collabora Online subscription cost for GroupOffice users?
Collabora Online itself is available as the free CODE edition, which Collabora describes as suited to testing, home use or small teams but not recommended for production. For production, the Collabora pricing page lists the Business plan at 3 euros per user per month for up to 99 users, including long term support, a service level agreement, signed security updates and customer portal access. Collabora quotes the Enterprise plan for 100 or more users with volume discounts, and it adds integration support, customization services and roadmap input. The subscription recurs monthly, so budget it alongside the one-time integration work. Confirm current terms directly with Collabora before you commit.
How long does a GroupOffice and Collabora Online integration take?
No duration is given here because the time depends on the module count, the number of environments (test and production), the TLS and DNS state, and whether testing covers real document types. A single-host Docker setup with one test pass will take far less time than a multi-module rollout with access groups and fidelity checks. Ask any provider for a schedule that lists each phase, its entry and exit criteria, and the testing window with real users. A fixed-scope written plan makes the schedule easier to compare across quotes.
What does the client need to provide before an integration starts?
Before work begins, the client should provide:
- A host or cloud account for GroupOffice and, if separate, for Collabora, with Docker or the chosen runtime available
- A DNS name and a TLS certificate for the Collabora server, plus a plan for renewal
- Network paths and firewall rules between the browsers, GroupOffice and Collabora
- A list of GroupOffice modules, user groups and who should be able to edit versus only view
- Sample documents in the formats the organization uses, for fidelity testing
- Named owners for approvals, change windows and post-go-live operations
Is GroupOffice with Collabora Online secure enough for regulated data?
Security depends on the controls you set, not on the integration alone. Restrict which hosts can reach the editor, use HTTPS on both sides, keep the editor patched using Collabora's advisories, and limit editing rights to the groups that need them. Regulated organizations should also map these controls to their own frameworks and have an independent auditor assess them, since DeployOpen prepares controls and evidence but does not issue audit reports or certifications. Ask any provider which hardening steps are in scope and which are left to your team.
Can DeployOpen support a GroupOffice and Collabora Online integration?
DeployOpen can plan, implement and document a GroupOffice and Collabora Online integration inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to list the modules, environments, testing and handover items so the quote can be compared with an internal estimate.
What should a quote for this integration include?
A useful quote lists each deliverable separately: infrastructure preparation, the Collabora deployment, GroupOffice configuration, module testing, access group setup, documentation and handover. It should state what is one-time and what recurs, including subscription fees, support retainers and certificate renewals. Ask which assumptions the price depends on, such as user count and host layout, and what changes trigger a new quote. Confirm who pays for third-party subscriptions and whether testing includes your own sample documents.
How DeployOpen scopes and delivers this integration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For GroupOffice, that means treating the Collabora Online server, the WOPI connection from GroupOffice and the document modules as one system with a written scope agreed before work starts.
How we scope
- Confirm the GroupOffice 26 deployment, modules in use and which groups should edit or only view documents.
- Record where the Collabora Online server will run, its network path to GroupOffice and the hostnames and TLS setup.
- Agree the written scope, deliverables and timeline before any build work, with ongoing support available as a retainer.
How we build
- Deploy the GroupOffice Docker setup and Collabora Online in your environment, following the Collabora and Intermesh integration tutorial.
- Configure WOPI access so only the intended hosts reach the Collabora server, and verify editing across files, projects, contacts and email.
- Test document fidelity with your own Office and OpenDocument files, and size the server against the concurrency you expect.
How we hand over
- Deliver runbooks for the Docker stack, certificate renewal, update steps and rollback for both GroupOffice and Collabora.
- Document access rules, group permissions and the checks used to confirm the integration after each change.
- Walk your administrators through daily operation and the points where they should escalate to DeployOpen or their own team.
How we support
- Plan Collabora Online and GroupOffice updates as a scoped task, including checks against the Collabora release notes before upgrading.
- Offer retainer support for monitoring, patching, incident response and periodic re-testing of editing workflows.
- Confirm the support boundaries, response expectations and any SLA terms in writing before the retainer starts.
