When Collabora Online upgrades and support are worth outsourcing
Upgrades and support keep a Collabora Online server on a supported branch and make sure security fixes reach production. Most teams split this work between their own operators, who run the servers day to day, and an outside partner, who takes on the patching, testing and release planning that needs time and specialist attention. An editor that serves live documents cannot be left on an old build, so the question is less whether to keep it current and more who does each step and who is accountable when a change goes wrong.
Four events usually start an upgrade. The first is a new yearly branch. Collabora's 25.04 branch was first released on June 19, 2025, and 26.04 was announced on July 23, 2026, so a team on one branch will eventually need to move to the next. The second is a security advisory. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and updated the package signing keys for RPM and DEB users, which means the signing key change must reach your package sources as well as the server. The third is a host upgrade, such as a new Nextcloud or other WOPI host version, which can change how the host calls the editor. The fourth is staff turnover, when the person who understood the original configuration leaves.
The decision depends on who patches, tests and signs off. Before you outsource anything, write down who watches the release notes and advisories, who applies point releases in a staging copy that is wired to the same WOPI host, who runs the document checks that matter to your users, and who approves the change window for production. If your own team cannot cover one of these steps within the expected response time, that gap is the strongest reason to bring in a partner for that step. Using CODE for production is a separate risk, since Collabora describes CODE as a rolling build suited to testing, home use or small teams and not recommended for production.
Ask any candidate partner, and check your own subscription, for the same specifics: which branches and point releases are covered, how quickly security fixes are applied, whether signed updates and customer portal access are included, how staging and rollback are handled, and what happens to support when a branch reaches the end of its maintenance window. Confirm these in writing before work starts. Those answers, not the release calendar alone, determine whether a split of duties between your team and a partner will hold up when the next advisory arrives.
What Collabora Online upgrade and support work includes
Collabora Online upgrades follow a yearly release branch, point releases on that branch, and security advisories between them. The work below turns that cadence into a planned, tested routine in your own infrastructure. The deliverables are handed over at the end, and the exact list is fixed in the written scope.
Yearly branch planning
Each year Collabora starts a new release branch, and the first decision is which branch your deployment should follow and when to move to it. We compare the branch in use with the current one, list the changes that affect your WOPI host, reverse proxy and TLS settings, and agree an upgrade window with your team. Confirm which branches your edition covers with long term support before you commit to a date.
Point release application
Point releases on the branch in use carry fixes for bugs and security issues. For example, 25.04.13 was released on September 21, 2026, on the 25.04 branch. We apply each point release first to a non-production copy, then to the production coolwsd servers or Kubernetes deployment, and confirm service health after each step. Ask how rollback works if a node fails to start after the update.
Security advisory triage and patching
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. We read each advisory against the version you run, decide how much exposure it creates in your setup, and schedule the patch within the timeline set in the written scope. Triage decisions are recorded so your security and audit teams can see what was decided and why.
Signed package and key handling
RPM and DEB installs rely on signed packages, and the 25.04 release notes record that package signing keys were updated for RPM and DEB users. We verify repository keys and package signatures before each install, and log any key change in the change record. Confirm with Collabora which signed update channel your plan includes and how key changes are announced to customers.
Regression testing against the WOPI host
An upgrade can pass a service health check and still break editing from the host application. We run an agreed set of test documents through your WOPI host, such as Nextcloud, covering open, edit, save and copy-and-paste for docx, xlsx, pptx, PDF and OpenDocument files. Failures are logged in the change record and resolved before go-live. The same test set is reused for each upgrade so results stay comparable.
Post-upgrade configuration review and runbook
After each upgrade we compare the coolwsd configuration and the WOPI allow list with what the host expects, including the server URL protocol and the IP restrictions the Nextcloud administration manual recommends. The documented runbook records each step, the rollback path, owners and the checks to repeat at the next upgrade. The exact list of handed-over deliverables is fixed in the written scope.
What drives the cost and effort of keeping Collabora Online supported
This table lists the factors that change how much work each Collabora Online upgrade and support cycle takes, why each one matters, and what keeps it manageable. Use it to see which drivers apply to your environment before asking for a quote. The main takeaway is that a small number of standard install methods, a staging copy of production and a clear change process usually matter more than the raw size of the deployment.
| Driver | Why it raises effort | What keeps it down |
|---|---|---|
| Number of coolwsd servers or Kubernetes replicas | Each server or pod must be upgraded, restarted and checked. Replica counts are set manually because autoscaling is disabled in the official Helm chart, so capacity changes are deliberate work, and rolling restarts must keep documents on the same pod. | Keep the server count to what peak concurrent editing requires, use one repeatable rollout pattern for all nodes, and confirm the rolling update order before each release. |
| Number of WOPI hosts and their versions | Each host that calls Collabora Online must stay compatible with the server version, and host upgrades can change WOPI behavior. Nextcloud, ownCloud, Seafile and other hosts each have their own release cycle. | Inventory every host and version, pin the host versions that are tested together, and test host upgrades against the target Collabora release in staging. |
| Install method (Docker images, system packages or Kubernetes with Helm) | Each method has its own upgrade path, package signing checks and configuration files. Mixed methods across environments mean separate runbooks and separate verification steps. | Standardize on one install method per platform, record the image tag or package version in configuration management, and document the upgrade steps for that method only. |
| Number of environments that need the same upgrade | Development, test, staging and production each need the change applied and checked, and drift between them makes failures harder to diagnose. | Promote the same artifact through each environment in order, and keep environment configuration in version control so differences are visible. |
| Custom integrations or branding that must be retested | Themes, custom fonts, templates, CheckFileInfo settings and integration code can break with a new release, so each customization needs its own test cases after every upgrade. | Keep a written list of customizations with expected behavior, automate the checks where possible, and limit customizations to those the business actually uses. |
| Edition in use (CODE or a subscription) | CODE is a rolling monthly release that Collabora does not recommend for production, so every update is a full change cycle. A subscription adds support terms and signed security updates, but the reader must still plan the change work. | Confirm with Collabora which edition and support terms apply to the deployment. Ask what the Business or Enterprise plan includes for long term support and signed updates before deciding on a version path. |
| Internal change process and approval steps | Security reviews, change advisory boards, maintenance windows and user communication add time to every release, especially when security advisories require fast action. | Agree in advance on which advisories are emergency changes, prepare standard change templates, and define a rollback plan so approvals do not depend on new analysis each time. |
How a Collabora Online upgrade runs from branch check to sign-off
The sequence confirms the installed version, selects a supported target release, and proves that editing still works in a staging copy before production changes. It ends with an upgrade record your team can use for later point releases and security advisories.
Inventory the current version and install method
DeployOpen records the installed Collabora Online version and its branch, and how it runs: system packages, a Docker image (the free CODE image or a subscription build), or Kubernetes with the Helm chart. We also list the WOPI hosts connected to it, such as Nextcloud, with their versions, the reverse proxy and TLS setup, the ingress controller, and any customizations. Your team confirms the inventory. The output is a written baseline that the upgrade plan is built from.
Select the target release within the branch plan
Collabora ships a yearly branch and point releases within each branch, and point releases carry fixes and security advisories. We compare your current point release with the latest one on your branch and with any newer yearly branch, and check the release notes for changed settings, deprecated options and package signing key updates. Confirm the current release list with Collabora before the choice is made. The output is a named target version with the reason for it.
Upgrade staging and run WOPI and format tests
The target version is installed in a staging environment that mirrors production, with a copy of the WOPI host configuration and an allow list that matches production. The test set covers opening, editing, saving and co-editing from the host, WOPI file information and permission checks, and round trips for docx, xlsx, pptx, PDF and any other formats your users rely on. For Kubernetes, we also confirm that WOPISrc routing still sends every user editing one document to the same pod. The output is a signed test log with each failure either fixed or accepted.
Write the rollback plan and agree the change window
Before production changes, we write the rollback plan: a backup of configuration and the WOPI host settings, the previous package version or image tag kept available, and the steps to restore service and to decide when to roll back. The change window and the people who approve and staff it are agreed in the written scope, along with the timeline. The output is a rollback runbook and a change request that your change board can approve.
Upgrade production and run smoke tests
The upgrade runs inside the agreed window, following the staging steps. Once the new version is running, we confirm the version reported by the server, then open, edit and save a test document from the WOPI host, check the ingress and TLS path, and review the server logs for errors. If a smoke test fails, the rollback runbook is used and the decision is recorded. The output is a smoke test result for each check, signed by DeployOpen and your operations contact.
Hand over the upgrade record
The upgrade record lists the version before and after, the staging and smoke test logs, the rollback decisions, the advisories addressed, known issues and the settings changed. It is stored in the documentation set your team owns, so later upgrades start from the same baseline. If support is under a retainer, the record also sets the schedule for reviewing the next point releases and advisories. The output is a closed change record and a documented baseline.
Why yearly branches and point releases shape the upgrade plan
Collabora Online ships on two clocks, and your upgrade plan has to follow both. The first is the yearly branch, named by year and month, such as 25.04 and 26.04. The second is the point release, a numbered build on a branch that carries fixes. The 25.04 branch was first released on June 19, 2025 as 25.04.2.3, and it was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026. A branch that is still getting builds is not guaranteed to keep getting them. Before you set any dates, confirm the current support window for each branch with Collabora, and enter the end date in your upgrade calendar.
Teams running an older branch can keep receiving fixes for a period, but that period is finite, so the plan should include a move to a newer branch. Collabora announced 26.04 on July 23, 2026. It adds an optional AI assistant across Writer, Calc and Impress that is off by default, and administrators choose the AI provider and whether it runs externally or on their own infrastructure. Those choices are a reason to test the new branch in staging before any production change. Start with an inventory of the branch and point release on each coolwsd server or container, and list which WOPI hosts depend on each one. Then stage the new branch against your Nextcloud or other host and check editing for the file formats your users rely on most.
Patch intake needs a routine because fixes arrive in point releases, and packaging details can change between them. 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. A team that imports keys by habit could miss a key change, and a team that never checks advisories could run a vulnerable build for months. Turn this into a recurring task with three steps: subscribe to Collabora's release notes and advisories, verify the signing key against the vendor's published guidance before updating RPM or DEB packages, and apply point releases in a scheduled window with a tested rollback path. Assign an owner to each step, whether that is your platform team or a support retainer.
CODE is the free edition, released on average once a month as a rolling build. Collabora describes it as suited to testing, home use or small teams, and it is not recommended for production. That makes CODE a useful place to try a new branch, but a weak foundation for a production editing service that must follow advisories on a predictable schedule. The supported path is a subscription. The pricing page lists the Business plan at 3 euros per user per month for up to 99 users, and it includes long term support, a service level agreement, signed security updates and customer portal access. Confirm with Collabora which of these terms apply to your install method, whether that is Docker images, system packages or Kubernetes.
Before you commit to a cadence, get written answers to four questions: the end date for each branch you might run, how Collabora notifies customers of advisories, whether signed security updates apply to your deployment method, and what happens to a branch when its window closes. Record those answers in the upgrade plan with the date you asked and the person who answered. For a Helm-based deployment, plan a rolling change across replicas and keep WOPISrc routing in place during the update so editors working on one document stay on one pod. The result is a short, repeatable cycle: check advisories, stage the candidate build, test editing with representative files from your estate, and then roll the change to production.
What goes wrong in Collabora Online upgrades and how to prevent it
Most upgrade problems in Collabora Online come from changes made outside a controlled process: unpinned builds, skipped point releases, settings lost during redeploys, and routing or scaling changes that affect live editing sessions. Each card below names one pattern, why it matters, and the step that prevents it.
Rolling CODE builds in production
CODE is the free edition, released on average once a month as a rolling release. Collabora describes it as suited to testing, home use or small teams and does not recommend it for production. Teams that pull the latest CODE image on every deploy receive untested changes with no fixed baseline to roll back to. Prevention: move production to a supported edition, pin an image tag, and run each update through a written change process with a staging copy and a rollback plan.
Skipping point releases
Collabora publishes point releases within each yearly branch, and security fixes arrive through them. According to the 25.04 release notes, the 25.04 branch was still receiving point releases, with 25.04.13 released on September 21, 2026. Release 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. A server held on an older point release can miss a fix that matters to your exposure. Prevention: review the release notes and advisories for your branch on a fixed schedule and confirm signing key updates for RPM and DEB packages.
Upgrading without retesting the WOPI host
Collabora Online is reached through a WOPI host such as Nextcloud, so a server upgrade changes behavior the host depends on. Opening, saving, locking and co-editing can change in ways that a server-only health check does not reveal. Prevention: test the full path from the host in staging, covering open, edit, save and share for the file types your users rely on, before the production cutover.
Losing allow list or HTTPS settings
A redeploy from an old template, image or chart can restore default values and drop the WOPI allow list or the HTTPS server URL. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers and using HTTPS for the Collabora server URL, with the same protocol as the Nextcloud installation. Prevention: keep these settings in version control and verify the allow list, server URL and certificate chain from the host side after every deploy.
Enabling autoscaling on Kubernetes
The official 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. An autoscaler added through a custom values file or a cluster-wide policy can add or remove pods during active sessions. Prevention: set replica counts explicitly, review any autoscaler or cluster policy that targets the Collabora deployment, and schedule capacity changes in maintenance windows.
Breaking sticky routing by WOPISrc
The Helm chart README requires load balancers to route by the WOPISrc parameter so that all users editing one document reach the same pod. An ingress change, a new load balancer or a rule based on client address can send co-editors to different pods and split their session. Nginx, HAProxy and OpenShift Router are the ingress options the chart supports, so confirm the routing rule syntax for your controller. Prevention: test with two users editing one file across pods after every ingress change.
How upgrade and support work differs by install method and starting point
In a Docker deployment, an upgrade means pulling a newer image and recreating the container, so the configuration and any certificates must come from outside the image. The free CODE image is collabora/code, published for x86-64, ppc64 and arm64, and the host architecture has to match one of those platforms before you pull.
- Pin the tag: Use a specific release tag instead of a floating tag, and read the release notes for the target branch first.
- Check the platform: Confirm the host architecture matches the image platform before the pull.
- Version the configuration: Keep coolwsd configuration and mounted certificates in version-controlled files so the recreated container starts with identical settings.
- Confirm the WOPI settings: Verify that the WOPI host allow list and the server URL survive the recreate.
- Test the round trip: Open an existing document through the WOPI host, edit it, save it, and confirm the reverse proxy and TLS still work.
Before you go live, compare the digest and platform of the pulled image with what you tested in staging.
Package installs are upgraded through the distribution's package manager, and that only works when the repository and its signing key are current. Collabora updated the package signing keys for RPM and DEB users in the 25.04 line, so a stale key can block an update or make a team distrust a valid one. Security fixes also arrive this way, as in the 25.04.7.5 release, which fixed CVE-2026-23623.
- Refresh the signing key: Import the current key for your package type and check its fingerprint against Collabora's published instructions before upgrading.
- Check the repository branch: A repository configured for an older branch will not move you to a newer one, so confirm which branch it points to.
- Plan the restart: coolwsd runs as a service, so schedule a restart window and check the service status after the update.
- Review configuration changes: The package manager may flag local edits to configuration files, so review each one before you accept the new file.
- Test the editor path: After the update, confirm the installed version, open and save a document from the WOPI host, and scan the logs for errors.
Record the package versions and key fingerprints in your change record so an auditor or incident responder can trace what ran on the host and when.
On Kubernetes, the official Helm chart changes the image, the values and often the ingress in one release. The chart sets replicas manually because horizontal pod autoscaling is disabled, as scaling breaks collaborative editing and copy and paste. Every upgrade must therefore keep the replica count and resource settings explicit and reviewed.
- Set replicas explicitly: Keep the replica count in your values file and make sure no autoscaler changes it during the rollout.
- Preserve resource settings: The chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Confirm your merged values still set these after chart changes.
- Confirm WOPISrc routing: Check that the Nginx, HAProxy or OpenShift Router ingress still routes by the WOPISrc parameter, so all editors of one document reach the same pod.
- Match the Controller version: If you run the Collabora Online Controller, confirm its version works with the chart version you are deploying.
- Test a rolling replacement: In a non-production namespace, have two users edit the same document while pods are replaced, and confirm the session continues.
Keep the rendered manifests from each release so you can compare the resource and replica values before and after the change.
Moving from an older branch or a self-managed CODE install to a supported edition changes support status as well as the version. CODE is a rolling release, released on average once a month, and Collabora describes it as suited to testing, home use or small teams, not production. The Business plan costs 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access, according to Collabora's pricing page.
- Map your starting point: Record the current branch or CODE build and the target branch. The 25.04 branch was still receiving point releases, with 25.04.13 released on September 21, 2026.
- Read every skipped branch: Review the release notes for each branch you pass through, not only the final target.
- Confirm entitlement first: Make sure portal access and signed package sources are working before cutover, so security updates are available from day one.
- Switch the package sources: Replace CODE sources with the supported repositories and their signing keys.
- Test with your formats: Run a staged cutover using the document formats your users rely on, and verify the WOPI host version is compatible.
Ask Collabora to confirm in writing which support, SLA and update terms apply to your edition and user count.
What your team must provide before Collabora Online support starts
Support for Collabora Online cannot start until your team gives us access and facts on both sides of the integration. Start with admin access to every coolwsd server and to the WOPI host, whether that is Nextcloud or another platform. Without host-side access, we cannot confirm which Collabora server URL and allow list the host uses, and we cannot test a document open after a change. Ask for named admin accounts, a documented emergency access path, and the approval needed to use it. Also confirm where each configuration file lives and who has edited it in the past year, since undocumented edits are the most common reason an upgrade behaves differently in one environment than another.
Next, provide a current inventory of versions and install methods. For each Collabora server and the WOPI host, list the installed version, the operating system, the install method (Docker image, system packages, or Kubernetes with the official Helm chart), and the reverse proxy or ingress in front of it. State whether any server runs CODE, the free rolling build that Collabora does not recommend for production. Moving that server to the supported edition is a separate decision with its own cost and testing. Add network and DNS details: hostnames, internal and external addresses, firewall rules between the host and the Collabora servers, and the addresses the host uses when it calls Collabora. Provide TLS certificates details too, including the owner, expiry dates and renewal process.
Your team should also supply the list of allowed WOPI host addresses. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers and using HTTPS for the Collabora server URL when the host uses HTTPS. Confirm whether those addresses are fixed, and whether a cloud load balancer, NAT gateway or autoscaling group could change them during a patch. A staging environment, or permission for us to create one, is equally important. Staging should mirror production configuration with a test WOPI host, so that point releases and branch moves can be checked against your own docx, xlsx and pptx samples before a change window opens. Without it, every upgrade becomes a test in production.
Name the people who approve and schedule work. You need an approver for production changes, a person who owns change windows, a contact who receives and triages security advisories, and a business owner for editing rules. Document which groups may open the editor and which may edit rather than only view, as Nextcloud Office allows administrators to set. These rules are a business decision, so they should come from your side before go-live changes are made. The approver also decides on branch moves, such as moving from one yearly branch to the next. We recommend that your approver makes that call, using our written test results and the vendor release notes as inputs. Record each acceptance decision in your change system with the version, date, tests run, known issues, rollback plan, approver name and outcome.
Recurring costs of keeping Collabora Online supported after go-live
This table lists the recurring and one-time costs of keeping Collabora Online supported after go-live, and who is paid or who bears each one. Read the second column to see whether the cost falls on your staff, your infrastructure or a vendor, and the last column for what drives it up. Subscription prices come from Collabora's pricing page, while other items depend on your environment and scope. Ask every provider for a written quote that states user counts, covered versions and the staging scope.
| Cost component | Who is paid or bears it | One-time or recurring | What drives it and what to request |
|---|---|---|---|
| Internal operator time | Your platform or operations team | Recurring | Advisory monitoring, point release review and change windows. Grows with the number of servers and how often you patch. |
| Staging infrastructure | Your cloud or hosting provider | Recurring hosting, one-time build | A copy of the production stack for testing point releases. Keep its sizing and WOPI host settings close to production. |
| Hosting capacity for test runs | Your cloud or hosting provider | Recurring during upgrade windows | Load and regression runs before each update. Confirm how your provider bills for short-lived test capacity. |
| Business subscription | Collabora | Recurring, per user per month | 3 euros per user per month for up to 99 users, including long term support, SLA and signed security updates (pricing page). |
| Enterprise subscription | Collabora | Recurring, quoted | Quoted with volume discounts for 100 or more users. Ask whether integration support and customization services are included. |
| CODE edition | No licence fee | Free to use | Rolling monthly releases, and Collabora does not recommend it for production. Your staff carry all patch and support effort. |
| Outside support retainer | Your chosen support partner | Recurring | Monitoring, upgrades and fixes on a written scope. Request response times, covered versions and support hours in the quote. |
| Internal skills for Linux, reverse proxy, TLS and containers | Your staff or training budget | Recurring staff time, one-time training | Needed to apply updates to the host, proxy, certificates and containers. Confirm cover for on-call and staff absence. |
Questions buyers ask about Collabora Online upgrades and support
Can we run Collabora Online CODE in production?
Collabora's stated position is that CODE is not recommended for production. CODE is the free edition, released on average once a month as a rolling build, and Collabora describes it as suited to testing, home use or small teams. The support difference is what matters for production. The Business plan, priced at 3 euros per user per month for up to 99 users according to the pricing page, includes long term support, a service level agreement, signed security updates and customer portal access. Enterprise plans for 100 or more users are quoted and add integration support, customization services and roadmap input. Your choice is therefore between a subscription with Collabora and a documented risk decision by your security and operations leaders. DeployOpen can plan and run either path, but the subscription itself is bought from Collabora.
How often does Collabora Online get upgraded in practice?
Upgrades follow Collabora's yearly branches and the point releases published on each branch. Collabora Online 25.04 was first released on June 19, 2025, and was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026. Collabora announced 26.04 on July 23, 2026, which adds an optional AI assistant that is off by default. Security fixes ship as point releases. For example, 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and updated package signing keys for RPM and DEB users. In practice, you review point releases on your current branch on a regular cadence and plan a move to a newer yearly branch when your support window or features require it. Confirm the latest point release and the end date for your branch in the release notes before you schedule work.
What does a Collabora Online upgrade engagement cost?
No single price applies, because cost has several parts. Software is paid to Collabora: the Business subscription is 3 euros per user per month for up to 99 users, and Enterprise is quoted by volume. Infrastructure for your coolwsd servers is paid to your cloud or data center provider. Labor is paid to whoever performs the work, covering staging, testing against your WOPI host, the change window, rollback planning and documentation. One-time costs include the first runbook and staging validation. Recurring costs include the subscription, infrastructure and any support retainer. Costs rise with the number of Collabora servers, WOPI hosts, custom templates or branding to retest, and file types in scope. Ask for a quote that lists deliverables, environments, client responsibilities, test cases, exclusions and recurring items. DeployOpen quotes from the written scope.
How long does a Collabora Online upgrade take to complete?
It depends on scope, and the duration is fixed in writing before work starts. Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in a written statement before any work begins. The main variables are the number of Collabora servers, whether they run from Docker, system packages or Kubernetes, the number of WOPI hosts and their versions, custom templates, fonts or integrations that need retesting, and the file types you must check, such as docx, xlsx, pptx, PDF and Visio. Whether a staging copy already exists also changes the timeline. Ask the provider to break the plan into staging build, functional testing, change window and rollback readiness, so you can see where time goes. Be cautious with any estimate that omits staging.
What does our team need to provide for an upgrade?
Expect to provide access, decisions and test input. You need access to the environment, including cloud accounts, cluster or hosts, and administrator access to the WOPI host, such as Nextcloud, for testing. A staging copy that resembles production is essential, or permission to create one. A named business owner should approve test results, and a change approval process must be defined. You should supply a list of document types, templates and fonts your users rely on. For Kubernetes deployments, provide the Helm values, replica counts and ingress type, which can be Nginx, HAProxy or OpenShift Router. The official Helm chart notes that autoscaling is disabled and that load balancers must route by the WOPISrc parameter, so confirm that routing is in place. Finally, keep the WOPI allow list and monitoring access current.
Can our own team upgrade Collabora Online without a partner?
Yes, a team can run upgrades alone if it prepares three things. First, a staging copy that matches production closely enough to catch problems. Second, a written runbook that covers backups, the upgrade steps, smoke tests and rollback. Third, a named owner accountable for the go or no-go decision. The runbook should also record the WOPI host version and allow list settings. Test the formats your users actually open, including docx, xlsx and pptx, and test multi-user editing, because a server can start cleanly and still break collaborative sessions. A partner adds outside review and capacity for short change windows, and DeployOpen can deliver the runbook and staging validation as a fixed-scope piece for your team to run afterward.
How do security advisories reach us, and how do we confirm the support window?
Collabora publishes security fixes in its release notes for each point release. For example, the 25.04 release notes record that 25.04.7.5 fixed CVE-2026-23623 and updated package signing keys for RPM and DEB users. Business subscribers receive signed security updates and customer portal access, so confirm the delivery channel and contacts your plan includes in your subscription terms. To confirm the current support window, check the release notes for your branch and the pricing or terms for your plan, then record the branch end date in your runbook. If you run CODE, the rolling build is your update path, so review its release notes at least monthly. DeployOpen does not issue advisories itself, but it can set up a review cadence that checks them against your deployed version.
How DeployOpen scopes, delivers and supports Collabora Online upgrades
DeployOpen plans and carries out Collabora Online upgrades inside your own infrastructure, from the current branch to a newer one. Engagements are fixed-scope, with the work agreed in writing before it starts, and ongoing support is available as a retainer after go-live.
How we scope
- We inventory the running Collabora Online version, its install method and every WOPI host connected to it.
- We confirm which release branch you are on and whether you run CODE or a subscription edition.
- The written scope lists the target version, staging tests, rollback steps and the documents we will produce.
How we build
- We rehearse the upgrade on a staging copy that mirrors your proxy, TLS setup and WOPI allow list.
- We test document round trips for the formats your users rely on, including docx, xlsx and pptx, before cutover.
- We check Helm values, replica counts and ingress routing by WOPISrc when Kubernetes is in use.
How we hand over
- You receive a change record with the old and new versions, configuration changes and test results.
- We document the rollback procedure and the signed package or image source used for each update.
- Your team gets a runbook covering how to track point releases and security advisories for your branch.
How we support
- Ongoing support and upgrades can be taken on as a retainer, with the coverage agreed in writing.
- We can apply point releases and security advisories on a schedule you approve, tested first on staging.
- Support scope, response expectations and the systems covered are confirmed in the retainer before work begins.
