Running Collabora Online on ARM64 servers

Running Collabora Online on ARM64 servers: when arm64 is a practical choice

Choose arm64 when it reduces cost or fits an existing fleet, but confirm support for each component before you commit. Many teams look at arm64 because they want browser document editing inside Nextcloud or another WOPI host on cheaper or already-standardized hardware. The Collabora Online server code is licensed under the Mozilla Public License 2.0 (MPL-2.0), and the free CODE Docker image is published for arm64 alongside x86-64 and ppc64. That makes arm64 a credible target, but publication alone does not settle the question. Confirm with Collabora which architectures and package repositories your chosen edition covers, and check the same for the host operating system, your reverse proxy and any fonts or helper components your documents depend on.

Treat the free CODE image with care at this stage. Collabora describes CODE as a rolling release, published on average once a month, and recommends it for testing, home use or small teams rather than production. A pilot on arm64 with CODE is a reasonable way to exercise your WOPI host integration, but the production decision should be made on a supported build for the same architecture. Ask Collabora whether the subscription offering covers arm64 for your package format or container image, and whether its release cadence and security advisories apply to that architecture as well.

Before rollout, run a performance test on the exact instance type you plan to buy, not on a similar-looking one. Arm64 cloud instances and servers differ in core count, memory bandwidth and per-core speed, so a result from one vendor does not transfer to another. Open a realistic mix of DOCX, XLSX and PPTX files, simulate concurrent editing sessions at the level you expect, and record conversion and load times against an x86-64 baseline if you have one. Use the outcome to set resource limits and decide how many servers you need. Document the results so that a later architecture change or upgrade has a fixed point of comparison.

Install options on arm64 and when each fits

This table compares the four ways to install Collabora Online on arm64 hardware: the CODE image, deb packages, rpm packages and the Helm chart. Read each row against your distribution, your subscription position and the team's orchestration skills to narrow the route before you test performance.

Install route	When it fits	What to confirm	Main trade-off
collabora/code Docker image	Pilot, test or small team on arm64 cloud instances where a single container is enough	The image tag supports arm64, and the support position for production use with CODE	CODE is a rolling release not recommended for production, so a supported route is needed later
Deb packages from Collabora's repository	Ubuntu or Debian arm64 hosts where you want coolwsd managed as a system service	The repository publishes arm64 builds for your exact release, and your subscription covers the package channel	You own OS patching, service configuration and the reverse proxy in front of coolwsd
Rpm packages on RHEL-family hosts	RHEL-family arm64 hosts already managed through dnf or yum	Whether Collabora's repository provides an arm64 rpm for your distribution and version; do not assume it does	If no arm64 rpm exists, you need an alternative route or an x86-64 host, which changes your architecture plan
Kubernetes with the official Helm chart	Clusters with arm64 worker nodes and a team that already runs ingress and manual replica control	Image architecture on your nodes, the ingress you will use, and that replicas are set manually because autoscaling is disabled	Highest orchestration effort, and WOPISrc-aware routing must be designed before users arrive

Which arm64 route fits your host and team

A single arm64 virtual machine or bare-metal server running Ubuntu or Debian is the most direct route. You add Collabora's deb repository, install the coolwsd package for arm64, then edit coolwsd.xml and coolconfig and place a reverse proxy in front of the service.

Install method: import the repository signing key, add the repository for your release, install coolwsd, and manage the service with your init system.
Verify first: run uname -m to confirm aarch64, then check that the repository lists arm64 packages for your exact OS release before you write any configuration.
Check fonts: confirm that the fonts your users expect are installed, because missing fonts change pagination and layout in documents that look correct elsewhere.
Operational work added: you own OS patching, applying point releases on the branch you chose, and checking that signing keys stay current.

Before any user traffic reaches the server, confirm the installed package version matches the branch you intend to run and that the WOPI host allow list in coolwsd.xml contains only your intended hosts.

Do not assume that RPM packages exist for every architecture that deb packages cover. Before you plan a RHEL-family arm64 fleet, confirm with Collabora whether its RPM repositories publish aarch64 builds for your release. If they do not, the deployment must use a different package path, and the choice changes how you patch and support the estate.

