Agencies accumulate installations. Twenty clients on WordPress means twenty cores to patch, twenty plugin sets that drift apart, and twenty chances for the one you forgot to become the one that gets compromised.
What tenant isolation actually means
A multi-tenant platform inverts this. One deployment serves many sites, but each site — each tenant — keeps its own database, its own content, its own theme and its own set of enabled modules. Upgrading the platform upgrades everyone. A tenant that wants an unusual feature enables a module rather than forking a codebase.
Where it gets hard
Isolation is the whole value, so anything that leaks across tenants is a serious bug rather than a cosmetic one. Three things need care:
- Data access. Every query must be scoped to the current tenant. This should be enforced by the framework, not remembered by each developer.
- Caching. A cache key without a tenant component will eventually serve one client's content to another. Assume it will.
- Background jobs. A queued job runs outside the request that created it, so it has to carry its tenant context explicitly.
Provisioning is a product feature
The interesting part is not hosting many tenants — it is creating one quickly. If spinning up a site needs an engineer, the model has not paid off. Provisioning should be a form: name the site, pick a theme, and get something that works immediately.
Should you build one?
If you run a handful of sites that differ wildly, separate installations are simpler and you should keep them. Multi-tenancy earns its complexity when your sites are variations on a theme and the count keeps climbing.
