Installing Collabora Online from Linux packages

Installing coolwsd from Collabora's deb and rpm repositories gives you a native service you manage with your own tooling. This page covers the choices, the install sequence and the checks that confirm it works.

Book a callTalk to us
On this page

Installing Collabora Online from Linux packages on servers you control

A system package install puts Collabora Online directly on an Ubuntu, Debian or RHEL-family server, managed by your existing operating system tooling, so the editing service runs in your own infrastructure without a container runtime in the middle. The core of the install is coolwsd, the WebSocket daemon that receives editing sessions from a WOPI host such as Nextcloud and hands documents to the LibreOffice-based engine behind it. Collabora Online can also be delivered as Docker images or on Kubernetes, and the choice is mostly about how your team already runs servers. Packages fit best when you manage hosts with configuration management, want systemd service control and standard patching, and do not already operate a container platform that would make images the simpler unit of deployment.

The server code is licensed under the Mozilla Public License 2.0 (MPL-2.0), which governs what you may modify and redistribute, and that license applies whichever delivery method you pick. Collabora offers CODE, the free edition, but it is released as a rolling build roughly once a month and Collabora describes it as suited to testing, home use or small teams, not production. For a production service, the supported routes are the Business plan, priced at 3 euros per user per month for up to 99 users according to the Collabora Online pricing page, and the Enterprise plan for 100 or more users, which is quoted. Confirm current plan terms, package availability and signing key handling with Collabora before you commit, because subscription access determines which repositories and update channels your servers can use.

Packages, Docker or Kubernetes: which install path fits your servers

Package installs put coolwsd directly on a host that your team builds and patches. This suits organizations with a standard Linux server image, existing configuration management, and administrators who already run systemd services. The host operating system, its kernel, its security updates and its firewall stay under your control, and Collabora's packages are installed alongside them from the deb or rpm repositories.

  • Host ownership: Your team owns the operating system, patch cadence and hardening baseline.
  • Update path: New coolwsd versions arrive through the package manager when you run an upgrade, so you control the change window.
  • Scaling: Each server is sized and load balanced by you, and you decide how many nodes exist.
  • Resource limits: Limits come from the host and systemd settings you define, not from a platform scheduler.
  • Architecture: Confirm the supported architectures for your distribution before you choose hardware.

Before committing, check that your team can maintain package signing keys, repository access and service configuration over the life of the server.

Which configuration files and settings to set at install time

This table compares the configuration areas you touch right after installing Collabora Online from packages: the coolwsd.xml server file, the coolconfig utility, WOPI host allow settings, TLS and listen address, and service-level settings. Read each row as a decision to make before the first users connect, and confirm exact key names against the version you install.

Setting areaWhat it affectsWhen it fits and what to confirm
coolwsd.xml (main server file)Core behavior of the coolwsd service, including network, storage and document handlingEdit before first start and after each upgrade; confirm key names and file location in the installed package
coolconfig (admin tool)Applies configuration changes from the command line and manages the service settings it exposesUse for supported changes so the packaged defaults stay consistent; confirm which keys it can set on your version
WOPI host allow listWhich Nextcloud or other WOPI host servers may request editing sessions from this serverSet to your exact host addresses at install time; a wrong or missing entry blocks document opening
TLS settingsWhether coolwsd terminates HTTPS itself or relies on a reverse proxy in front of itChoose before go-live; if a proxy terminates TLS, confirm which protocol the WOPI host URL must use
Listen address and portWhich interface and port coolwsd accepts connections on, which affects proxy routing and firewall rulesBind to the address your proxy or internal network reaches; confirm the default port and change it only with matching proxy config
Service-level settings (memory, logging, timeouts)Process resource use, log detail and how long idle or long editing sessions are keptReview against expected concurrency; confirm limits with Collabora documentation before raising them in production
Restart and validation after changesWhether new settings are active and whether the WOPI host can still reach the serverRestart the service, then test a document open from the WOPI host to confirm the change took effect

How to install coolwsd from the Collabora repository, step by step