Install method: if aarch64 RPMs are published for your release, install coolwsd from the RPM repository and account for SELinux policy and firewall rules. If they are not, plan a container route or a deb-based arm64 host for this workload.
Verify first: check the repository metadata for the aarch64 architecture, the RHEL-family release you run, and the signing key you will import.
Check policy: test SELinux and firewall settings in a staging host, because a fleet-wide policy can block the service even when the package installs cleanly.
Operational work added: if your fleet mixes package paths, you maintain two patching procedures, two sets of evidence and a documented list of exceptions.

Confirm the package path for each host role before you write the fleet build standard, so that no host type is added later without an agreed patch process.

A Docker host on arm64 runs Collabora Online from a container image instead of system packages. The free CODE image, collabora/code, publishes an arm64 build. CODE is a rolling release that Collabora describes as suited to testing, home use or small teams and not recommended for production, so a production container needs the supported image covered in the sibling Docker guide.

Install method: pull the image for linux/arm64, set the environment variables for allowed WOPI hosts and TLS, and grant only the container capabilities the service requires.
Verify first: run docker manifest inspect on the image tag and confirm an arm64 platform entry exists, then confirm the same for the subscription image you plan to run.
Pin tags: record the exact image tag in your deployment files, because a rolling tag changes what runs after a routine pull.
Operational work added: you handle image updates by tag, host kernel and Docker engine updates, volume backups and restart behavior after host reboots.

Before go-live, pull the image on the target arm64 host, start it with your production settings and confirm the WOPI allow list and proxy path work before you connect the first client.

Why the missing arm64 rpm path changes RHEL-family plans

If your servers run a RHEL-family distribution on arm64, do not assume the Linux package route works the way it does on x86-64. The supplied facts do not confirm an arm64 rpm package for coolwsd, so the first task is to verify what Collabora actually publishes for your distribution and architecture. Check the package repository listed in Collabora's installation documentation, look for an aarch64 directory or metadata entry for your major release, and confirm the repository signing key is the current one. Do this before you size hardware, draft change requests or promise a date to the application owners, because the answer decides which of the options below you are choosing between.

If no arm64 rpm exists for your release, you have three realistic paths. The first is a deb-based arm64 host (for example Ubuntu or Debian), which the Linux package route supports on arm64 according to the installation guidance you will verify, and which suits teams whose platform standard allows a second distribution family. The second is the container route, using the arm64 variant of the CODE image or a supported production image, but this moves patching, image provenance and support responsibility to your team unless you hold a subscription that covers the image. The third is a platform decision made earlier, such as a standard that already fixes RHEL-family hosts, which means you either accept the container route under your own support model or negotiate the exception before build starts.

Confirm four things in writing with Collabora: whether an arm64 rpm build exists for your exact RHEL-family release, which deb and container artifacts they support on arm64, whether the subscription you are considering covers each artifact, and how they deliver security updates for each path. Then check your own repository mirror, because an internal copy may lack the arm64 metadata even when the upstream repository has it. Record the answers in the design document so the choice of path is traceable to evidence rather than to assumption.

Set up Collabora Online on an arm64 server in order

This sequence takes an arm64 host from architecture check to a verified Collabora Online service that a WOPI host can reach and use to open documents. Each step ends with a check, so a failure points to one layer of the stack.

