How the Collabora Online Drupal integration keeps Drupal in charge of access
A Drupal team that wants Word, Excel and PowerPoint files edited in the browser without leaving the site can use the Collabora Online module, which connects Drupal to a self-hosted Collabora Online server over WOPI and reuses Drupal users and permissions. WOPI, the Web Application Open Platform Interface protocol, is how the host hands a document to the editor: Drupal tells the editor where the file lives, grants the access that lets it open in the browser, and receives the saved changes back. Collabora Online is built on LibreOffice technology, and its server code is licensed under MPL-2.0, so you run the editor yourself. The free CODE edition suits testing and small teams, and Collabora does not recommend it for production, so plan on a supported server for anything users depend on. You can read more on the Collabora Online product page.
The central decision is who can do what, and that answer should stay in Drupal. Users sign in to Drupal, and the module's checks should decide which files a person may open at all and which they may edit rather than only view. Map each Drupal role to an explicit outcome before rollout. For example, in an illustrative setup, an editorial role might edit draft documents while an authenticated role only views published ones. Then test that matrix with dedicated test accounts from each role, including an account removed from a group, to confirm that access ends when Drupal permissions change. Ask the module maintainers to confirm how these checks apply to files in private storage as well as public storage, and record their answer in the pilot plan.
What must be in place before installing the Collabora Online module
The Collabora Online module for Drupal sits between a Drupal site, a Collabora Online server and the browsers of your editors. Each card below is a prerequisite that has to hold on both sides of that connection before you install anything, and several of them depend on dates and versions you should confirm when you plan the work.
A supported Drupal 10 or 11 site
Start with a Drupal 10 or Drupal 11 site that you can update on your own schedule. Drupal 10 reaches end of life on December 9, 2026, so a Drupal 10 site installed today needs a dated plan to move to Drupal 11 before that date, and Drupal 12 requires PHP 8.5 or later. Confirm which core version your site runs and whether your contributed modules support it, because the Collabora module must be compatible with the same core line you choose.
PHP version that matches your Drupal core
The PHP runtime sets the floor for your Drupal version. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later, and no supported Drupal version runs on PHP 7. Check the PHP version on every web node that serves Drupal, including staging and any cron or Drush hosts, because a node with an older runtime will fail in ways that look like module bugs. Record the version in your change request so the upgrade order is clear.
A supported database engine
Drupal runs on MariaDB, MySQL, PostgreSQL or SQLite. Choose the engine your operations team can back up, restore and patch, and confirm that the version is one Drupal supports for your core release. SQLite suits small test sites rather than production editing workloads, so use it only for a lab. Make sure the database and the Drupal file system are in the same backup set, because document permissions and file references depend on both.
Apache or Nginx in front of Drupal
Drupal runs on Apache or Nginx, and the web server configuration decides how WOPI traffic and document downloads reach PHP. Confirm the server's URL rewriting, upload size limits and timeouts before you test, because a large Office file that uploads or saves slowly will show up as an editor failure. Keep the configuration in version control so that the same settings can be reproduced on a rebuilt server.
A production Collabora Online server
The Drupal module needs a Collabora Online server that browsers can reach and that the Drupal server can reach too. Do not point a production site at the free CODE edition, which Collabora describes as not recommended for production. Size the server for your real concurrency using the scaling guidance for Collabora Online, and decide whether one server is enough or whether you need WOPISrc-aware load balancing. Ask who patches the server and how security advisories reach your team.
HTTPS on both sides of the connection
Serve Drupal and Collabora Online over HTTPS, and use the same protocol for the Collabora server URL as for the Drupal site. Certificates must be trusted by the browsers and by the Drupal server, which calls the WOPI endpoints itself. Plan certificate renewal and check that internal certificate authorities are trusted on every node. Mixed content or an untrusted certificate typically shows up as a blank editor frame, so test from a clean browser profile.
A named owner for beta status
The Collabora Online module is in beta and has not had a security review, so production use needs an accountable owner before installation. Name a person who tracks the module's release notes, reviews its issue queue, decides when to pin or roll back a version, and signs off on the risk. Ask the Drupal team to confirm the module's current version and compatibility on its project page, and write down the date you checked so that the decision is traceable.
How Drupal users, roles and permissions map to editing rights
This table compares the Drupal objects that decide who can open, view and edit an office document through the Collabora Online module. Read each row as a question to answer in your own test site before production, because the module's exact permission names and mapping must be confirmed in its documentation. The main takeaway is that a user can edit only when Drupal grants access to the document entity and the editor permission, so test every role, not only administrators.
| Drupal object | What the module uses it for | Editing outcome | What to verify |
|---|---|---|---|
| User accounts | Identify the person opening the document and tie the WOPI session to a Drupal user | Each session acts as the signed-in user, so edits are attributed to that account | Open the same document as two different users and confirm the author and session identity shown in the editor |
| Roles | Group users so that permissions can be granted in bulk | Role membership decides whether the Collabora editing permissions apply | Confirm which roles receive view and edit permissions and that a user with two roles gets the expected result |
| View permission | Controls whether the editor opens the document read-only, if the module offers this distinction | Users with view-only rights can read but not change the file | Confirm the permission name in the module configuration and test a view-only role with an edit attempt |
| Edit permission | Controls whether the user can save changes back to Drupal | Users with edit rights can change and save the document | Confirm the exact permission name and check that saved changes appear in the file entity revision history |
| File entity or media field | Holds the document and its access checks | Access to the file entity or media item determines whether the editor loads at all | Check that private files, unpublished media and restricted fields do not open for users outside the intended group |
| Anonymous users | Unauthenticated visitors with no Drupal account | Editing should not be available to anonymous users unless you have deliberately configured it | Confirm the anonymous role has no editor or edit permissions and try to open a document URL while logged out |
| Blocked accounts | Accounts disabled in Drupal that may still hold an active browser session | Blocked users should lose editing access once the account is disabled | Block a test account during an open editing session and confirm that new and existing sessions stop working as expected |
Collabora Online Drupal integration setup sequence
This sequence takes a Drupal site from a Collabora Online server that answers over HTTPS to a tested setup where users open and edit office documents according to their Drupal roles. Each step ends with a check, so the staging run shows what works before any production decision.
Stand up Collabora Online over HTTPS
The infrastructure team deploys Collabora Online from a Docker image, system packages or Kubernetes in infrastructure you control, with a certificate that matches the hostname Drupal will use. Use CODE only for testing, since Collabora does not recommend it for production. Confirm the discovery endpoint path in Collabora's deployment documentation, then request it over HTTPS from the Drupal server's network. Done when the response is an XML discovery document that lists the supported file types, and the same request succeeds from a browser on a client network.
Install the module in a staging site
The Drupal team installs the Collabora Online module and its dependencies on a staging copy of the production site, not on live content. Use Drupal 11 for new work, since Drupal 10 reaches end of life on December 9, 2026. Drupal 10 needs PHP 8.1 or later and Drupal 11 needs PHP 8.3 or later, so check the PHP version first. Read the module's documentation, release notes and open issues, because the module is in beta. Done when the status report shows no unmet requirements and the module enables without errors in the logs.
Enter the Collabora server URL
The Drupal administrator enters the Collabora server address in the module's settings, using the same protocol as the Drupal site. If Drupal runs on HTTPS, the Collabora URL must also use HTTPS, or the browser will block the editor frame. Confirm the exact setting name and location in the module documentation before editing. Done when the settings save and the module reports a successful connection to the server, or when a test document opens in the editor without a mixed-content or certificate error in the browser console.
Restrict WOPI requests to Collabora addresses
The web or network team limits calls to Drupal's WOPI endpoints so that only the Collabora server addresses can reach them, using web server rules or firewall policy. Nextcloud's administration manual recommends the same approach for its Collabora connection. If a load balancer or NAT sits between the servers, confirm which source address Drupal actually sees, because the rule must match that address. Done when a request to the WOPI endpoints from an unlisted host is refused, and documents still open from the Collabora server.
Map roles to view and edit permissions
The Drupal administrator decides which roles can open documents in the editor and which can edit them, then sets those permissions using Drupal's standard user and role model. Keep the mapping small and confirm the permission names in the module documentation. Create one test account for each role, including one with no editor access. Done when the written role matrix matches what each test account can do in the next step, and the matrix is approved by the people who own the content.
Test with sample documents and roles
The QA or content team uploads sample files in formats the business uses, such as docx, xlsx, pptx and odt, to the staging site. They open each file with the view-only account, the editing account and the no-permission account. Save an edit, reopen the file, and check layout, tables and images. Review the Collabora and Drupal logs for errors. Done when view-only sessions stay read-only, edits save and persist, the no-permission account is refused, and the results are recorded before any production decision.
Securing the Collabora Online Drupal integration
The Collabora Online module ties document editing to Drupal's users and permissions, so the controls below sit at two edges: the network path between Drupal and Collabora, and the Drupal and Collabora software you keep patched. The module has no completed security review, so your team must run its own review or testing before production.
Restrict WOPI traffic to Collabora
Limit WOPI requests from Collabora to the Drupal site to the IP addresses of your Collabora servers, and block everything else at the firewall or reverse proxy. Nextcloud's administration guidance recommends the same control for its WOPI traffic, and the principle applies equally to a Drupal host. Confirm with your network team how outbound addresses behave behind NAT or a cloud load balancer, because a changed address will silently break editing.
Serve the Collabora URL over HTTPS
Use HTTPS for the Collabora server URL and match the protocol used by the Drupal site. Mixed protocols cause browser content blocking and WOPI errors, and editing traffic carries document content and access tokens. Check certificate validity, chain completeness and renewal automation for both the Drupal host and the Collabora ingress before go-live.
Limit editing to named roles
Drupal permissions decide who can open and edit documents, so grant the editor and edit capabilities to named roles only, not to every authenticated user. Map each role to the content types and file fields where documents live, and test with a non-administrator account. Keep view-only access separate from edit access so readers cannot change approved documents.
Patch Drupal on the published schedule
Drupal core and contributed modules, including the Collabora Online module and its dependencies, need patches on the monthly bugfix release and on security releases. Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday. Agree a patch window that covers both, and test document editing after each update because a core upgrade can change the module's behavior.
Subscribe to Drupal Security Team advisories
Subscribe the operations owner to Drupal Security Team advisories so that any issue affecting Drupal core or a module on your site reaches a named person quickly. Record which modules are installed and their versions in your change log, so you can tell within minutes whether an advisory applies. Decide in advance who approves emergency patches outside the normal schedule.
Track Collabora security advisories
Collabora publishes security advisories for Collabora Online, and the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Track advisories for the branch you run, apply the fixed point release, and confirm that package signing keys are updated on RPM or DEB hosts. A Drupal patch does not replace a Collabora patch, so watch both lists.
Beta status and missing security review: what to weigh before production
A pilot on public or internal documents is a reasonable way to learn how the Collabora Online module behaves with your Drupal users, roles and Collabora server. It is a test of the integration, not a production dependency, and the pilot's scope should keep any failure or exposure away from anything you would not publish anyway.
- Limit the content: use only documents already classed as public or internal, with no personal data, contracts or records under retention rules.
- Read the module status: check the release history, the open issue queue and the beta label on the module's project page on the day the pilot starts, and record what you saw.
- Test permissions: create test accounts for each Drupal role and confirm who can view and who can edit, including users who should be blocked.
- Check the Collabora side: confirm the server version, TLS and reachability following the Collabora Online deployment guidance for your host.
- Log fidelity and defects: record formatting losses in Word, Excel and PowerPoint files, data loss and errors so the production decision rests on evidence.
Before the pilot closes, decide whether the findings justify the review in the production tab or whether a supported Collabora-backed WOPI host, such as Nextcloud, should be evaluated instead.
Production means the module becomes part of how regulated or personal data is opened and changed. The main gap is the missing security review. No independent review result is available to you, so your team, or a tester you commission, has to produce the evidence that the maintainers have not supplied. Access control in this case is the question that matters most: can a user reach a document their Drupal permissions should block?
- Security test the integration: test the module, its WOPI endpoints and its access checks, including attempts to open or edit documents from accounts without rights.
- Map the dependency chain: list Drupal core, the contributed modules, the Collabora server and the operating system, and subscribe to advisories from the Drupal Security Team.
- Restrict and encrypt WOPI traffic: limit which hosts can call the WOPI endpoints and enforce HTTPS between Drupal and the Collabora server.
- Record the risk decision: document who approved the risk, what is accepted, the conditions for review and the review date. Auditors and certification bodies will assess this record, and neither DeployOpen nor the module supplies it.
- Assign patch ownership: name who applies module and Collabora updates, who watches advisories and how quickly a fix must go live.
Confirm whether your compliance obligations accept a contributed module without a published review, or whether a supported Collabora-backed host would meet the requirement with less custom risk.
A Drupal 7 site cannot be made current by adding an editing module, so the integration decision follows the migration decision. Drupal 6 and 7 sites are not upgraded in place. They are migrated into a new site with the core Migrate modules or Drush, and themes are rebuilt. Drupal 7 security support ended on January 5, 2025, and the Drupal Association's extended support program lists certified vendors for sites that cannot migrate yet. For a Drupal 8 site, confirm its support status on Drupal.org before relying on it.
- Confirm the support window: if the site cannot migrate on schedule, compare the extended support providers listed by the Drupal Association before accepting unsupported code.
- Choose the target version: Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so test the Collabora module on the version you will run after migration.
- Check PHP requirements: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later.
- Avoid new dependencies on the old site: adding the integration to a platform being replaced creates work you will repeat after the move.
- Plan the test window: schedule the security test and pilot on the target build so the production decision uses the final codebase.
Ask whether the migration timeline, the target version and the Collabora test can be agreed together in one written plan.
Testing document fidelity, permissions and failure handling before go-live
Run four test groups before the Drupal site goes live: document fidelity, the permission matrix, concurrency and an upgrade rehearsal. Start with document fidelity, using samples drawn from the real content mix rather than generic files. Include .docx, .xlsx and .pptx files that carry tracked changes, comments, embedded images, custom styles, named ranges and formulas, plus PDF, RTF, CSV and ODF samples. Open each one in the editor from a Drupal node, edit it, save it, then reopen it in the original application and compare layout, pagination, fonts, charts and formulas. Collabora's product page lists the formats it supports, but support for a format does not prove that your documents survive a round trip, so record the differences you accept and the ones that block go-live. Confirm with your content owners which fonts and macros appear in those files.
Next, build a permission matrix with one row per Drupal role, plus anonymous users and a blocked account. For each row, test whether the user can see the editing entry point, open a document in view mode, edit it and save. The module reuses Drupal users and permissions, so the matrix should show that a user who cannot view a node cannot reach the editor through a direct WOPI URL either. Also check what happens when an account is blocked during an open session, because the editor may keep a session alive until the token expires. Confirm with the module documentation and the Collabora and host settings how access tokens are issued and how long they last in your version, and record that behavior as a finding. Run the matrix against the Nextcloud-style group restrictions only if you are also deploying those, and do not assume they exist in Drupal.
Run concurrency tests with two or more editors on the same document, and run them through the production routing design, not a single test server. The Collabora Online Helm chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, and that load balancers must route by the WOPISrc parameter so all editors of one document reach the same pod. Test that routing with your actual ingress, confirm that a second editor joining mid-session lands on the same backend, and check that a pod restart or failed health check produces a clear error rather than silent divergence. Then run a rehearsal of the upgrade path: restore a copy of production into a staging site, upgrade Drupal core and the module together, and repeat the fidelity and permission tests. Drupal core releases follow a published schedule, so rehearse against the version you will actually run. Store every result, with dates, versions, document samples and reviewer names, as go-live evidence, since auditors and your own change board will ask for it.
Common failures in the Collabora Online Drupal integration
This table pairs each failure a team is likely to meet when connecting Collabora Online to Drupal with its probable cause and a check to run. Work through it in order during testing, since the first rows are the cheapest to verify. The main takeaway is that most failures trace back to URL protocol, WOPI reachability, role mapping or version drift, and each can be confirmed before users depend on the editor.
| Symptom | Likely cause | Fix or check to run |
|---|---|---|
| The editor does not load when a user opens a document | The Collabora server URL uses a different protocol from the Drupal site, for example HTTP on one side and HTTPS on the other | Confirm the Collabora URL and the Drupal site use the same protocol, preferably HTTPS on both, and correct the module setting to match |
| Editing requests from Collabora fail or time out | A WOPI IP allow list on the Drupal side or in front of it omits the address the Collabora server uses | List the outbound addresses of each Collabora server, add them to the allow list, then open a test document from a clean browser session |
| Documents open read-only for users who should edit | Drupal roles are mapped to view-only permissions, or the module's edit permission is not granted to the role | Compare the user's role against the module's view and edit permissions, grant edit only to roles that need it, and test with one account per role |
| Users see the editor for documents they should not reach | Access checks rely on the file entity's view permission, which is not set on the node or media item holding the file | Test with an account that lacks access to the entity, confirm the request is refused, and review access rules on the content type |
| Saved changes appear in the wrong entity or the save fails with no message | The file is linked to a different entity revision than the one the user opened, or the save path is blocked by file permissions on the Drupal server | Open the saved document from the entity page, check the file's revision and the web server's write permission on the file directory, then repeat the edit with a test file |
| The editor stops working after a Drupal core update | The contributed module was not updated alongside core, or it targets a Drupal version range that does not include the new core release | Check the module's supported core versions before updating core, update the module in the same change, and keep a staging copy for regression tests |
| The module refuses to install or pages error after a move to Drupal 10 or 11 | The PHP version on the server is below the minimum for the Drupal version: 8.1 for Drupal 10 and 8.3 for Drupal 11 | Run the PHP version check on the web server itself, not only on the workstation, and upgrade PHP before enabling the module |
| Co-authors do not see each other's edits or get stale content | Requests for one document are routed to different Collabora servers because the load balancer does not route by the WOPISrc parameter | Configure the load balancer to send all requests for one document to the same server, then test two browser sessions editing one file at once |
Questions teams ask before hiring help for Drupal and Collabora Online
What drives the cost and effort of a Drupal and Collabora Online project?
The largest cost is design and verification work, not software licenses, because Drupal and the Collabora Online server are both open source. The effort usually splits into six parts: evaluating the Collabora Online module, building and hardening the Collabora server, designing permissions so Drupal roles map to editing rights, testing document fidelity and co-editing, reviewing security, and planning upgrades. Build and setup work is mostly one-time. Upgrades, server patching, subscription fees and support recur. Effort rises with the number of content types, file formats, roles, and Drupal sites, and with the depth of the security review. Ask for a written scope that lists each part as a separate line with its deliverables, so you can compare quotes on the same basis.
What does Collabora Online cost for a production server?
Collabora Online has a subscription cost for production, and the free CODE edition is not recommended for production use. The published Business plan costs 3 euros per user per month for up to 99 users. It includes long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan, for 100 or more users, is quoted with volume discounts and adds integration support, customization services and roadmap input. The subscription recurs monthly per user, so your user count and growth drive the total. Ask for the seat count, the plan tier, and whether the quote covers the Drupal integration support you expect. Confirm current terms on Collabora's pricing page before budgeting.
Can our team run a Drupal Collabora Online integration without outside help?
Yes, if your team has the right skills and time, but the work spans two systems. Drupal administration includes module configuration, role and permission design, and upgrade experience with contributed modules. The Collabora side needs Linux administration, a reverse proxy, TLS certificates, Docker or system packages, and network paths between Drupal and the Collabora server. Someone also needs to test documents across formats and own the security decisions. Teams without this mix often underestimate testing and upgrades. A practical check is to name an owner for each skill area and run a pilot on a staging site before committing to production. Your team can also take over ownership after a partner builds the system, if the handover is written into the scope.
How long does a Drupal and Collabora Online integration take?
The duration depends on the written scope, so no fixed timeline applies to every site. The main drivers are the number of Drupal sites and content types that open documents, the number of roles to map, the file formats your users need, whether the Collabora server is new or already exists, and how much security review and testing you require. If your site runs Drupal 10, plan around its end of life on December 9, 2026, because a Drupal upgrade can run alongside or before the integration. Ask for milestones with dates agreed in writing, a test plan with exit criteria, and a list of dependencies on your team, such as DNS changes, certificates, and approvals.
Is the beta Collabora Online module safe for production Drupal sites?
A beta module can run in production only after you weigh its maturity against your risk tolerance, and no security review is listed for it. Check the module's release status, open issues, maintainer activity, and how quickly fixes arrive. Confirm whether the module has been through a security review and how vulnerabilities are reported. Drupal's Security Team handles core and contributed project issues, but a listed security review is a separate check. If you proceed, limit the first release to a pilot group, restrict who can edit, keep the Collabora server patched, and set a go or no-go decision point. Document the decision and the compensating controls so your approver can accept the residual risk.
What must we provide before an integration project starts?
You need to provide access, an environment, sample content, a role model, and an approver before work begins. Drupal access includes staging and production admin accounts and the code repository. The server environment includes host or cluster capacity, DNS names, TLS certificates, the reverse proxy or ingress path, and firewall rules between Drupal and the Collabora server. Content samples should cover each file type and a realistic mix of document sizes, so testing is meaningful. The role matrix should state which Drupal roles can open, edit, and manage documents. Finally, name one approver who can accept the scope, sign off on test results, and decide on go-live. Missing items usually delay the schedule more than technical problems do.
How DeployOpen scopes and delivers the Collabora Online Drupal integration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For the Collabora Online Drupal integration, we start with a written scope that settles the Drupal version, the module status and the security review question before any build begins.
How we scope
- Confirm the Drupal 10 or later version, PHP version and web server stack the site runs on
- Record which document types, user groups and Drupal roles may open and edit files
- Agree in writing whether the beta Collabora Online module is accepted or a different approach is used
- Define the Collabora Online server location, network path and TLS requirements for your environment
How we build
- Install and configure the Collabora Online server and the Drupal module in a staging environment
- Map Drupal users and permissions to editing rights and test each role against real document types
- Test co-editing, file save behavior and document fidelity with your existing office files
- Apply access restrictions and proof of the WOPI host allow list before moving to production
How we hand over
- Document the configuration, permission mapping, update steps and rollback procedure for your team
- Provide test results covering document types, roles and failure cases agreed in the scope
- Walk your administrators through routine checks, module updates and Drupal core upgrade impact
- Deliver the written record of residual risks, including the open security review question
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainer scope covers Drupal core and module update testing against the Collabora Online server
- Review Collabora Online security advisories and plan patch windows with your operations team
- Coordinate with your independent auditors when compliance evidence is needed for the integration
