Please find all information on updates, features, and fixes of the Collabora Online Controller on this page. Details about security updates are available here.
Collabora Online Controller 1.4.0
Released on 24th August 2026
Versions
- COOL Controller 1.4.0. Chart version and appVersion are both 1.4.0.
- collabora-online-umbrella 1.5.0. It depends on cool-controller 1.4.0 and collabora-online 1.3.1.
Actions to take when you upgrade
- With leader election on, every controller pod reports ready. The service picks the leader by the
cool-controller.collabora.com/leaderlabel. Drop any monitoring rule that treated an unready controller pod as a fault. Upgrades no longer have a gap where no controller answers.
New settings
extraVolumes,extraVolumeMountsandextraEnvVars– extra volumes, mounts and environment variables for the controller pod.
Each one is described in the chart’s values.yaml, next to the value it belongs to.
High availability
- A standby controller pod answers the readiness probe, so the deployment counts as fully available.
- The pod holding the lease marks itself with the leader label and gives it up when the lease passes on.
Collabora Online Controller 1.3.0
Released on 18th August 2026
Versions
- COOL Controller 1.3.0. The cool-controller chart version and its appVersion are both 1.3.0 now, so the chart and the binary carry one number.
- collabora-online-umbrella 1.4.0, up from 1.3.3. It depends on cool-controller 1.3.0 and on collabora-online 1.3.0.
Actions to take when you upgrade
- Set
documentMigrator.coolMemoryUtilizationclearly belowtargetMemoryUtilizationPercentageof collabora-online. With the two figures equal, a pod only starts handing documents over at the moment the autoscaler asks for another pod, and it can run out of memory while that pod starts up. documentMigrator.coolMemoryLimitis read as decimal megabytes. A limit written as8000Micounts as 8388 megabytes inside the controller. Write it as8000Mif you want the controller to work to the same figure as the pod limit. This reading is the same as before and is written down here because it decides when documents start moving.- The controller refuses to start on two configurations it used to accept. With the migrator enabled, a
coolMemoryLimitthat works out below one megabyte is refused, and a value written with no unit at all counts bytes. A geolocation setup that is enabled while itsserverscount is below one is refused as well. AdocumentMigrator.migrationIntervalshorter than 5s falls back to 30s and says so in the log. - A helm upgrade that changes a controller setting now restarts the controller pod, so the controller reads the new setting.
- The controller creates the election lease itself, so you no longer need to delete the lease by hand during a clean update.
New settings
expectedDocumentMemory(default 100M) – the memory a document is expected to use once it is open. Raise it for a deployment whose documents are larger than a few pages.documentMigrator.migrationInterval(default 30s) – how long the controller waits between one look at pod memory and the next.debugServer.enabledanddebugServer.port(default 9001) – serves the profiles of the go runtime on a port of its own, absent from the service and the ingress. Reach it withkubectl port-forward.
Each one is described in the chart’s values.yaml, next to the value it belongs to.
Routing and load spreading
- A document is recorded against the id of the pod it is open on rather than against a route token, and the route tokens, pod names and locations are published together as one value that is replaced whole.
- A pod is charged for the documents handed to it that it has not reported yet, so documents arriving inside one reporting window are spread across pods instead of all going to the pod that reported the least memory.
- A pod keeps its recorded load when its monitor connection comes back, and a pod that has not reported since it connected counts as the memory it last reported rather than as empty. Either one used to draw a run of new documents.
- A new document only goes to a pod the published layout holds a route token for.
- A token refresh that cannot reach a pod keeps the tokens already published. Such a refresh used to leave the controller with nothing to route to.
Document migration
- A pod whose documents are all open for editing now has one of them moved off it. Such a pod used to be passed over and kept filling.
- A migration works from the memory of the pods it can move a document to, and leaves out the pods that are draining.
- Documents move only while the connected pods hold the published route tokens, and once a document has moved, the requests for it go to the pod that reports it.
- A move that gets no acknowledgement still records where the document went.
Toolchain
Built with Go 1.25.13 for security fixes.
Known issue
The Collabora Online 26.04.2.1.1 image never connects its monitor to the controller, which leaves the controller with nothing to route. Use 26.04.2.4.1 or later.
Collabora Online Controller 1.2.0
Released on 17th July 2026
Bug Fixes/Improvements
- Make URL parsing compatible with COOL 26.04
- Action Required
- Use Collabora Online Controller 1.2.0 with COOL 26.04 Use umbrella helm charts: 1.3.0
Collabora Online Controller 1.1.11
Released on 22nd June 2026
Bug Fixes/Improvements
- Bump Go version to 1.25.11 for security fixes
- Action Required:
- Use umbrella helm charts: 1.1.15
Collabora Online Controller 1.1.9
Released on 24th April
Bug Fixes/Improvements
- Bump Go version to 1.25.9 for security fixes Switch base docker image to use
gcr.io/distroless/static-debian12:nonroot - Action Required Use umbrella helm charts: 1.1.13
Collabora Online Controller 1.1.8
Released on 17 March 2026.
Bug Fixes/Improvements
- Bump Go version to 1.25.8 for security fixes
- Action Required
- Use umbrella helm charts: 1.1.12
Collabora Online Controller 1.1.7
Released on 3 December 2025.
Bug Fixes/Improvements
- Fixed a bug where leaderElection is enabled we sometimes end up in deadlock situation where no-one is leader
Bump Go version to 1.25.5 for security fixes
Action Required
- Pre‑upgrade cleanup to avoid stale leadership and leases:
kubectl delete -n deployment && kubectl delete lease collabora-online -n- Use umbrella helm charts: 1.1.11
Collabora Online Controller 1.1.6
Released on 13 November 2025.
Features
- Fixed leader election lease duration calculation that caused leases to be created with 705032704 seconds (22 years) instead of the configured 10 seconds. This prevented proper leader failover when controller pods crashed or restarted.
- Bump Go version to 1.25.3 for security fixes
Collabora Online Controller 1.1.5
Released on 15 October 2025.
Features
Internal Cluster Communication
- Enables direct communication between COOL Controller and Collabora Online within the Kubernetes cluster, bypassing external network routing for improved performance and reduced latency
- Enhances security by keeping all controller-to-COOL traffic internal to the cluster network
- Reduces network overhead and eliminates unnecessary external ingress/egress traffic
- For detailed setup instructions, refer to the sdk.collaboraonline.com
Collabora Online Controller 1.1.4
Released on 29 August 2025.
Features
- Remote dynamic configuration via
/controller/remoteconfighttps://sdk.collaboraonline.com/docs/installation/Configuration.html?#remote-dynamic-configuration - Health/readiness split: /healthz and /readyz; only the elected leader becomes Ready.
Bug Fixes/Improvements
- Leader‑only serving; followers remain Healthy but never Ready.
- Lease cleanup on uninstall to prevent orphaned leader‑election locks.
- Runs as unprivileged user by default.
- Monitor Origin mismatch resolved (COOL adds “Origin”; accepted correctly).
- No traffic forwarded to followers.
Action Required
- Pre‑upgrade cleanup to avoid stale leadership and leases:
kubectl delete -n <namespace> deployment <deployment-name> && kubectl delete lease collabora-online -n <namespace>- Use helm charts: umbrella 1.1.6; controller 1.1.7.