How the Collabora Online Nuxeo integration opens and co-edits files
If you run Nuxeo for document management and want Office and ODF files opened and co-edited in the browser, the Collabora Online Nuxeo integration uses the WOPI protocol and Collabora's Nuxeo addon to connect Nuxeo to a Collabora Online server you control. Collabora lists Nuxeo among its WOPI integrations, so this is a documented integration path. DeployOpen plans and builds the connection, the WOPI host settings in Nuxeo and the hosting of the Collabora editor in your infrastructure. The exact addon package, the versions that match your Nuxeo release and the configuration steps come from Collabora's documentation, so confirm them for your release before scoping the work.
When a user opens a file, Nuxeo acts as the WOPI host. It gives the browser a launch address for the Collabora server, and the Collabora server then calls back to Nuxeo to read file information and fetch the file content. Saves travel the same way in reverse. The decisions to make early are which Nuxeo permissions allow opening, which allow editing, and how the addon maps those permissions to the read-only and editable states the editor receives. Ask Collabora or the addon documentation exactly how each Nuxeo permission and group is translated, and test with a read-only user and an editing user before rollout.
Co-editing depends on every session for one document reaching the same editing instance. On a single Collabora server this happens by default. In a clustered deployment, the load balancer must route requests by the WOPISrc parameter so that all users editing one document reach the same pod. 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. Plan capacity in advance, and test with several users editing the same file at once, including copy and paste between sessions.
The connection needs both directions to work securely. Browsers must reach the Collabora server, and the Collabora server must reach Nuxeo's WOPI endpoints. Use HTTPS on both sides with matching protocols, and manage certificates for each name. Where the addon allows it, restrict WOPI callbacks to the Collabora server addresses. The Nextcloud administration manual recommends this pattern for its own WOPI setup, but whether the Nuxeo addon supports an equivalent restriction must be confirmed with Collabora. Also plan how you will apply Collabora Online point releases and security fixes, because the Nuxeo connection must keep working through each update.
Before you commit to a timeline, confirm four things with Collabora and your Nuxeo team: the addon package and version for your Nuxeo release, the Collabora Online release line you will run, which Office and ODF formats your document types need in the editor, and whether your reverse proxies, load balancers and firewalls pass WOPI traffic without altering the WOPISrc parameter or the request headers. Each answer changes the build sequence, so record them in the written scope.
What you need in place before connecting Nuxeo to Collabora Online
Six items must be in place before anyone installs the Nuxeo addon or points it at a Collabora server. They depend on each other: your Nuxeo release determines which addon version you can use, and the server name and certificates determine whether the editor loads in users' browsers. Confirm the addon version against your Nuxeo release with Collabora before scheduling any work.
Supported Nuxeo release and admin access
Confirm which Nuxeo release your platform runs and that the Collabora Online addon is built for that release. Ask Collabora to confirm the addon version against your release before any work is scheduled, since the addon and the Collabora server must agree on the versions they support. Your team also needs administrator access to install the addon, change its configuration, and restart services in every environment, including staging, so that changes can be tested before production.
Production-grade Collabora Online edition
Choose a supported Collabora Online edition for production use. Collabora does not recommend CODE, its free edition, for production. Supported editions include long term support, a service level agreement, signed security updates and customer portal access, according to Collabora's pricing page, which matters when Nuxeo users open business documents every day. Confirm the edition, server version and support terms in writing before you size the server.
HTTPS name for the Collabora server
Give the Collabora server a stable HTTPS name that both Nuxeo and users' browsers can resolve. Nuxeo passes this address to the editor, so the name must match the certificate and be reachable from every browser that opens a document. Decide whether the name is public or internal, and use the same protocol for the Collabora server URL as for Nuxeo, preferably HTTPS, in line with the WOPI guidance in the Nextcloud administration manual.
Certificates trusted by both systems
Nuxeo must trust the certificate presented by the Collabora server, and the Collabora server must trust the certificate that Nuxeo presents on its WOPI calls. If either side uses an internal certificate authority, install its root certificate on both systems, including any container images or Java trust stores that run the addon. Add these certificates to your renewal calendar, because an expired certificate can stop editing for every user at once.
Network paths between Nuxeo, editor and users
Map every path before installation: Nuxeo to the Collabora server for WOPI calls, the browser to the Collabora server for the editing session, and the browser to Nuxeo for document access. Allow these flows through firewalls, reverse proxies and load balancers, and confirm the ports with your network team. Load balancers must route by the WOPISrc parameter so all users editing one document reach the same pod, because the Helm chart disables horizontal autoscaling for this reason.
Named owner for the addon
Assign one person to own the Nuxeo addon, its version and its upgrade path. The owner tracks Collabora security advisories, such as the 25.04 release notes entry for CVE-2026-23623, and package signing key changes that affect RPM and DEB installations. They also coordinate Nuxeo and Collabora upgrades so the addon stays on a supported pairing. Without a named owner, the addon can fall behind the Nuxeo release it was built for.
How WOPI carries file access between Nuxeo and the editor
In a WOPI setup, Nuxeo is the host that holds the file, and Collabora Online is the editor that displays and changes it in the browser. When a user opens a document, Nuxeo does not simply pass the file to the browser. It builds a request to the editor that includes a WOPISrc parameter, which is the address the editor uses to call back to Nuxeo for that specific file. The editor then fetches the content from Nuxeo and sends saves back through Nuxeo. Confirm in Collabora's Nuxeo documentation exactly how the addon builds this request, which paths the editor calls and which operations it performs. Do not assume that generic WOPI endpoint names match what the addon implements.
Before any file is opened, the editor publishes a discovery document that lists the file types it can open, edit or view, along with the URL templates it uses for each action. Nuxeo relies on this information to decide which documents can be offered for editing in the browser. Your first technical check is to compare the formats listed by your Collabora Online version with the file types your Nuxeo repository actually holds, including OpenDocument files and Microsoft formats such as docx, xlsx and pptx. Also confirm that the public address of the editor matches the address your users reach, because the discovery document and the URLs inside it must resolve correctly from the browser and from Nuxeo.
Every call from the editor back to Nuxeo carries an access token that identifies the user and the document. Nuxeo checks that token on each request, not only when the document is first opened. This means the session is a live control, and access can end in the middle of an editing session. Decide how long tokens remain valid, how Nuxeo revokes them when a user is removed or a document is locked, and how quickly the editor stops saving after that point. Confirm these behaviors with Collabora and Nuxeo, and test them with an open editing session, because the outcome depends on the addon version you deploy.
The host, not the editor, decides who can open a document and who can edit it. The editor enforces only what the token permits, and it does not read Nuxeo's access control lists directly. Map Nuxeo permissions, such as read and write on a document, to the view and edit capabilities the addon sends to the editor. If that mapping is loose, a user with read access could end up with edit rights. Build a test set with a reader, a contributor, a user with no access and a locked document, then confirm in the addon documentation which permission each case produces before you roll the integration out to users.
Configuration sequence for connecting Nuxeo to Collabora Online
This sequence connects a Nuxeo test environment to a self-hosted Collabora Online server, then carries the same configuration into production. Each step closes with a check, so problems surface while they are still cheap to fix. Confirm every setting name against Collabora's documentation and the addon documentation before you enter it.
Confirm versions and addon compatibility
Before any installation, record the Nuxeo version, the Collabora Online release and the Collabora addon version you plan to use, then check them against the addon's compatibility matrix. Collabora Online 25.04 is still receiving point releases, and 26.04 is the newer release, so confirm which branch your support terms cover. Ask the addon publisher and Collabora which combinations they test. The check is complete when you hold a written list of approved versions that the team has signed off.
Deploy Collabora Online behind HTTPS
Deploy the Collabora Online server in an environment you control, using Docker images, system packages or Kubernetes, according to your platform standards. Serve it over HTTPS on a hostname that will not change, because the addon configuration stores that address and a certificate tied to a changing name causes breakage later. If you run several replicas, route requests by the WOPISrc parameter so every user editing one document reaches the same pod, and keep autoscaling off, since Collabora's Helm chart documentation warns that scaling breaks collaborative editing. Check: the server answers over HTTPS with a valid certificate for the hostname you chose.
Confirm the discovery URL from Nuxeo
From the Nuxeo server or container, request the Collabora discovery URL using the same protocol and hostname you plan to use in production. The discovery response lists the file types and actions the server supports, so it also tells you which formats can open. Run the request from the Nuxeo network segment, because a path that works from an administrator's workstation can fail behind a proxy or firewall. Check: the response returns from Nuxeo itself, and every file type you need appears in it.
Install and configure the Collabora addon in test
Install the Collabora addon in Nuxeo's test environment only, then set the Collabora server URL, the discovery URL and the file types it should open. Confirm each setting name in the addon documentation and in Collabora's WOPI guidance before you enter it, because names can change between addon releases. Record every value in your change log so production matches test exactly. Check: a test document in a supported format opens in the browser editor from the Nuxeo interface without certificate warnings.
Map Nuxeo permissions to view and edit rights
Decide which Nuxeo groups may open documents read-only and which may edit, then map those groups to the rights the addon checks. Keep the mapping narrow: a user who can read a document should not gain edit rights through the editor, and guest or anonymous access stays excluded unless you have approved it in writing. Nextcloud Office offers a similar split between groups that can use the editor and groups that can edit, so treat it as a design reference only. Check: a reviewer can list each group and its right, and confirm both against the written matrix.
Restrict WOPI callbacks to known sources
Limit the WOPI requests that Collabora sends back to Nuxeo to the addresses of your Collabora servers, using a firewall rule, a load balancer allowlist or the access controls your Nuxeo proxy supports. The Nextcloud administration manual recommends the same control for its WOPI endpoints, restricting them to the addresses of the Collabora servers, so use it as a reference when you confirm what your platform allows. Use HTTPS for both the Nuxeo and Collabora URLs. Check: a request to the WOPI endpoint from an address outside the list is refused, and a request from a listed Collabora server succeeds.
Test open, save and co-editing by group
Create a test user in each permission group and run the same script for each: open a document, edit it, save it, and confirm the change appears in Nuxeo's version history. Then open the same document from a second session to test co-editing. Include a document in every format you plan to support, plus one user who should be refused edit rights. Record results and any browser or network errors. Check: each group behaves as the matrix defines, every save appears in version history, and both sessions see each other's changes.
Promote to production with a rollback plan
Apply the tested configuration to production through your change process, using the same versions, values and permission mapping recorded in test. Before the change, write a rollback plan that names the previous addon version, the previous Nuxeo configuration and the steps to disable the editor for all users, and confirm who is authorized to run it. Repeat the step seven checks in production with a test account, and set up a process to track Collabora security advisories after go-live. Check: the production test passes, and the person who would run the rollback has reviewed the steps.
Which Nuxeo data and permissions map to editor behavior
This table compares what Nuxeo holds for each document with what Collabora Online receives and does during an editing session. Read each row as a question to answer in your own environment, and treat every row marked for confirmation as dependent on the Nuxeo addon version you deploy. Files, identity, versions and rights should each be tested with a sample document before rollout.
| Item | Nuxeo side | Collabora side | What to confirm |
|---|---|---|---|
| File types | Office and ODF blobs stored on Nuxeo documents, with the MIME types the addon offers for editing | OpenDocument, docx, xlsx and pptx, plus PDF, RTF, CSV and Visio per the Collabora Online product page | Which types the addon version routes to the editor, and whether PDF, RTF, CSV and Visio open for editing or viewing only (confirm) |
| Document identity | Document UID and blob reference that the WOPI host exposes as the file ID | Identifies the file through the WOPISrc parameter, which load balancers also use for routing | The file ID format the addon generates, and whether it stays stable after a document is moved or renamed (confirm) |
| Version handling | Each saved change may create a new document version or overwrite the current blob, depending on settings | Sends saved content back to the host through WOPI write calls when the user saves | Whether saves create new versions or overwrite the current blob, and how lock and conflict handling behaves (confirm) |
| User identity | Authenticated Nuxeo user or session that the host passes along for display and attribution | Receives user ID and display name from the host and uses them to attribute edits and comments | Which user fields the addon sends, and whether guest or anonymous access is supported (confirm) |
| View versus edit rights | Nuxeo permissions on the document decide whether the host requests read-only or editable access | Opens read-only unless the host grants write permission for the session | Whether a permission change applies to open sessions or only on reopen, tested with a read-only account (confirm) |
| Co-editing sessions | One document ID should map to one shared editing session for all users | All users editing one document must reach the same Collabora pod, so replicas are set manually and autoscaling is disabled | How ingress routing by WOPISrc is configured, and what happens to a user who loses write rights mid-session (confirm) |
| Edition for production | Integration testing can start on the free CODE edition | CODE is free and rolling, and Collabora does not recommend it for production | Which Collabora Online edition and support plan fit the production environment, confirmed with Collabora before go-live (confirm) |
Sizing and routing Collabora Online pods behind Nuxeo
Co-editing depends on routing before it depends on capacity. The Collabora Online Helm chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste. Replica counts are therefore set by hand, and the load balancer in front of the pods must route by the WOPISrc parameter so that every user editing one document reaches the same pod. Before you size anything, confirm with your Nuxeo integration team and the Collabora addon documentation how the WOPI host builds the WOPISrc value for each file, because the ingress layer can only route on what it receives.
The chart README gives production resource guidance of requests at 4 CPU cores and 6000 MiB of memory per pod, with limits at 8 cores and 8000 MiB. Treat these figures as a starting reference, not as a sizing result for your organization. Requests affect how the scheduler places pods on your nodes, and limits cap what a pod may consume. The node capacity you need follows from the replica count multiplied by these figures, plus headroom for upgrades and node failure. That infrastructure runs in your cloud account or data center, so it is a cost you carry directly, separate from any Collabora subscription.
The chart README lists Nginx, HAProxy and OpenShift Router as supported ingress controllers. Choose the controller your platform already operates, then verify that its configuration keeps all requests for one WOPISrc on one pod. Check the chart values and the controller version you run, and test the behavior in a non-production environment. Ask Collabora or your implementation partner to confirm the exact routing configuration for your controller. Nuxeo's own deployment sizing is out of scope for this section and is covered separately, so the figures here describe only the Collabora side of the editing path.
A load test is the only reliable way to check the starting reference against your workload. Build the test from the number of concurrent editors you expect, the number of sessions open on the same document at once, the mix of Word, Excel, PowerPoint and OpenDocument files, and realistic use of copy and paste. Confirm the expected concurrency with the business owners of the Nuxeo repositories, since guesses about usage tend to be wrong in both directions. During the test, verify that sessions for one document stay on one pod and that memory and CPU stay within the requests you set. Record the results so the replica count can be changed deliberately during a maintenance window, because scaling is manual and changing it while sessions are active can disrupt editing.
Security settings for the Nuxeo to Collabora Online connection
These controls cover the path between Nuxeo, the Collabora Online server and the people editing documents. Each card names one control, the decision behind it, and what to confirm with Nuxeo, Collabora or your own environment before go-live.
HTTPS with trusted certificates
Encrypt every leg of the connection: browsers to Nuxeo, browsers to the Collabora Online server, and Nuxeo to the editor. Each endpoint needs a certificate chain that the other parties trust, including any internal certificate authority your organization runs. Confirm that Nuxeo and the editor both validate each other's certificates, and that certificate renewal is part of the operations runbook, since an expired certificate can stop editing for every user at once. Ask Nuxeo and Collabora which addon settings control certificate verification.
Restrict WOPI traffic by address
Where the platform supports it, allow WOPI requests only from the known addresses of your Collabora Online servers. This keeps other hosts from calling the WOPI endpoints on your Nuxeo side. The Nextcloud administration manual recommends this pattern for its own Collabora integration. Ask Nuxeo and Collabora whether the Nuxeo addon supports address restriction. If it does not, document a compensating control, such as network policy that limits which systems can reach the WOPI path.
Match protocols in both URLs
Configure the URL that Collabora uses to reach Nuxeo and the editor URL that Nuxeo sends users to with the same protocol. The Nextcloud administration manual advises using the same protocol for both, preferably HTTPS. Mismatched schemes can cause mixed content blocks, failed callbacks and sessions that open but do not save. Check the discovery endpoint from the Nuxeo side and confirm that every editor URL it advertises uses HTTPS before users reach production.
Group limits for use and editing
Limit separately who can open documents in the editor and who can edit them. The Nextcloud administration manual describes group settings for both use of the editor and editing rights, which is a useful model for the Nuxeo connection. Map these limits to Nuxeo groups or permissions, then test with a read-only account, a contributor and an account outside the allowed groups. Confirm with the addon vendor which Nuxeo permissions the editor respects.
Stay on a supported patch line
Run a Collabora Online release line that still receives fixes and keep it current. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. Subscribe to Collabora's release notes, test each update in a non-production Nuxeo environment first, and confirm that your package repositories import the updated signing keys. The 25.04 branch was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026.
Review the MPL-2.0 server code
The Collabora Online server code is licensed under MPL-2.0, so your security team can read the source when reviewing request handling, authentication hooks and WOPI endpoints. Use the code as a review reference for your own testing and for questions to the vendor. Open licensing and source availability do not make the server secure. The deployed configuration still needs review, patching and testing in your environment.
Common Nuxeo and Collabora Online failures and their fixes
This table lists common failures when Nuxeo hands documents to Collabora Online, with the likely cause and first checks for each. Match the symptom you see, work through the cause column, and then review the fix before changing any setting. Confirm parameter names, certificate handling and version pairings with Collabora before applying changes in production.
| Symptom | Likely cause | Fix |
|---|---|---|
| Documents open read-only when edit was expected | The user holds only read permission in Nuxeo, or the integration's edit mapping does not match the user's role | Check the Nuxeo permission on the document, then review the edit mapping with Collabora's integration guidance |
| Editor loads but files do not save | The editor cannot reach the Nuxeo callback address, or a proxy or firewall blocks save requests | Test connectivity from the editor to Nuxeo, and confirm that save requests pass through every proxy and firewall |
| Certificate errors between Nuxeo and the editor | A private or internal certificate authority is not trusted by the editor or the Nuxeo server | Add the internal certificate authority to both trust stores, then confirm the certificate chain with Collabora |
| Mixed HTTP and HTTPS URLs | Nuxeo generates links with a different protocol than the Collabora server URL | Use one protocol throughout, preferably HTTPS, and check that reverse proxies forward the correct protocol headers |
| Users reach a different pod mid-session and co-editing breaks | The load balancer routes by client address or cookie instead of the WOPISrc parameter, or replica counts change during a session | Route by WOPISrc so everyone on one document reaches the same pod, and keep replica counts fixed as the Helm chart documentation advises |
| Some file types fail to open | The format is not on the editor's supported list, or Nuxeo maps the file's MIME type incorrectly | Confirm the format against Collabora's supported list, check the MIME type mapping, and test each format with a sample file |
| Editing fails after a Nuxeo upgrade | The Nuxeo addon version is not certified for the new Nuxeo release or the current editor version | Check the addon and editor compatibility with Collabora before upgrading, then retest open and save on a staging copy |
| Access works for some users and not others | Nuxeo group or role membership does not match the groups the integration allows to open or edit | Compare the allowed groups in the integration settings with each test user's memberships, and correct the mapping |
Questions buyers ask before connecting Nuxeo to Collabora Online
What drives the cost of connecting Nuxeo to Collabora Online?
Cost is driven by three things: Collabora licensing for production, the integration work, and the support you choose to run after launch. Licensing is the part you can price in advance. Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, with long term support, a service level agreement, signed security updates and customer portal access. For 100 or more users, the Enterprise plan is quoted with volume discounts and adds integration support, customization services and roadmap input. The integration work covers Nuxeo configuration, the WOPI connection between the host and the editor, sizing, testing and handover. Those costs rise with the number of Nuxeo repositories, file types and user groups in scope. Ask for each component as a separate line in the written quote, so you can see which parts are one-time and which recur.
How much does Collabora Online licensing cost for production use?
Budget for a paid plan, because Collabora describes its free CODE edition as suited to testing, home use or small teams and not recommended for production. Collabora's pricing page lists the Business plan at 3 euros per user per month for up to 99 users. To estimate the yearly line, multiply that rate by your licensed user count and by 12, then confirm with Collabora how it counts users, including people who only view documents. For 100 or more users, Collabora quotes the Enterprise plan with volume discounts, so you need a direct quote. Licensing recurs for as long as the editor runs in production. Confirm current terms on the pricing page before you finalize the budget, because plan terms can change.
How long does a Nuxeo and Collabora Online integration take?
The duration depends mainly on scope and on your environment. The main drivers are the number of Nuxeo repositories and document types to open and edit, whether co-editing is required, which file formats are in scope, how many environments you need (test, staging and production), and how long your security team takes to approve certificates and network paths. Collabora Online supports OpenDocument and Microsoft formats, including docx, xlsx and pptx, plus PDF, RTF, CSV and Visio files, so the format list alone can change testing effort. Your number of available change windows also sets the pace of go-live. DeployOpen's engagements are fixed-scope, so the timeline is agreed in writing before work starts. Ask for that timeline to list each dependency on your side.
What must our team provide before connecting Nuxeo to Collabora Online?
Before work starts, you provide access and approvals for the systems involved. Typical items include administrator access to Nuxeo for the integration account, TLS certificates for the Collabora server and the WOPI host, using the host names each system will use, network paths between Nuxeo, Collabora Online and users' browsers, test users and groups that cover each role able to open, view and edit documents, and a change window for each environment. The Nextcloud administration manual, which covers a different WOPI host, recommends restricting WOPI requests to the Collabora server addresses and using HTTPS for the Collabora server URL. Ask Nuxeo and Collabora which equivalent controls apply to your setup. Your security team should also decide which groups may edit documents, not only view them.
Can an internal team connect Nuxeo to Collabora Online without outside help?
An internal team with Nuxeo administration, Linux and container operations, and TLS skills can often do the work, but the job is more than installing a connector. Collabora's product documentation covers Docker images, system packages and Kubernetes, so the deployment choice affects the skills you need. The hardest parts sit in security and load: the WOPI trust relationship, certificate chains, which Nuxeo groups can edit, and routing so all users of one document reach the same server pod. Check whether your team has run a document editor in production before, and who will apply patches. Ask the team to write a test plan covering each file type and user role. If the skills are split across teams, a fixed-scope engagement can fill the gaps and hand over a runbook.
What ongoing work follows launch for Collabora Online with Nuxeo?
Plan for recurring work in five areas. First, patching: Collabora publishes security advisories, and its 25.04 release notes record a fix for CVE-2026-23623 in point release 25.04.7.5, along with updated package signing keys for RPM and DEB users. Someone must watch releases and apply them. Second, updates to the Nuxeo connector, which must be retested against the Collabora version you run. Third, Nuxeo upgrades, which can change the WOPI behavior the connector depends on. Fourth, Collabora Online upgrades, including moving between release branches. Fifth, capacity review as user counts and document sizes grow. If you run on Kubernetes, the Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing, so capacity changes are made by hand. Budget for the people and the test environment, and name an owner for each item.
What should a written quote for this integration include?
A useful quote starts with scope and deliverables, then lists each cost line separately. Ask for the Nuxeo versions and repositories in scope, the Collabora Online deployment method and the number of environments, and the file types and co-editing behavior to be tested. The Collabora licensing line should name the plan, the user count and who purchases it. Integration, sizing, testing and handover should each appear as their own item, along with the change windows and what your team must provide. Confirm the support period, the recurring work it covers, and the acceptance criteria. Mark which items are one-time and which recur. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so check that each of these appears in the document you sign. Ask for assumptions in writing too, because they drive most change requests.
How do we keep all users editing one document on the same server?
Route requests by the WOPISrc parameter so that every user editing one document reaches the same Collabora pod. The official Collabora Online Helm chart README states that load balancers must route this way. The same README disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replica counts are set manually. For production, the chart recommends limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, and it supports Nginx, HAProxy and OpenShift Router ingress. Confirm that your ingress controller can route on that parameter, then test with two browsers editing one file at the same time. If you run Collabora Online outside Kubernetes, confirm the equivalent routing behavior in Collabora's documentation before go-live.
How DeployOpen scopes, builds and supports the Nuxeo integration
DeployOpen plans, implements, integrates, hardens and supports self-hosted open-source platforms inside your own infrastructure. For Collabora Online and Nuxeo, we define the WOPI host and editor connection in writing before work starts, then build and test it in your environment.
How we scope
- Written scope that names your Nuxeo version, file types and user groups in use
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Confirm the Collabora addon version and its compatibility with your Nuxeo release before scoping
How we build
- Configure load balancers to route by the WOPISrc parameter when Collabora runs on Kubernetes
- Restrict WOPI requests to known Collabora server addresses and use matching HTTPS URLs for both systems
- Test opening and co-editing of docx, xlsx, pptx and ODF files from Nuxeo, with the permissions your roles require
How we hand over
- Written configuration record covering WOPI host settings, editor URLs, network rules and secret locations
- Runbook for patching Collabora Online, including checks to repeat after each point release
- Knowledge transfer to your administrators on troubleshooting WOPI and editor sessions
How we support
- Retainers are available for ongoing support, upgrades and continuous testing after handover
- Track Collabora security advisories and schedule point release updates through your change process
- Re-test the Nuxeo connection after each Nuxeo or Collabora upgrade before it reaches users
