CollaboraOnline/online: the GitHub repo that is an issue tracker, not the source

What CollaboraOnline/online actually is on GitHub

The repository is not the product's source tree. Its README opens with a notice that active development has moved to a Gerrit instance at https://gerrit.collaboraoffice.com, and that this GitHub repository is kept for two things: issue tracking, and release artifacts. Bug reports and feature requests go to the GitHub issue tracker. The nightly container image, the Helm chart and build assets are published from here. The top level of the repository reflects that narrow scope: .git-hooks/, .github/, CODE_OF_CONDUCT.md, CONTRIBUTING.md, COPYING, README.CONTRIBUTING.md, README.md, SECURITY.md, and two directories, docker/ and kubernetes/. There is no application source directory to compile. That layout is the single most important fact for anyone arriving from a search engine expecting to build an office suite. The README is explicit that pull requests are welcome only for the parts this repository owns, naming the Helm chart under kubernetes/helm/ and the docker image build under docker/from-source-gh-action/.

Who the split between GitHub and Gerrit is for

This arrangement suits two audiences and frustrates a third. It suits operators who want to deploy Collabora Online and file a bug without touching C++ or JavaScript: they get a GitHub issue tracker and a Helm chart in the same place. It suits reviewers who work inside Collabora's own Gerrit workflow, where code review for the application source happens. It does not suit a developer who wants to fork the repository, patch a rendering bug, and open a pull request against GitHub. The README states plainly that source code changes go to Gerrit, not GitHub, and points to CONTRIBUTING.md for the process. If your goal is to modify the editor itself, the repository you are looking at is the wrong entry point. If your goal is to run the thing, it is the right one, because the deployment artifacts are exactly what this repository owns.

How the deployment artifacts flow out of this repository

The mechanism is publication, not compilation. According to the README, three kinds of artifact are published from this GitHub repository: the nightly container image, the Helm chart, and build assets. The chart lives at kubernetes/helm/ in the tree, and the docker image build lives at docker/from-source-gh-action/. Releases follow the chart's own version line rather than the application's, which is visible in the release names: helm-collabora-online-1.3.2, then 1.3.3, then 1.3.4, the most recent dated 2026-09-22. A read-only mirror of the source code exists at CollaboraOnline/online.mirror, and its README is where the project directs readers for build instructions and project documentation. So the data flow for an operator is: pick a chart version from the releases, point it at an image, deploy to Kubernetes. The data flow for a developer is entirely different: read the mirror, push to Gerrit. Nothing in the repository layout suggests the two paths converge.

Installing Collabora Online from the Helm chart

The README does not print an install command. It states that the Helm chart is published from this repository and that it lives under kubernetes/helm/, so the chart is the supported path onto a cluster. A conventional Helm install against a chart directory checks out like this, and the values file is where you would set your image and ingress details:

git clone https://github.com/CollaboraOnline/online.git
cd online
helm install collabora-online ./kubernetes/helm

The README does not document the chart's required values, so treat the values file inside kubernetes/helm/ as the source of truth before you run anything against a real cluster. If you prefer the container route, the README says the nightly container image is published from this repository, and the build definition sits in docker/from-source-gh-action/. What you should see after a successful install is a running Collabora Online deployment reachable through whatever ingress your values configure. What the README does not give you is a default port, a default hostname, or a minimum chart version, so none of those should be assumed.

Where this repository stops being the right tool

The clearest failure mode is a contributor opening a pull request against application code. The README says such pull requests are welcome only for the Helm chart and the docker image build, so a patch to the editor will be redirected to Gerrit and the contributor's time is lost. A second limitation is documentation depth: the README covers what the repository is for, not how to configure the chart or what image tags exist, and it defers build instructions to the mirror repository's README. A third is that the release cadence you see here is the chart's, not the application's. If you need to know which Collabora Online version a given chart deploys, the release name helm-collabora-online-1.3.4 does not tell you, and the README does not map chart versions to application versions. Anyone who needs that mapping has to look outside this repository. Finally, the licence field on the repository is NOASSERTION, with a COPYING file at the top level; the README does not spell out licensing terms for the chart or the image, so a compliance review has to read COPYING directly.

Alternatives and how their approach differs

The obvious comparison is a self-hosted document server that ships its full source in the same repository as its deployment tooling, so a single clone gives you both the application and the chart. That model lets you patch the server and redeploy from one tree. CollaboraOnline/online deliberately does not work that way: the application source is reviewed on Gerrit, a read-only mirror exists at CollaboraOnline/online.mirror for reading, and this repository owns only the chart and the image build. The practical difference is where your change lands. In the single-repository model you commit and build. Here you either file an issue on GitHub or push a change to Gerrit, and if your change is to the chart or the image build, GitHub is the correct destination. A second alternative is running a hosted office suite and skipping self-hosting entirely, which removes the chart, the image and the cluster from the picture but also removes the control that makes the Helm chart worth using.

Maintenance, upgrade cost and licence handling

The repository is not archived, and the last push was on 2026-09-22, the same day as the helm-collabora-online-1.3.4 release. The three most recent releases span roughly three weeks: 1.3.2 on 2026-08-31, 1.3.3 on 2026-09-17, and 1.3.4 on 2026-09-22. That cadence means an operator pinning the chart should expect version bumps to review on a short cycle, and Helm's usual upgrade path applies: change the chart version, run helm upgrade, and check the values file for new keys, because the README does not promise backward compatibility between chart versions. The upgrade cost is mostly in the values file and the image tag, not in application code, since this repository does not hold application code. On licensing, the repository's licence field reads NOASSERTION and a COPYING file sits at the top level, so the terms are not stated in the README. Read COPYING before you redistribute the chart or the image; nothing here constitutes legal advice.

Editorial conclusion

Adopt the Helm chart or the container image if you want to run Collabora Online on Kubernetes and you accept that build assets are published from GitHub while the application source is reviewed on Gerrit. Do not clone this repository expecting a working build: the README states that source changes go to Gerrit, and the mirror repository is where build instructions live. Before deploying, verify the chart version you pin, whether the image you pull is the nightly build or a tagged release, and whether your bug belongs in the GitHub issue tracker or in Gerrit review.

Frequently asked questions

Official sources

1. CollaboraOnline/online on GitHub
2. Issues
3. Project website
4. README
5. Releases