How We Built Enterprise Multi-Tenancy on Laravel 12

Multi-tenancy is one of the hardest architectural decisions in SaaS. Get it wrong and you'll spend years untangling data leaks and performance issues. Here's how we approached it at CoreAxis.

We chose a schema-per-tenant model over shared tables with tenant_id columns. Each business gets an isolated MySQL schema, a separate Redis namespace, and dedicated file storage paths.

Tenant resolution happens at the middleware layer, before any controller logic runs. We resolve the tenant from the subdomain, a custom domain DNS record, or a bearer token claim — all three are supported simultaneously.

The biggest challenge was making this transparent to the rest of the application. We extended Laravel's database manager to automatically prefix every query with the tenant's schema name. Developers write normal Eloquent models — the tenancy layer handles the rest.

For performance, we cache tenant config and permissions in Redis with a short TTL. Cold tenant lookups (first request after cache miss) add ~3ms of overhead — acceptable for an enterprise product.

Branch management was an interesting extension of this. Branches are sub-tenants that inherit their parent's config but can override specific settings (like pricing rules or tax rates for a different state).

We're planning to open-source the tenancy package as a standalone Laravel library later this year. Watch this space.