Designing Scalable Laravel SaaS Architecture
Most Laravel SaaS products start as a single-tenant app with a tenants table added later. That works until jobs, caches and files leak across customers. Isolation has to be a product decision, not a middleware afterthought.
Isolation is the product
I treat tenancy as a hard boundary: data, queues, object storage and config. A tenant_id column is not enough if a queued job can still see the wrong rows, or if a cached report mixes two companies.
On platforms like BROC ServiceOS, the first question is not “which package”. It is: what happens when tenant A’s invoice job runs while tenant B is being restored from backup. If you cannot answer that, you do not have a SaaS yet.
Queues, cache and files
Horizon, Redis and S3 are not decorations. Every job carries the tenant. Every cache key is namespaced. Every upload path is owned. That is boring, and it is why the second customer does not take the first one down.
If you skip this, you will debug “random” data in production. It is never random. It is a missing boundary.
Billing next to the tenant
Plans should map to limits the product actually enforces: seats, locations, API volume — not a PDF of features. Billing belongs next to the tenant record, not scattered inside every module.
From Tangier I ship Laravel SaaS this way because rewrites after the second customer are more expensive than a clear isolation model on day one.
Key takeaways
- Decide tenant isolation before you pick packages.
- Jobs, cache and files must carry the tenant.
- Bill for limits you actually enforce.
FAQ
Should I use a multi-tenant package from day one?
Use a package only after you can describe isolation in your own words: database, queues, files. A package does not invent a boundary you have not designed.
Single database or database per tenant?
Start with one database and strict tenant scoping if you are early. Split later when compliance, restore, or noisy neighbours force it — not because a blog post said so.