This sequence takes a Linux server from a supported OS and architecture check to a running coolwsd service that answers a WOPI host connection and renders a test document. Each step names the check that confirms it is complete.

  1. Confirm OS and architecture support

    Before touching the server, the operator confirms the distribution and CPU architecture match a package format Collabora publishes. Deb packages cover Ubuntu and Debian, rpm packages cover the RHEL family, and arm64 is available as a deb only, so an arm64 RHEL-family host needs a different deployment path. Check the supported release list in Collabora's documentation for the branch you intend to install, and confirm the host has the fonts, DNS name and TLS certificate planned for users. The step is done when the OS version, uname -m output and chosen branch are written down and match the published packages.

  2. Add the Collabora repository

    The administrator adds the Collabora Online repository for the chosen package type and branch to the server's package manager configuration. On Debian-family systems this is an apt source file, and on RHEL-family systems it is a yum or dnf repository file. Use the repository definition from Collabora's current installation instructions rather than a copied example from an older guide, since branch names change with each release. The step is done when the package manager lists Collabora packages in its metadata with the expected branch name.

  3. Import and verify the signing key

    The administrator downloads Collabora's package signing key over a trusted channel, checks its fingerprint against the value published by Collabora, and then installs it into the package manager's keyring. Do not skip the fingerprint check, because it is the only step that confirms the packages come from Collabora. The Collabora Online 25.04 release notes record that package signing keys were updated for RPM and DEB users, so anyone who installed an earlier 25.04 key should re-import the current one before upgrading. The step is done when the fingerprint matches Collabora's published value and the package manager reports the repository as trusted.

  4. Install the coolwsd package

    The administrator installs the coolwsd package with the native package manager and lets it resolve its dependencies, including the bundled LibreOffice components and any required system libraries. Install a fixed version where change control requires it, and record the exact package version for later upgrades and vulnerability tracking. Expect the package to create the coolwsd service and its default configuration files. The step is done when the package manager reports a successful installation and the coolwsd --version output matches the expected branch.

  5. Edit coolwsd.xml and coolconfig

    The administrator sets the server's public hostname, TLS options, the allowed WOPI host list and the listening address in the main configuration file, which is coolwsd.xml on the default installation. Settings that depend on the host platform, such as the allowed WOPI host or the URL the platform uses to reach the server, must match what Nextcloud or another WOPI host is configured to call. Review the coolconfig settings used by the package for the same host values and for any optional features the organization has decided to enable or disable. Keep a copy of the original files so changes can be reviewed and reverted. The step is done when the file parses without errors and the hostname and allowed hosts match the platform configuration.

  6. Restart and enable the service

    The administrator restarts the coolwsd service so the new configuration loads, then enables it so it starts after a reboot. On systemd-based distributions this is a systemctl restart coolwsd followed by systemctl enable coolwsd, and the administrator checks the status and recent journal entries for configuration errors or port conflicts. A reverse proxy in front of the server must also be running and pointed at the coolwsd listening port. The step is done when the service reports active, is enabled at boot and the journal shows no repeated errors.

  7. Verify with a WOPI connection and a test document

    The administrator confirms the server accepts a real WOPI connection by opening a test document from the connected host, such as a Nextcloud instance with the Nextcloud Office app pointed at this server. Use a document with known content in a format the organization relies on, such as docx, xlsx or pptx, and check that it loads, accepts edits and saves back to the host. Also check the WOPI host allow list logs and confirm that a request from an address outside the allowed list is refused. The step is done when the test document opens, edits save and the logs show the expected allowed and refused requests.

Editing coolwsd.xml and coolconfig without breaking the next update

Treat the package-owned configuration as read-only and keep your changes in a separate, versioned layer. The package manager owns the default coolwsd.xml and the coolconfig helper that ships with the server, and a package upgrade may replace them. Before you edit anything, confirm on your own distribution where these files live and which ones are marked as configuration files by the package manager (for example, by listing the package's file manifest with your distribution's query tool). Record the exact coolwsd version you installed, then make each change as a small, documented edit in a Git repository or configuration management system, with a comment explaining why it exists. Keep the list of changes short. Every local edit is one more thing to reconcile when the vendor changes a default. Test your override file against a staging host before it reaches production.

Use systemd for every service action so that start, stop and log checks behave the same across hosts. Run systemctl enable --now coolwsd once to start the service and set it to start at boot, then use systemctl status coolwsd to confirm the unit is active and to see the most recent log lines. Read detailed output with journalctl -u coolwsd, adding --since to narrow the window around a restart. Confirm the unit name on your distribution before scripting against it. After every package update, restart the service during a planned window, then check that the status is active, that the journal shows no new errors at startup, that your WOPI host can open a test document in a browser, and that the version reported by the package manager matches what you approved. Also confirm that the security advisories and signing key changes listed in the Collabora Online release notes have been applied to your branch.

