DEV Community


Discussion on: Which cloud provider should I use to build Multi-tenant SAAS?

simoami profile image
Simo Moujami

Hi @simo97 ,
Thanks for the article. I wanted to touch base on the tenant detection approach. I did consider the subdomain approach but I got burned in the past for embracing it. The issue with it is that you need wildcard certificates to support a secure * and those don't come cheap. Also, we're deploying to Google Cloud and they don't support wildcard certificates as managed certificates, which means we have to manually update them every year. Finally supporting subdomains requires running scripts that modify the dns records which is cloud platform specific. For example the way to do it with Route53 (AWS) is different from Google or Godaddy.

Additionally we have a requirement to support accounts that can manage other accounts. For example, Deloitte might be managing several clients and when they log in, they could manage any specific client. So there must either be some kind of selection post login or a way to differentiate the emails or usernames. To recap, here's the few options I had considered:

  1. subdomains, like * I already mentioned the disadvantages of this options.
  2. Using account-level email addresses as shown in the model above, your account email is The app sees that your email is specific to client1 *** and identifies the account. But it means an account email has to be setup for you each time you need access to an account. perhaps it also means you couldn’t set up an account on behalf of a client since you need an email set up with them first.

  3. during the login process, we ask you to first enter the organization name so we can identify which org you want to logon to, then we request your email address in step 2. the issue here is if you mistyped the org name, like Pandora vs Pandora inc, vs Pandora, inc, not sure how we can correctly map it to the correct tenant

  4. Let the user log in with the email set in the users table. If they have membership with more than one account, prompt them to select the account they wish to access. So now this single email approach raises a question. How do you sign up multiple times using the same email address so you can sign up multiple clients.

simo97 profile image

Hi @simoami

Thank for sharing your process, it looks interesting but i think a lot of points really depends on what you're building.

1. For sub-domains

It's more likely to be useful for users's confidence that their data are not merged with others client's data (peoples thinks like that sometimes, when a SaaS is designed like that, maybe weird but it is what it is). And from what i tried in the past, i discoverd that you can define a CNAME with * as value and target your server with it then you web server (NGINX, or any proxy) will be in charge of indentifying the request informations and will handle the certificate (with server block in nginx you can load differents SSL certificated depending on the domain server_name directive ) and everything accordingly. Please check this out :

2-3. User identification

The way to design this really depends on what your system does and how it does it. It can be difficult to do if your users can be shared across multiple organizations, in that case you may need to store some user's meta data (about what organizations they are into actually for example) and either propose them to choose one when login in or redirecting them into a "default" organization and they can change it later or something (king of how AWS manage everything with Regions).

In other design if your users a totally separated per organizationa and there is no reason for a user to have the same account with multiples organization it become simplier... you just need to store the org ID in the User informations (table, or whatever you use to store them).

  1. When you say "single email approach", i think visitors can create accounts on your system with their proper email (@gmail, @outlook, etc) but you will certainly have to restrict someone to create multiple account with the same email. But it really depends on your system. May be setting up a king of external auth system is a good and simplier solution for you (OAuth, or something). But i think you may have to make a difference between organization's owners and organization's members in someway.

Sorry for responding with so much delay... i totally missed the notification. I help this will be helpful in some way.

Just ping me a message if you want more discussions on this topic.