How to Back Up and Restore Collabora CODE Configuration Files Safely

Collabora Online Development Edition (CODE) 26.04.4.2 was released on September 24, 2026. That matters for backup planning because the 26.04 release line also changed parts of the recommended reverse-proxy path handling for newer WebSocket URLs. If you are preparing for an upgrade, migration, or disaster recovery, backing up only one XML file may not be enough to reproduce a working deployment.

The verified core is straightforward: Collabora's main server configuration file is /etc/coolwsd/coolwsd.xml, including inside the official CODE container. The official Docker documentation also supports copying that file out of a container, copying it back, or bind-mounting it from the host. The parts that vary are everything around it: Docker environment variables, bind mounts, WOPI proof keys, TLS termination, and reverse-proxy configuration.

This guide shows a conservative backup-and-restore process for both native package installations and Docker deployments. It intentionally separates what is confirmed by Collabora documentation from what depends on your own deployment.

What Should a Collabora CODE Backup Include?

Verified: /etc/coolwsd/coolwsd.xml is the primary Collabora Online configuration file. Collabora documents this path directly and describes the file as self-documenting for the available server options. See the official Collabora Online SDK manual.

Deployment-dependent: a complete recovery may also require the configuration used to launch the service. For Docker, that can include Compose YAML, environment variables, bind mounts, secrets, and files mounted from the host. For a native installation, it can include a reverse-proxy virtual host and certificates if those are managed on the same server.

Action: before creating an archive, write down whether your instance is a native package installation or a Docker/Compose deployment. Do not assume the same restore procedure applies to both.

Common Misunderstandings Before You Start

Backing up coolwsd.xml does not back up user documents

CODE is normally connected to a storage platform through WOPI. Documents remain under the control of that storage platform, such as Nextcloud or another WOPI host. Restoring CODE configuration therefore does not restore the documents themselves.

Action: back up the WOPI host and its data store using that product's own backup procedure. Treat this CODE backup as a service-configuration backup.

A Docker container is not the backup

A container can be recreated from an image. Configuration passed with environment variables or bind mounts may live outside the container, while edits made only inside the container can disappear when the container is replaced.

Action: save the deployment definition and host-mounted files, not just the container filesystem.

Copying an old coolwsd.xml over a newer version is not always the safest restore

Configuration options can change between CODE release lines. Collabora's current release notes show continuing server and proxy changes in the 26.04 series, including updated proxy recommendations for the compact WebSocket URL. See the official CODE 26.04 release notes.

Action: record the CODE version with every backup. When restoring to a different version, compare the saved file with the new package's default before replacing it wholesale.

Step 1: Record the Installed Version and Deployment Type

Start by recording enough information to reproduce the environment. For a container deployment, inspect the running container and its image:

docker ps --filter name=collabora
docker inspect collabora --format '{{.Config.Image}}'
docker inspect collabora --format '{{json .Mounts}}'

If your container uses a different name, replace collabora accordingly. The official image is published as collabora/code; Docker Hub currently identifies the 26.04.4.2 image in the latest release line. See the official Collabora CODE image on Docker Hub.

For a native package installation, record the package version with the package manager you actually use. On Debian or Ubuntu, for example:

dpkg-query -W 'coolwsd*' 'collaboraoffice*' 2>/dev/null

Action: save the version output in the same protected backup directory as the configuration archive.

Step 2: Back Up the Core Configuration and Deployment Metadata

Native package installation

Create a root-only backup directory and archive the complete /etc/coolwsd directory rather than selecting only the main XML file. That preserves any additional files that your installed package or local customization has placed there.

sudo install -d -m 700 /var/backups/collabora
sudo tar -C /etc -czpf \
  /var/backups/collabora/coolwsd-etc-$(date +%F).tar.gz \
  coolwsd

This command deliberately changes to /etc before archiving, so the archive contains a relative coolwsd/ path instead of an absolute filesystem path.

Docker or Docker Compose

Collabora's documentation states that the official image contains /etc/coolwsd/coolwsd.xml and that administrators can copy it out, modify it, copy it back, or mount it from outside the container.

If the file is not already bind-mounted from the host, copy it out:

sudo install -d -m 700 /var/backups/collabora
docker cp collabora:/etc/coolwsd/coolwsd.xml \
  /var/backups/collabora/coolwsd.xml

Next, capture how the container was configured:

docker inspect collabora --format '{{json .Config.Env}}' \
  > /var/backups/collabora/container-env.json

docker inspect collabora --format '{{json .Mounts}}' \
  > /var/backups/collabora/container-mounts.json

Important: environment output can contain passwords, admin-console credentials, hostnames, or other secrets. Keep these files root-readable only and encrypt or otherwise protect off-host copies.

If you use Docker Compose, copy the actual Compose file and any referenced environment or secret files from the host. Their locations are specific to your deployment, so there is no universal path that can be safely assumed.

