Platform
Multi-tenant PaaS
One codebase, many tenants — each with its own database, its own network and its own backups.
| Kind | Platform |
|---|---|
| Start | |
| Ended | |
| Technology | .NET, NestJS, PostgreSQL, Kubernetes, Terraform, ArgoCD, Traefik, Prometheus |
| In service | 16monthsended |
In detail
Most tenancy models economise exactly where it later gets expensive: a shared schema, a tenant column, and isolation that depends on every single query filtering by tenant correctly. One forgotten filter is enough for one customer to see another customer’s data.
Here each tenant got its own database, its own connection pool, its own backups to two separate locations, and a network rule preventing access between tenants. Isolation therefore sat in the infrastructure, where a coding mistake could not undo it.
A service set up new tenants: it generated the full environment, rolled it out, and shut unused ones down again. Everything underneath — cluster, database, registry, DNS — came entirely from Terraform.
The project was ended, and the platform with it. Until then it ran in production with real tenants.
The log for this system.
- Operations
Moved tenant separation into the infrastructure: a namespace, a database and a network rule of its own for every tenant.
- Operations
Automated hibernation for idle tenants: shutting them down and starting them again on demand.
- Build
Moved every tenant onto one Kustomize base with per-tenant overlays, so a release ran the same way everywhere.
- Operations
Provisioned the cluster, managed database, container registry and DNS entirely through Terraform.
- Build
Started the multi-tenant platform: API gateway and the first backend services.
Next step
We will tell you up front where the time will go.
Describe your plan in a few sentences. We will name the two or three places where a system of this kind turns expensive.