Confirm the host architecture
The platform engineer runs uname -m on the server and checks the instance metadata or hardware record of the cloud or data center platform to confirm the same architecture is reported at both layers. Some virtual machine images run a different userland from the hardware they sit on, so both must agree. The step is done when the output reads aarch64 at the OS level and the platform record matches the arm64 package or image you plan to use.
Choose the package or image for arm64
Decide between Debian packages (deb) from Collabora's repository and the CODE container image, which is published for arm64 along with x86-64 and ppc64. Check that the distribution release you run has an arm64 deb build in the repository before you commit. Confirm with Collabora that no arm64 rpm packages are offered for RHEL-family hosts, so RHEL-family teams should plan a container or a Debian-family host. The step is done when you have written down the artifact, its version and the reason for the choice.
Verify repository keys and signing key updates
Before installing, import the repository signing key from Collabora's official channel and check its fingerprint against the value published in Collabora's documentation. Collabora has updated package signing keys for RPM and DEB users in the past, so confirm you have the current key and a process to refresh it. The step is done when the package manager reports the repository as trusted and an update check runs without signature warnings.
Install coolwsd or start the container
Install the coolwsd package or start the arm64 image with the configuration you have chosen. Keep the container or service on a version your team has tested, and record the exact package version or image tag. Do not run the free CODE image as the production base without a deliberate decision, since Collabora describes CODE as suited to testing, home use or small teams and not recommended for production. The step is done when the package installs cleanly or the container starts and stays running after a restart.
Set allowed WOPI hosts and the public URL
Configure the list of WOPI hosts that may connect to the server, and set the public URL that clients and the WOPI host will use to reach Collabora. Restrict allowed hosts to your Nextcloud or other WOPI host addresses, and use HTTPS for the Collabora server URL, matching the protocol of the WOPI host where possible. Confirm the exact configuration keys in your version's documentation. The step is done when the server logs no allow list warnings for your WOPI host on startup.
Put the reverse proxy in front
Place Nginx, Apache or HAProxy in front of the service with TLS termination, and forward the discovery paths and WebSocket routes that Collabora needs for editing sessions. Set timeouts long enough for extended editing sessions. Confirm that the proxy passes the WOPISrc parameter unchanged, because routing decisions later depend on it. The step is done when the discovery endpoint answers over HTTPS through the proxy with a valid certificate.
Check service health
Run systemctl status coolwsd on package installs, or check the container status and logs on container installs. Then request the discovery and health endpoints from the WOPI host network and from outside it, and confirm that each returns the expected response. Review the logs for startup errors, font warnings and WOPI rejections. The step is done when the service reports active, the endpoints respond through the proxy, and the logs show no errors on a clean restart.
Open a test document from the WOPI host
From the WOPI host, open a test document in each format your users need, such as docx, xlsx and pptx, and make a small edit in each one. Test one account with edit rights and one with view-only rights, and confirm that the view-only account cannot save changes. Compare how the text and layout render against the original file. The step is done when every test document opens, saves and reopens correctly, and the rendering differences you see are written down for your fidelity review.

Security and patching considerations on arm64

On arm64, the security work is the same as on x86-64, but it has more places to go wrong: a package signing key, a point release, a network allow list, a transport setting, or an image built for the wrong architecture. Each card below is a control to check before production and again after every update.

Keep package signing keys current

Collabora updated the package signing keys for RPM and DEB users in the 25.04 release line. If your arm64 hosts still trust an older key, repository updates can fail or you may be tempted to bypass verification. Confirm that each arm64 host imports the current key from Collabora's repository before you add the repository to your mirror, and record the key fingerprint in your change log.

Apply security point releases promptly

Collabora publishes point releases within each branch, and the 25.04 branch shipped 25.04.7.5 on January 29, 2026 to fix CVE-2026-23623. Point releases on arm64 need the same testing as x86-64 builds, but the rollout window should not depend on how long a performance test takes. Keep a staging arm64 host on the same version as production so a fix can be validated quickly.

Restrict WOPI requests to Collabora IPs

The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. On an arm64 cluster or a set of cloud instances, those addresses can change when instances are replaced, so the allow list must be updated as part of your provisioning. Confirm the addresses with your network team and test that Nextcloud can still open a document after each change.

Use HTTPS for the server URL

The Nextcloud manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. A mismatch between HTTP and HTTPS causes connection failures, and plaintext traffic exposes document content and session data on the network. Check the certificate chain on each arm64 host and at the reverse proxy, and confirm that the URL configured in Nextcloud matches the public name in the certificate.

Verify the arm64 artifact before production

Confirm that the package or image you deploy is the one Collabora publishes for arm64. The free CODE Docker image is published as collabora/code for x86-64, ppc64 and arm64, so check the architecture of the pulled image and the package architecture before you promote it. Pin the image by tag or digest, and keep the checksum and signature records with your deployment artifacts so you can prove what was installed.

How to test Collabora Online performance on arm64 before rollout

