Sizing, prerequisites and the difference between single-node and high-availability Kubernetes for a self-hosted collaboration suite.
Kubernetes is the default target for self-hosted software, and for good reasons: rolling upgrades, declarative configuration and a scheduler that survives a node failure. It also adds a layer between you and the application that has to be understood before an incident, not during one.
This covers what a collaboration suite actually needs from a cluster.
The most common mistake is designing for high availability before anyone uses the system. A single-node Kubernetes deployment is a legitimate production configuration for a team of a few hundred, and it defers the complexity until you have a reason.
Use it to:
Migrating from single-node to HA later is a configuration change plus a data migration, not a redesign, provided you keep the stateful components external from day one. Which is the next point.
This is the single most important architectural decision.
A collaboration suite has three kinds of state:
| State | Where it belongs | Why not in-cluster |
|---|---|---|
| Relational data | Managed MySQL 8, or a careful StatefulSet | Backups and failover are a solved problem elsewhere |
| Object storage | S3-compatible external service | Capacity grows without bound; object lifecycle matters |
| Session and coordination | Redis | Losing it should be survivable, not catastrophic |
Running MySQL inside the cluster is possible and occasionally correct, but it moves the hardest operational problem — point-in-time recovery for a stateful database — into a system that was not designed for it. If you already operate a managed database, use it. The self-hosted collaboration guide covers the backup implications.
Do keep the stateless application tier in the cluster. That is what Kubernetes is good at.
Before you run an installer, confirm:
Two of these are the usual schedule killers: an undecided domain name and object storage that has never been used by anything before.
Collaboration workloads are bursty and memory-sensitive rather than CPU-bound. The real-time coordination service holds connections open for every active editor, which makes memory the first constraint you hit.
Rough starting points for a mid-size deployment:
The high-availability Kubernetes guide is the first-party topology and verification reference once the measured workload justifies moving beyond a single node.
Measure before you scale. The vendor’s resource planning guide documents the baseline; your own numbers are the ones that matter.
Adding replicas helps for some failure modes and not others.
Improved by HA:
Not improved by HA:
It is worth being blunt about the first list: teams often build a three-node cluster and leave the database on a single instance with no failover. The cluster buys less availability than the database configuration costs.
Rolling upgrades are the payoff for running on Kubernetes, and they need two things to be safe.
A rollback plan that has been exercised. Not a documented one. A tested one, including how to revert a schema migration if the release included one.
A staged environment. Production should not be the first place a release runs. A staging namespace with the same manifests and a recent database copy catches most surprises.
Set an upgrade cadence and publish it. Predictability reduces user friction more than low frequency does, and security patches should not wait for a window that never arrives.
Beyond the generic node metrics, these are the signals that predict a collaboration outage:
The incident tooling in the repository’s troubleshooting documentation describes the signals the suite exposes.
If you are still deciding whether to self-host at all, start with what private cloud document collaboration is. If the driver is compliance rather than architecture, data sovereignty frames the argument.