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

All the available Laravel packages for multi-tenancy mostly depends 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.

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:

Users might forget what they have selected as their sub-domain in a multi-domain setup.
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.
Mobile app will need to connect to different APIs for different tenants.
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:

The data I am going to store for each business is very sensitive as they are business financial information so need to be siloed.
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:

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.
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?

wilsenhc

2 years ago

Level 2

The package stancl/tenancy has many different ways to identify tenants, including all the options you mentioned.

The package also lets you implement your own Tenant Identification driver and it also has manual tenancy initialization that you can implement yourself.

These two things are independent of the single-db or multi-db setup you choose too!

I think this should be a good way for you to go with. It will be a little more work than you would expect (having to write your own Tenant Identification Driver) but the good thing is you can fully customize it however you want

Ben Taylor

2 years ago

Level 35

I once had to port a legacy app to Laravel. This app had 2 databases based on country. The country was included in the url structure (something.com/{country}/something). I could use the country part of the url in a middleware to determine the right database connection. Maybe you could do something similar?

fludems2

2 years ago

Level 2

I'm pretty new to laravel and have been building a multi-tenant app using tenancyforlaravel for the past 6 months.

You could in tenancyforlaravel have a user model that is a standard user model.

You then could have a model in your central application for storing auth details for the users, but just the identifiers they might provide you with such as a username or an email and a column for the tenant ID.

Laravel models have events: https://laravel.com/docs/10.x/eloquent#events

I'd just make sure you have code for a user being created, updated, deleted etc and update the central model so the central DB is aware of what login belongs to who.

You could store users in the DB entirely, but I think it's just creating complexity at that point having part of the app consistently outside of tenant context.

EDIT: Just re-read your post, you probably need this central DB Table to have a one-to-many relationship with tenants so that they can switch between tenants.

But then you have the problem of having to get the credentials in every tenant DB they have access to.

At that point you might wanna use resource syncing, and the documentation on tenancyforlarvel covers your situation you're explaining pretty much: https://tenancyforlaravel.com/docs/v3/synced-resources-between-tenants/

Please or to participate in this conversation.