Action: confirm that your backup includes the source of truth. If coolwsd.xml is bind-mounted, back up the host file. If configuration is supplied through environment variables, preserve the Compose/run configuration that defines those variables.

Step 3: Include Proof Keys, Proxy Configuration, and TLS Only When They Apply

These components are important precisely because they are not identical on every installation.

WOPI proof key: Collabora documents that RPM and DEB installations generate the WOPI proof keypair automatically. For Docker, the keypair is not shipped in the public image; when used, it must be generated and supplied to the container, typically through a volume. The manual documents coolconfig generate-proof-key for generating the key. Because the Docker key lives outside the immutable image, losing the host-side mounted key can change the identity used for WOPI proof signing.

Action: use the container's mount list to identify the host location of any proof-key mount and back up that host-side file or directory securely. Do not invent a path if your deployment does not use one.

Reverse proxy: Apache, Nginx, HAProxy, Traefik, or another proxy may hold the public hostname, TLS termination, WebSocket routing, and request forwarding rules. In CODE 26.04, Collabora updated proxy guidance for the newer compact WebSocket URL while retaining a legacy fallback in some cases.

Action: back up the exact proxy configuration that serves your Collabora hostname. Its filesystem path depends on your operating system and proxy, so identify it from the active proxy configuration rather than copying a generic path from a tutorial.

TLS certificates: back them up only if this host actually owns them. If TLS is terminated at a load balancer, ingress controller, CDN, or separate reverse proxy, the certificate backup belongs there instead.

Step 4: Verify the Backup Before You Need It

A successful tar command is not enough. Test that the archive can be listed and that the expected main configuration file is present.

sudo tar -tzf /var/backups/collabora/coolwsd-etc-$(date +%F).tar.gz \
  | grep 'coolwsd/coolwsd.xml'

Create a checksum for off-host verification:

cd /var/backups/collabora
sha256sum * > SHA256SUMS

Then copy the backup to a second protected location using your normal backup system. Do not leave the only copy on the same host you are protecting.

Action: test extraction into a temporary directory at least once. A backup you have never opened is only an assumption.

Step 5: Restore Conservatively, Then Validate the Running Service

Restore a native installation

Prefer installing the same CODE release first. Stop the service, extract the archive to a staging directory, and compare the saved configuration with the newly installed default:

sudo systemctl stop coolwsd
sudo mkdir -p /root/collabora-restore
sudo tar -xzf /var/backups/collabora/coolwsd-etc-YYYY-MM-DD.tar.gz \
  -C /root/collabora-restore

sudo diff -u \
  /etc/coolwsd/coolwsd.xml \
  /root/collabora-restore/coolwsd/coolwsd.xml

If the versions match and you intend a full replacement, first retain the fresh directory as a rollback copy:

sudo cp -a /etc/coolwsd /etc/coolwsd.pre-restore
sudo cp -a /root/collabora-restore/coolwsd/. /etc/coolwsd/
sudo systemctl start coolwsd

If the versions differ, merge the settings you actually changed instead of blindly replacing the new file. This avoids discarding new defaults or required elements introduced by the newer release.

Restore a Docker deployment

Recreate the container from the recorded image version and original Docker Compose or docker run definition. Restore host bind-mounted configuration, proof keys, and other external files to their original host paths before starting the container.

If you deliberately kept coolwsd.xml inside the container rather than as a bind mount, Collabora's documented approach permits copying the file back. In practice, a host bind mount is easier to reproduce because the configuration survives container replacement.

Action: restore the deployment definition first, then restore the files it references. This keeps environment variables, volumes, and the XML configuration consistent with one another.

How to Confirm the Restore Actually Worked

Do not judge success only by whether the process starts. Check the service from the same network path used by clients.

For a native installation:

sudo systemctl status coolwsd --no-pager
sudo journalctl -u coolwsd -n 100 --no-pager

For Docker:

docker ps --filter name=collabora
docker logs --tail 100 collabora

Collabora documents the /hosting/capabilities endpoint as a way to retrieve, among other information, the running product name and version. Through your public Collabora URL, test it with:

curl -fsS https://office.example.com/hosting/capabilities

Replace the hostname with your own. Also open a real document from the WOPI host and verify that editing, saving, and reconnecting work through the normal reverse-proxy path.

Action: consider the restore complete only after the capabilities endpoint responds and an actual document can be opened and saved.

Practical Backup Checklist

Final Recommendation

The most reliable Collabora CODE recovery plan is not a single copied file. Keep coolwsd.xml, the exact CODE version, and the deployment definition together as one recoverable set. Add proof keys, proxy rules, and TLS material only where your architecture actually uses them. For upgrades, restore into the same release when possible; if you move to a newer release, compare and merge configuration rather than overwriting the new defaults without review.

As of October 6, 2026, CODE 26.04.4.2 is the current release shown by Collabora's official 26.04 release notes and Docker image metadata. Check those official sources again before a future migration because image versions, proxy recommendations, and configuration options continue to evolve.