What will be the right way to do multi-tenancy SaaS with single domain(single endpoint to login) and multi-database with Laravel+Jetstream? [closed]

All the available Laravel packages for multi-tenancy mostly depend on domain/path/request_header-based identification. The type of multitenancy use case that I’m trying to find seems to be very hard to find.

I have checked package “stancl/tenancy” and “spatie/laravel-multitenancy:^1.0” they provide tenant identification based on domain but also supports custom middleware for tenant identification. But I am not sure if the way I am trying to implement the identification will be the right way to do it.

It’s quite simple though if you look at something like Xero. When you sign up for Xero, you are another tenant on their system. You don’t get a domain name or the ability to have a vanity domain name. Yet I can’t imagine they scope each database record. Surely they have a database per client?

Anyway, it seems most of the tenancy packages you either need a domain name/path, or you need to scope. I’m trying to understand how to do multi-tenancy with separate databases but no custom domain/path.

The Laravel app I am trying to develop will have many, many transactional types of data. It is kind of a business accounting solution and for that reason I want the data to be separated from each other for efficiency and security.

I need a single domain/endpoint solution because:

  1. Users might forget what they have selected as their sub-domain in a multi-domain setup.
  2. I can’t have a simple and single login button on my homepage that will lead users to their login page, as each login page will be different for different tenants.
  3. Mobile app will need to connect to different APIs for different tenants.
  4. One user may have access to multiple businesses meaning multiple tenants and need to switch businesses easily.

I need a multi-database solution due to:

  1. The data I am going to store for each business is very sensitive as they are business financial information so need to be siloed.
  2. There will be a lot, I mean a lot of data that we will need to store, so separating by database, I think will be efficient.

Considering my scenario, I think a single domain with a multi-database setup is suitable (Please let me know if I am wrong with my reasons).

I am thinking about making the identification based on users.

But this introduces new sets of problems:

  1. I can no longer put users on their tenant databases. I need to take them out of the database and put them in the central database.
  2. How can I make the relationship between users and data living on the tenant database (for example which user made the transaction)? Even if I can, will it be a feasible solution?

Could anyone please guide me in the best direction? Does anyone know or have any better idea on how that can be done?

Leave a Comment