Security controls to set during the package install

Most of the controls that matter for a Collabora Online server are set while the packages are installed and the first configuration is written, not after go-live. The cards below cover what to verify before installing, what to restrict once coolwsd is running, and how to keep the server patched over its lifetime.

Verify the repository signing key

Before adding Collabora's deb or rpm repository, confirm the signing key fingerprint against the value published by Collabora rather than trusting the first key you download. Import it into the package manager's trusted keyring and check that the repository file points at that key. A repository added over an unverified connection can deliver a modified coolwsd build, so treat the key check as a required step in your install runbook. Record the fingerprint in your change ticket so later audits can see what was trusted.

Restrict WOPI hosts to known addresses

coolwsd only should accept WOPI requests from the hosts that legitimately embed it, such as your Nextcloud servers. Set the allowed WOPI host list in coolwsd.xml during install, using the addresses or names of those servers, and keep it as narrow as your topology allows. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers, so apply the same discipline on both sides of the connection. Review the list whenever a Nextcloud node is added or retired.

Use HTTPS for the Collabora URL

The Collabora server URL that Nextcloud and browsers use should match the protocol of the Nextcloud installation, and HTTPS is the preferred choice. Plan certificate issuance and renewal before the first user connects, and decide whether TLS terminates at a reverse proxy or inside coolwsd. Confirm that the certificate chain is trusted by every Nextcloud host, because a mismatch between HTTP and HTTPS settings is a common cause of failed editor sessions. Document where the private key lives and who can read it.

Run the service under a dedicated account

The coolwsd service should run under its own unprivileged system account, not root and not a shared administrator login. Confirm the account owns only the directories it writes to, such as its log and cache paths, and that the configuration file is readable by the service but writable only by administrators. Keep the account out of interactive login groups. Check the systemd unit after installation so that the service is not granted more capabilities than the editing workload requires.

Apply signed security updates promptly

Collabora publishes security fixes as point releases within each branch. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, so a server still on an older 25.04 point release needs that update. Subscribe to the release notes, set a patch window that your change process can meet, and verify package signatures during each update. Track which branch you run, because point releases do not move you to a new major branch.

Keep package signing keys current

Collabora has updated package signing keys for RPM and DEB users in the past, so a key that worked at install may be replaced later. Include key rotation in your patch process: when Collabora announces a new key, import it through the documented procedure and confirm that updates still verify before retiring the old key. Failing to rotate can block security updates or push teams to disable signature checks, which removes the protection the key provides. Assign an owner for this check.

Questions teams ask before installing Collabora Online from packages

Can our team install Collabora Online from packages without outside help?

Yes, many teams with Linux administration experience can install coolwsd from Collabora's deb or rpm repositories on their own. The package install itself is the short part. The effort comes from what surrounds it: a correct coolwsd.xml, a reverse proxy with WebSocket routing, TLS, font installation, allowed WOPI host settings and a tested update routine. Ask whether your administrators have run a TLS-terminating reverse proxy and handled WebSocket traffic before, since that is where first installs usually stall. A short internal pilot on a non-production host will show quickly which of these gaps you have.

What drives the effort and cost of a package installation?

The cost is mostly staff time, plus any subscription you choose. The main drivers are:

  • Team skills in Linux, certificates, proxies and Nextcloud or other WOPI host configuration
  • OS hardening required by your security baseline, such as firewall rules, service accounts and log collection
  • Reverse proxy design, including subdomain layout and timeouts for long editing sessions
  • Font requirements, since document fidelity depends on the fonts users expect
  • Testing with your real document set and the formats your users open most
  • Subscription plan, if you choose one

For subscriptions, the Business plan is listed at 3 euros per user per month for up to 99 users, according to the Collabora pricing page. Enterprise pricing for 100 or more users is quoted, so ask for a written quote.

What does the work need from our team?

You need a Linux server or virtual machine that Collabora supports for the package route, administrative access to install packages and manage services, and a DNS name and certificate for the Collabora endpoint. You also need a contact who knows the WOPI host, usually Nextcloud or another platform, and who can change its configuration. Someone should own the document test set and sign off on rendering. Plan for a change window for updates and a named person to read security advisories. Confirm supported architectures and operating system versions against Collabora's current documentation before you order hardware.

How long does it take to get the first working document open?