Architecture alone does not decide capacity. An arm64 server being supported does not tell you how many editing sessions it will carry, so the test has to use the instance type, document mix and concurrency your organization expects in production. Start by writing down the target instance size, the number of concurrent editors per server you plan for, and the document types users open most. Then compare the arm64 result against the reference the official Helm chart gives for production pods: limits of 8 CPU cores and 8000 MiB of memory, with requests of 4 cores and 6000 MiB. Treat these as a starting reference only. The chart's figures were set for its own deployment context, so you must confirm with Collabora whether they apply to your arm64 target before using them to size anything. If your arm64 instance differs in core count, memory or storage speed, record that difference in the test report so the numbers can be read correctly.

Build the test document set from real files, not samples chosen for convenience. Include the Microsoft formats your users actually exchange (docx, xlsx and pptx), OpenDocument files, and a few large spreadsheets and presentations with embedded images, since these drive memory use most. Run concurrent editing sessions against the same documents as well as separate ones, because multiple users in one document exercise a different code path than many users in many documents. Include copy and paste between two open documents and between Calc and Writer in the scripted run. Copy and paste is the function most sensitive to load, so a server that looks fine while typing can still fail here. Confirm with your Nextcloud or other WOPI host that the session load you simulate matches how the host opens documents in practice.

Record latency for keystroke echo, document load time and save time at each concurrency step, and record resident memory and CPU per coolwsd process over the full run. Increase concurrency in steps and stop at the first step where latency or memory becomes unstable, then note the last stable step as your working capacity. Repeat the run after any change to the Collabora Online version, because each release can change resource use, and use a test environment that mirrors your production proxy and WOPI allow list settings. Keep the raw results so the arm64 and x86-64 figures can be compared directly if you later need to choose between them. Ask Collabora or your implementation partner which metrics they expect you to record for a go or no-go decision before the test begins.

Limits to confirm on your arm64 environment

Collabora's arm64 support depends on the package format, the image, the operating system and the release branch you choose. The cards below list the points to confirm with Collabora and in your own environment before you commit hardware, images or a rollout date, since each one can change the deployment path.

Supported packages and images

Confirm which packages and images Collabora supports for your exact architecture and operating system version. Check the arm64 deb packages for your distribution release and the arm64 build of the CODE image separately, because a published image does not prove that the matching system package exists for the same release. Record the package name, repository and image tag you tested so the rollout uses the same artifacts.

Subscription status of the image

Confirm whether the arm64 image you plan to run is the free CODE edition or a supported subscription build. CODE is a rolling release that Collabora describes as not recommended for production, so a production arm64 host usually needs a different artifact with its own update and support terms. Ask Collabora which image and tag carry the support commitment you need.

Font and rendering fidelity

Confirm that documents render correctly on the arm64 host after installation. Compare pagination, line breaks and embedded fonts for the Microsoft and OpenDocument files your users actually open, and check that the fonts in the system template are present on this architecture. Repeat the check after every update, because a font gap can appear without any change to the document.

Instance sizing for the workload

Confirm that the chosen arm64 instance type meets your concurrency and memory needs. Load test with realistic document sizes and realistic numbers of simultaneous editors, and watch CPU, memory and response times rather than relying on vendor sizing from x86-64 hardware. The Helm chart's production figures are a reference point for x86-64 pods, not a guarantee for arm64 instances.

RPM coverage for your distribution

Confirm that an rpm package exists for your distribution, version and architecture before choosing a RHEL-family server. Collabora's rpm coverage differs from its deb coverage, so an arm64 Linux estate may need a different distribution or a container path. Ask for the supported list in writing and keep it with your change records.

WOPI host version compatibility

Confirm that your WOPI host, such as a Nextcloud release, supports the Collabora release you plan to run. Check the host's documentation for the minimum and maximum supported connector behavior, and confirm the WOPI host allows the Collabora server URL over the same protocol as the host. A version mismatch can break editing even when the Collabora server starts cleanly.

Questions teams ask before running Collabora Online on arm64

Does Collabora Online support arm64 servers?

Yes for the container route, and the answer depends on the package route you plan to use. The free CODE Docker image is published as collabora/code for x86-64, ppc64 and arm64, so arm64 hosts can run it. For Linux packages, check Collabora's deb repository for the exact coolwsd package for your Ubuntu or Debian release on arm64 before you plan the build. The rpm route needs the closest check: confirm whether arm64 rpm packages exist for your RHEL-family hosts. If they do not, you will need a deb-based host, the container image, or a different host OS. Ask Collabora to confirm supported architectures for the edition you intend to run.

