Adding more than five custom domains to a premium static web app

[green-munkey]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Is there a way/ or would there be a way in the future, to add more than five custom domains to a premium static web app?

Describe the solution you'd like A clear and concise description of what you want to happen.

We are coming from Heroku, where we don't have a hard limit on custom domains. Therefore, we want to continue offering custom URLs to all of our tenants, which is well over the 5-limit that static web apps currently allow.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

The only alternative that I have found is to configure Azure front door in front of Azure's static web app. I have not implemented this yet, but there is documentation on this topic.

Additional context Add any other context or screenshots about the feature request here.

[rupareddy5-21]

Hi, increasing the limit on no. of custom domains is not something we have on our roadmap at the moment. Sorry for the inconvenience.

[patrik-simunic-cz]

@rupareddy5-21 @annikel Well, this is not exactly an „inconvenience“ or „enhancement“, as it is a total no-go (for us). We as well need to host a multi-tenant application, which by definition requires an unlimited number of custom domains. There is the theoretical "workaround" with Front Door, however as our application relies on the Host header, it's an open question whether this solution is technically doable. (I will return here later and post about the results of my PoC test.)

If it would be not possible, then as I said, this would be a total no-go. We would have to move our entire infrastructure (APIs, CDNs, storage containers, queues, databases etc.) away from Azure, as it makes no sense to host parts of infrastructure with different provides - especially the database, where physical (and virtual) closeness to the web app matters because of latency.

Vercel provides unlimited number of domain aliases, AWS Amplify also provides unlimited number of custom domain names (yes, there is a 5-domain limit, but you can request increase of this limit with AWS support). So as I said, this hard limit makes SWA nothing less than no-go for any multi-tenant application (and as these kinds of applications usually carry a lot more infrastructure, a no-go for the entire application ecosystem as well). You really might want to consider "putting it on the roadmap" - even just adding the possibility of increasing the limit after a request might be enough.

[patrik-simunic-cz]

@rupareddy5-21 @annikel Alright, so I've just tested the so called "workaround" with Front Door in front of the SWA and I'm sorry to say, we'll have no choice than to migrate out of Azure. Putting Front Door in front of SWA means that we can point as many domains to the SWA, however in doing so, we loose the information about the original domain requested and therefore cannot render the appropriate tenant. None of the HTTP headers (host, referer, disguised-host, x-ms-original-url etc.) that propagate to the SWA indicate for what domain was the request originally made.

Basically, the "trivial" issue that SWA can have only 5 associated custom domains means that the entire Azure ecosystem as a whole is unusable for our needs of hosting our system, where the multi-tenant application is just one piece. As there's no way around this, this is not an „inconvenience“, but outright blocker.

[ltond]

This very restrictive limit of 5 domains has prevented us from using Static Web Apps also. It would be good to know why such a low threshold is hard-coded here, whereas an App Service can have up to 500 domains.

[thomasgauvin]

Hi folks, we're looking into providing this, how many custom domains do you usually need for your Static Web Apps?

[ltond]

We needed upwards of 300. We've switched to a different solution using an App Service now.

[thomasgauvin]

Ok thanks @ltond, I'd love to better understand your use case for this and see if there's any workaround to be explored, or if there's anything we can build to better support these 'multi-tenant' applications

Would you be available for a 20 min chat? My email is my full name in lowercase at microsoft

[noynek]

Just ran into this issue as well and wondering what options we have. @thomasgauvin did you come up with any solution? Is it possible to manage custom domains elsewhere and just point the DNS entries to the static app?

[vicpada]

Subscribing to this. We have the same issue. We need to support more much than 5 domains.

[noynek]

What worked for me was I set up a Front Door which pointed to my static web app. The Front Door allowed me to have more domains. A little more setup work involved, but it unblocked my issue.

[vicpada]

Thanks for the tip @noynek. I consider this already, but want to avoid the extra setup, and having to handle caches for deployments etc. I think using SWA is to automate and simplify setup and deployment. Adding this extra bit mostly defeats the use of SWA. IMO you're better off using AFD+Blob or CDN+Blob rather than SWA if going that route (unless I miss some other advantage).

[noynek]

You might be right. I'm definitely not clear on the tradeoffs of the different azure options. SWA with a function app seemed like the easiest way to set things up until we ran into the domain issue. The easiest switch to allow more domains while still keeping our setup, was to add a Front Door. It wasn't intuitive, but once it was up I haven't had any major complaints. Would love to know if there's a better way.

[pettys]

Subscribing because same problem here with a multi-tenant app. @thomasgauvin, when you ask "how many domains" the answer is, "How many customers do we hope to have someday?" 100's, hopefully 1000's. Not sure why you need a limit, but if practically speaking you do need one, AWS's model of a soft limit that can be raised with a support request would be an ok thing (per @patrik-simunic-cz comment).

[thomasgauvin]

Hi all, for that amount of custom domains (+100s), we recommend using App Service/Web Apps or another service. At this time, this is beyond what our infrastructure can host, though we continue to look into ways to improve and/or increase certain quotas.

Alternatives with SWA include setting up an AFD (as mentioned above) or having multiple SWAs (may not be practical with 100s of domains)

[pettys]

@thomasgauvin sorry to hear that. It would have been nice to leverage a platform optimized around static content delivery for our multi-tenant web app.

[planetdaz]

I'm also disappointed to learn that supporting a multi-tenant app with a subdomain schema is precluding us from using SWA as the delivery method for our UI, due to the domain limit. I am currently experimenting with AFD+SWA and while that works, it adds a lot of complexity to tenant onboarding, management and deployment.

With onboarding, we need our app to provision the subdomain and certificate when a new tenant signs up without human intervention.

With deployment, we need to purge AFD caches, or the app fails to load properly on the client.

And with management, it's just cumbersome as hell to wade through the complexity of AFD routes and origins, makes me dizzy.

Multi-tenancy SaaS is not an edge case, it's very common. Surely there must be turnkey solutions to this pile of seemingly straight forward issues?