KamoCRM does not run on someone else's platform-as-a-service. It runs on an RKE2 Kubernetes cluster we build, operate and are woken up by — with our own storage, ingress, certificate automation, virtualisation and image registry. Everything we know about shipping software that stays up, we learned here, at our own expense.
| Measure | Value | Source | Measured |
|---|---|---|---|
| Deployments in the cluster | 106 | kubectl get deploy --all-namespaces | |
| Running pods | 267 | kubectl get pods --all-namespaces | |
| Stateful workloads | 22 | kubectl get statefulsets --all-namespaces | |
| Namespaces | 19 | kubectl get namespaces | |
| TLS certificates under automated management | 211 | kubectl get certificate --all-namespaces (cert-manager) | |
| Ingress routes | 40 | kubectl get ingressroute --all-namespaces (Traefik) | |
| Control-plane node uptime | 266 days | kubectl get nodes -o wide, AGE column | |
| Kubernetes version | v1.35.6+rke2r1 | kubectl get nodes -o wide, VERSION column |
What building it taught us
It would have been easier to rent. Managed Kubernetes exists, it is good, and choosing it would have removed an entire category of problem from our lives. We run our own because the platform carries things a managed offering will not host for you at a sensible price — telephony that needs real network control, WebRTC media that needs predictable UDP paths, inference that needs hardware — and because a company selling infrastructure competence should be able to demonstrate it rather than describe it.
The cluster carries Longhorn for replicated block storage, Traefik for ingress, cert-manager issuing certificates per hostname, KubeVirt for the workloads that genuinely need a virtual machine, and a private registry. Certificates alone are a good illustration of why operating teaches things reading does not: they are issued per fully-qualified name and serially, so a tenant that adds a hostname and does not wait sees a self-signed certificate on exactly one host and concludes the whole system is broken. You do not learn that from documentation. You learn it from a support ticket.
The failures have been instructive in the way only your own failures are. A schema migration that made every service return errors for a quarter of an hour because connection pools were holding an older catalogue version. A node whose second network interface corrupted large transfers intermittently, which looked like a software bug for a long time. Memory limits that were fine until a garbage collector disagreed. Every one of those is now something we design against on client work, because we paid for the lesson already.
This is the difference we are actually selling. A development firm that has never operated what it built will hand you a repository and an invoice, and the first production incident will be yours alone. We write runbooks because we have needed them at two in the morning.
Built with
- Kubernetes (RKE2)
- Traefik
- cert-manager
- Longhorn
- KubeVirt
- containerd
- Docker registry
- Ubuntu
What this qualifies us for
Tell us what you are trying to do
A short conversation is usually enough to tell whether we are the right people. If we are not, we will say so and point you somewhere better.