The first document can open within a short working session once the server, DNS, certificate and proxy are in place, but the duration depends on those prerequisites rather than on the package install. Teams that already run a reverse proxy and have a certificate process move quickly. Teams that need new network paths, firewall approvals or identity changes usually take longer. No duration is set by Collabora for this step, so build your own plan from your environment and test it end to end with a real WOPI host before announcing the service.

How are Collabora Online updates applied on package installs?

Updates come through the same deb or rpm repositories you installed from, so you apply them with your normal package manager and then restart the service. Collabora's 25.04 release notes show point releases such as 25.04.7.5 fixing CVE-2026-23623, and they also record that package signing keys were updated for RPM and DEB users. That means your team must check that repository keys stay current, not just that packages upgrade. Test each update on a staging server with your fonts and sample documents, then schedule the production change. Check the release notes before each upgrade for configuration changes.

When do we need a subscription instead of CODE?

CODE, the free edition, is described by Collabora as suited to testing, home use or small teams and not recommended for production. It is also a rolling release, released on average once a month. If you need a production service with long term support, a service level agreement, signed security updates and customer portal access, the Business plan fits that need, according to the Collabora pricing page. Compare those listed terms against your own availability and patching requirements, and confirm in writing what your chosen plan covers before you go live.

Does the Collabora Online server code use a permissive license?

The server code is licensed under the Mozilla Public License 2.0 (MPL-2.0), according to the COPYING file in the CollaboraOnline/online repository. MPL-2.0 is a file-level copyleft license, so modifications to MPL-licensed files you distribute must be shared under the same terms. Review the license with your legal or open-source compliance team, especially if you plan to modify source code, and check the subscription terms separately because they govern the support and updates you receive.

What a fixed-scope package install covers at DeployOpen

A fixed-scope package install starts with a written scope that pins down the details most likely to change the work: the target operating system and release, the CPU architecture of each server, whether the deployment is on x86-64 or arm64 hardware, and which package repository channel will be used. The scope also records the reverse proxy in front of coolwsd, the WOPI hosts that will be allowed to call it (for example, one or more Nextcloud instances), the hostname and TLS arrangement, the fonts users expect to see in rendered documents, and the testing and handover steps that close the engagement. Each of these decisions alters the configuration file and the verification work, so a scope that leaves them open tends to produce an estimate that later moves.

Ask DeployOpen to state in the scope which document formats and test files will be opened, edited and saved during acceptance testing, and who on your side signs off on the results. The handover should name the coolwsd.xml settings that were set, the location of the repository key and version pins, the service unit that runs the server, and the steps your operators will follow for a later package update. Confirm also whether the work includes a test against your actual WOPI host, since a server that starts cleanly can still fail when a host connects.

DeployOpen does not publish a price list. A quote follows from the written scope, so the cost of a package install depends on how many servers and environments are involved, how many WOPI hosts need configuration, how much font and format testing is requested, and whether the work includes a handover session for your team. Ask for the quote to separate one-time setup from any recurring support, and ask which items are excluded so that you can plan the remaining work internally. Retainers for ongoing support and updates are priced separately from the install.

How DeployOpen scopes, installs and supports Collabora Online

DeployOpen plans, installs, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Collabora Online on Linux packages, we start from a written scope that names your distribution, architecture, WOPI hosts and network layout before any server is touched.

How we scope

  • Confirm the Ubuntu, Debian or RHEL-family versions and CPU architectures your servers run.
  • Record which WOPI hosts, such as Nextcloud, will call the server and over which URLs.
  • Agree in writing which coolwsd.xml and coolconfig settings are in scope and who owns them.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

  • Add Collabora's package repository and verify its signing key against the vendor's published guidance.
  • Install coolwsd, set allowed WOPI hosts and TLS options, then restart and confirm the service state.
  • Test document open, save and co-editing from each WOPI host using your own sample files.
  • Keep configuration changes in version control so every later edit can be reviewed and reverted.

How we hand over

  • Deliver a runbook covering install steps, configuration files, service commands and known failure points.
  • Document the package update procedure, including how signing key rotations will be applied on your servers.
  • Walk your operations team through the setup and record who will perform each recurring task afterward.
  • Provide a checklist your own auditors or assessors can use, without DeployOpen issuing any attestation.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • Retainer scope can cover applying point releases and reviewing Collabora's security advisories on your schedule.
  • Ask for the support response terms, upgrade windows and escalation path in the written quote before signing.
  • Support work stays inside your infrastructure, so your data and credentials never leave your environment.

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com