Is CODE suitable for production on arm64?

No. Collabora describes CODE (Collabora Online Development Edition) as suited to testing, home use or small teams and says it is not recommended for production. It is released on average once a month as a rolling release, which makes it a poor fit for change control in a regulated environment. CPU architecture does not change that position. A production arm64 deployment should run a supported edition under a plan that provides long-term support, signed security updates and a service level agreement, and CODE is useful for the test phase described in this section.

How much does a Collabora Online Business plan cost?

The Collabora pricing page lists the Business plan at 3 euros per user per month for up to 99 users. The fee recurs monthly and scales with the number of users. The plan includes long-term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan, for 100 or more users, is quoted with volume discounts and adds integration support, customization services and roadmap input. Your own costs sit outside the licence: arm64 hardware or cloud instances, storage, staff time for testing, and any services work. When you request a quote, ask for the per-user rate, the support terms, the contract length, and a list of what is excluded.

How long does arm64 validation take, and what drives it?

No validation duration is published for this work, so treat any figure you are given as a planning assumption to confirm against your own scope. The main drivers are the document mix (Writer, Calc and Impress files, PDFs, Visio and older formats), the fonts your users depend on, the concurrency you need to support, the number of WOPI hosts connecting, and whether you install from packages or from the container image. Plan a load test on arm64 itself. Do not assume x86 benchmark results carry over. Define pass criteria for rendering, editing, collaboration and response times before testing starts, because the number of retest cycles depends on how clearly those criteria were set.

What must our team provide for an arm64 test?

The test needs a small set of inputs from your side. Plan to provide:

An arm64 server or cloud instance sized for the test, with the same operating system you plan to run in production.
A test corpus of documents drawn from your actual files, including the Microsoft and OpenDocument formats, PDFs and any templates your teams use.
Access to a WOPI host, such as a Nextcloud test instance, with a network path to the Collabora server and the WOPI allow list configured.
DNS names and TLS certificates for the Collabora URL, using the same protocol as the host.
Access to logs and basic monitoring, plus a named owner who signs off on results.

If any of these are missing, the test will stall while the gap is filled, so confirm them before the schedule is set.

Can our team test and roll out arm64 ourselves, or do we need a partner?

Your team can do it if it has Linux administration, container and reverse proxy skills, the time to run structured tests, and someone to own the sign-off decision. A partner is worth considering when you have no arm64 experience, lack Collabora sizing experience, need an independent test plan, or want a rollout with a documented rollback path. DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ongoing support and testing are available as retainers.

How DeployOpen scopes and delivers arm64 Collabora Online deployments

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including arm64 hardware and cloud instances. For Collabora Online on ARM64 servers, the work starts with a written scope that confirms the package or image route, the architecture of every host and the performance evidence needed before rollout.

How we scope

Confirm which WOPI hosts, such as Nextcloud, will call the arm64 server and how many users will edit at once.
Record the chosen route in writing: deb packages on arm64 or the arm64 CODE image, and why it fits your hosts.
Agree the performance test plan and acceptance criteria before any build work starts, since engagements are fixed-scope.

How we build

Install and configure coolwsd on the arm64 hosts, with WOPI allow lists, TLS and reverse proxy routes set for your environment.
Run document fidelity and load tests on arm64 against your real file types, and record results alongside the configuration.
Where rpm-based hosts are part of the estate, document the alternative install path agreed in the scope rather than assuming parity.

How we hand over

Deliver configuration files, runbooks for service management and update steps, and the test results used to approve rollout.
Walk your operations team through monitoring, log locations and the process for applying Collabora security updates on arm64.
Document open items, such as any architecture-specific limits found in testing, so your team can decide on them later.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, covering arm64 hosts alongside the rest of the estate.
Re-run performance and fidelity checks when you move to a new Collabora branch or change hardware.
Confirm with us in the quote which support tasks are included, and which need your vendor subscription or your own team.

Running Collabora Online on ARM64 servers