Subdomain and custom domain based multi tenant application


We are building a solution similar to Shopify. Where the customer can create a store using our product (assume Once the store is created, the customer can access their store with the URL (every store will have a unique URL). Also, customer can, link their custom domain to their store ( => Our frontend stack is build using NextJS.

Now, these are the questions I’m looking for an answer to:

  • Can this be achieved using Netlify? If yes, how?
  • Can we automate all these things at scale with an SSL certificate for both subdomain and custom domain?

You’d need a wildcard subdomain ssl which can be added by Netlify staff if you are a pro* member (Might require business?).

I believe for your sub-domains they would be different branches, and for the redirects, maybe you’d setup a URL rewrite so that your subdomain rewrites to their domain? They’d probably need to do some manual changes on their own domain though. To add redirects etc I think you’d need to trigger a Netlify build but that shouldn’t be too hard to get going. :slight_smile:

I’ll tag @jen for more information / clarification, who may also be able to help you with wildcard subdomains if you’re on the correct tier as a customer.

1 Like

Many thanks for the tag @AaronP!

@vishalvijay, here’s our spiel about wildcard subdomains, which is how we support use cases like yours:

Your SSL question is addressed in there :slight_smile: Wanna have a read through and let us know if you have followup questions?

Thanks, @AaronP, and @jen for your valuable input.

I got a clear idea about how to go about subdomain. We’ll be using a custom wildcard SSL certificate as our DNS is managed elsewhere.

But I still didn’t get a clear answer for custom domain support. The facts I know:

  • If wildcard support enabled, we can’t add any other domain alias to that site (To solve this problem, we are okay to have one more site for custom domain)
  • Only up to 50 custom domains are allowed on a site.

Based on the above facts let me frame my question this way.

We don’t want to deploy an individual site for each of our customers to support custom domains. We are okay to have a site for handling subdomain and another for a custom domain. So the problem comes down to Netlfify support only 50 domain alias, is it a hard limit? Can you guys change the limit if we are ready to pay?

Makes sense - we aren’t trying to suggest you create a site per customer, although some other customers of ours do that as it better accommodates their use case.

You may be able to add up to 90 custom domains per site (that is the HARD limit which is not changeable) but I have to warn you this pattern will have some caveats which I discuss below. You can configure names via API to automate your usage, and you will have to “shard” your sites for names beyond the 90th.

The main caveats (besides needing to pay to resell our service) are really around SSL. We only serve SSL content, so any hostname we host must be covered by an SSL certificate. We can absolutely provision certificates for dozens of distinct names (and this is why we have a limit on # of sitenames since our SSL provider can only add a limited number to a certificate), but they ALL have to be configured right for this to work.

Using customer-provided domains where they control DNS will be a lot of troubleshooting overhead - for you, not us - since you’ll provide tech support to your customers on configuring DNS. We have a couple folks who use this pattern today, and I have helped them help many of their customers get things configured more correctly to allow SSL to provision. They have finally learned all the gotchas, but it was a lot of work for them and not a great customer experience for a lot of their customers. TL;DR it is hard to get right, and it will be a fair amount of work for you to provide tech support to them.

Thanks, @fool for the input.

Let me try to summarise what you said.

We can achieve the custom domain feature at scale only with sharding of 50 (or 90 MAX) domains per site. But it comes with a couple of challenges.

  1. There is a lot of DevOps automation required from our end for this to work correctly.
  2. We’ll have provided support to our customer for configuring their DNS (Which we anyway have to do)
  3. Plus - For deploying code changes to many sites at the same time requires an optimized CI/CD pipeline.

Please correct me if I’m wrong.

I wouldn’t say #1 is true. it’s not much harder to create 50 sites via the API than one. I don’t recommend updating many sites with new names; I recommend updating site 1 with names 1-50, then moving on to site 2, etc. You just need to know the last site, and write one extra code stanza to check number of names and if it’s too high, create a new site instead.

  1. yup, that’ll be the worst of it.

  2. you could deploy your code without building here and there would be no CI delays. I don’t know your codebase, but as I mentioned if it is truly shared across all customers, you shouldn’t need to rebuild EVERY site unless you make a change that impacts all.

Got it. Thanks @fool

Hopefully this will make you smile ha ha. I stumbled upon this a year and a half later and it’s exactly what I needed to know :smile: On serious note if anything has changed pls ping back. Thanks again!