Multi-tenant SaaS
A multi-tenant product demands two things that pull against each other: tenants must be isolated, and cost per tenant must fall as you grow. Managed Kubernetes gives per-tenant namespaces and quotas over one shared node pool, with rolling upgrades so a release never becomes a maintenance window.
A Real Story
How this runs in production
Kelola HR serves 340 companies from one codebase. The largest tenants demand data isolation they can evidence in an audit; the smallest pays Rp900k a month and cannot carry its own infrastructure cost.
The answer was not a cluster per customer. One Kubernetes cluster holds all of them with per-tenant namespaces, quotas and RBAC — while the three largest get a separate database, because their contracts genuinely require it.
- tenants on one cluster
- 340
- downtime during upgrades
- 0 mnt
- cost per tenant/mo
- Rp61rb
We used to think isolation meant a cluster per customer. What we actually needed was namespaces and quotas that are genuinely enforced.
Reference Architecture
Exactly what they run
The plan names below are the same ones listed on the pricing page.
- Kubernetes Cluster3 pool · 6–24 nodeAutoscaling, rolling upgrades with no maintenance window.
- Managed Databaseg2.2xlarge × 4Three large tenants isolated, the rest shared.
- Load BalancerIngress L7Host-based routing, one certificate per tenant domain.
What You Get
Built for this workload
Per-tenant isolation
Namespaces, quotas, and granular RBAC on one cluster.
Node autoscaling
Capacity follows load, not last month’s forecast.
Zero-downtime upgrades
Roll Kubernetes forward without a maintenance window.
Built From