Feature Request - Custom Domain for Staging Site

[HiltonGiesenow]

I've tried creating a cname, but it didn't work, not sure if I just messed something up, or if it's not supported. Aside from that, I think the title is quite self evident :-)

[miwebst]

This is not supported right now :)

[HiltonGiesenow]

That's why I've titled it "Feature Request" ...

[miwebst]

Understood. I was confirming your earlier comment: "not sure if I just messed something up, or if it's not supported"

[HiltonGiesenow]

ahh ok, my mistake - thanks for confirming. I was wondering if any of this would be open sourced at any point, in which case I'd be happy to work on a PR. Not the Azure portion itself necessarily, just the Github Action component I mean

[m-sterspace]

@HiltonGiesenow my workaround for this was just to create more Static Web App instances with the same github repo. We typically have 3 different hosting environments per app, production, staging, and develop, so I created 2 more Static Web Apps, but each one associated with a different branch of the same repo, so there's now have 3 different workflow files, one each for the master, develop, and staging branches:

[HiltonGiesenow]

that's a great idea, thanks. It might change when this goes g.a. and has pricing attached, but it'll certainly work for now

[m-sterspace]

In a related, but slightly different request, I would really like the ability to have dedicated/stable URLs for deployment slots. Being able to set them up with a custom domain and a cname record as well would be ideal, but I care less about that then just having a stable URL for a staging slot.

If you implement your own authentication for your application, either using the MSAL library or Auth0s or just rolling your own OAuth setup, you need to have a stable callback url for each of your sites that is registered with the authentication providers. At present you can't really easily set that up since staging slots always get a brand new random url.

[mwaddell]

This is really more of a DNS issue. In order to map your production slot to another url, you need to use a CNAME. There isn't any "dynamic" equivalent to a CNAME that would let you do pattern matching (e.g. map fuzzy-stone-*.azurestaticapps.net to staging-*.mycompany.net).

Besides, the whole benefit of SWA is that you get a separate phoenix environment for every PR. If you want to have a fixed location for your staging environment, then just use a separate branch. For example, instead of trying to do everything in your "main" branch, have a separate "prod" branch and using "main" as staging. Then you get a static URL for the staging branch, phoenix environments for every PR against staging, and a separate static URL for production -- that also gives you an additional audit step between staging and production which can have different sign off users in the branch protection rules.

If you want to have 3 separate statically named environments, then don't use PRs at all - just set up 3 branches and push everything to the one you want it to deploy to. This is how we manage things that don't support phoenix environments (like some legacy dotnet framework apps)

[m-sterspace]

This is really more of a DNS issue. In order to map your production slot to another url, you need to use a CNAME. There isn't any "dynamic" equivalent to a CNAME that would let you do pattern matching (e.g. map fuzzy-stone-*.azurestaticapps.net to staging-*.mycompany.net).

Besides, the whole benefit of SWA is that you get a separate phoenix environment for every PR. If you want to have a fixed location for your staging environment, then just use a separate branch. For example, instead of trying to do everything in your "main" branch, have a separate "prod" branch and using "main" as staging. Then you get a static URL for the staging branch, phoenix environments for every PR against staging, and a separate static URL for production -- that also gives you an additional audit step between staging and production which can have different sign off users in the branch protection rules.

If you want to have 3 separate statically named environments, then don't use PRs at all - just set up 3 branches and push everything to the one you want it to deploy to. This is how we manage things that don't support phoenix environments (like some legacy dotnet framework apps)

This is why I had asked for the option for static deployment slots as opposed to dynamic ones. Once this service exits preview I'd rather not have to pay for three instances of it just to have dev and staging deployment slots that will barely be used.

Dynamic deployment slots and URLs only work if your app either doesn't have authentication, or if you use the built in authentication. If your app is trying to be relatively platform neutral so that it could be easily deployed anywhere, and you're handling authentication yourself using something like the msal.js library, then a dynamic url is a non starter as every callback url has to be registered with your oAuth provider.

[mwaddell]

@miwebst - do you have any idea what the pricing will look like for SWA once it hits GA? Will there be a significant cost difference between having 4 different SWA instances where no staging slots are used vs having a single SWA instance with 3 staging slots?

Will the staging slots have to use the same pricing model as the production slot? If so, having 4 different instances might actually be cheaper if I can use consumption-based pricing on my 3 staging instances and only use a dedicated pool on my production one.

[mwaddell]

We've been using Auth0 with SWA and it supports wildcard callback URLs, so it hasn't been a problem for us. I don't know about other oAuth providers.

[m-sterspace]

We've been using Auth0 with SWA and it supports wildcard callback URLs, so it hasn't been a problem for us. I don't know about other oAuth providers.

It shouldn't support wildcard callback URLs, as that goes against the OAuth standards, all the callback URLs should be absolute:

https://docs.microsoft.com/en-us/azure/active-directory/develop/reply-url#restrictions-on-wildcards-in-redirect-uris
https://tools.ietf.org/html/rfc6749#section-3.1.2

[mwaddell]

We've been using Auth0 with SWA and it supports wildcard callback URLs, so it hasn't been a problem for us. I don't know about other oAuth providers.

It shouldn't support wildcard callback URLs, as that goes against the OAuth standards, all the callback URLs should be absolute:

https://docs.microsoft.com/en-us/azure/active-directory/develop/reply-url#restrictions-on-wildcards-in-redirect-uris
https://tools.ietf.org/html/rfc6749#section-3.1.2

True, and it is noted in auth0's documentation that this is only intended for dev/test environments, and should not be used on production. They also do put some restrictions on wildcards (e.g. no *.com, etc) but I do understand that this is non-standard and not likely to be supported on oAuth providers generally.

• https://auth0.com/docs/applications/wildcards-for-subdomains

I agree that the most flexible solution would be to modify the "Custom Domains" section of the SWA portal to list 1 production slot and N staging slots (depending on how many you've purchased - 1 for now). They could default to "random-words-hashcode-#.eastus.azurestaticapps.net" (where "#" gets replaced by the PR number) - but let users override those to something static.

However, this is basically the same as maintaining a separate branch for each staging "slot" and merging the PR branch you want to test into the "slot" branch you want to deploy it to for testing. This is possible to do with automatically with GHA instead of manually if you're creative (e.g. have a workflow that automatically merges that branch's changes into a specific slot's branch based on the label associated with the PR) but it's definitely less slick than having Azure manage that for you, and it's also unclear whether there will be any cost difference to having 2 production slots with no staging slots vs 1 of each.

[iomariani]

Any updates regarding this? Is it on any milestone?

Currently now there's a Standard plan with up to 5 custom domains, however staging sites still use Azure auto-generate one...
Even if we set our DNS CNAME as an alias do the Static Web App resource.

One workaround right now we could create a CNAME pointing to the custom azure-generated-name-1.domain.
However there's no way to change it when the bot comments on the PR, so it still comments it with the auto-generated one...

[m-sterspace]

The randomly generated URLs has become an even bigger non starter for us internally.

Our IT team has implemented DNS filtering that seems to filter out any relatively new URL that it doesn't recognize and hasn't been explicitly whitelisted. This makes the randomly generated URLs that are created for pull requests effectively unusable for us on our corporate machines.

[superhp]

Any progress or roadmap for implementing custom or predefined URL for stating environments?

[nitelite]

Any progress or roadmap for implementing custom or predefined URL for stating environments?

If you specify which branch is your production branch, you can get stable URLs for the rest of your branches at least.
Ref: https://azure.microsoft.com/en-us/updates/public-preview-stable-urls-for-preview-environments-in-azure-static-web-apps/

[superhp]

@nitelite thanks, that's great! I also saw that SWA phoenix environments are now deployed to a more stable URL: stableurl-pullrequestnumber.azurestaticapps.net (https://docs.microsoft.com/lt-lt/azure/static-web-apps/review-publish-pull-requests). So you can predict it now. For example, you can register a new redirect uri for Azure B2C programatically: az rest --method PATCH --uri 'https://graph.microsoft.com/v1.0/applications/' --headers 'Content-Type=application/json' --body '{"spa":{"redirectUris":["https://myurl-pullrequestid.azurestaticwebapps.net"]}}'.
We also tried to hide this URL under proxy (Azure Functions v3 Proxy) by using such rule:
"rule name": {
"matchCondition": {
"route": "/123/{*all}"
},
"backendUri": "https://staticwebappurl-123.westeurope.azurestaticapps.net/{all}"
}
So then we can use a custom domain like this: https://mycustomurl.com/{pullrequestid}/ and it works except the SWA built in authentication. When you authenticate, you are redirected back tohttps://staticwebappurl-123.westeurope.azurestaticapps.net/ instead of https://mycustomurl.com/123/. Do you have any ideas how this could be fixed?

[Reshmi-Sriram]

Apologies, we missed on updating this issue thread!
Static Web Apps announced support for Named Preview Environments in May 2022. This enables one to add a custom prefix to the default generated URL, thus eliminating the need to have multiple Custom Domains for different environments.

Do let us know if this helps solve your problems! :)

[roblambertini]

This is not supported right now :)

As for the original question: are there any plan to support this scenario without creating multiple swa instances (one for each environment)?

[johnkors]

We wanted to get to the following URLs:

• preview-pull1337.domain.com (CNAME linked to PR deploy)
• test.domain.com (fixed test env)
• www.domain.com (fixed prod env)

To achieve this, we ended up skipping the "preview" features (it does not support custom domains) and use Pulumi to provision new SWA for each pull request instead.

IF SWA preview and named environments had supported custom domains and finer control over the generated names, we could probably have solved it with SWA preview environments. Atm this is not possible.

[ulfbrehmer]

We also wanted do have custom domains ready for different environments, e.g.:

• dev.domain.com
• demo.domain.com
• customerspecific.domain.com
• prod.domain.com
  Apart from the prod environment, all others would be fixed subdomains for dev/test or for feature testing, using the same GH repo but different branches (not necessarily named same as the hostnames).
  Unfortunately, Azure SWA does not support custom domains for staging environments, so users are stuck with those long auto-generated ones. It would be much neater if we could have this.

[JackWillDavis]

Adding another vote for this as it would be really useful. We're planning on providing access to a staging environment for a group of internal beta testers so allowing custom domain mapping to them would be really helpful.

The alternative is having multiple SWAs for each branch as suggested above.

[thomasgauvin]

Thanks everyone for the feedback, I'm writing here to let you know we are tracking this internally and are considering prioritizing this for future plannings. I currently see 22 👍, so it seems like a feature many would benefit from!

[fede]

+1
we are trying to have a standard for staging url convention to increase visibility within a big organization and this is definitely making it harder apart from other aspects that have been covered in this thread.

[amrtappin]

+1
We use subdomains to map to customer instances: xxxx.website.com maps to customer xxxx. currently we can only test on the production slot only

[cr3wdayt5p]

@thomasgauvin What is the status on this essential feature?

With browsers now blocking 3rd party cookies by default this is even more critical for smooth testing of SWAs.

[dlebee]

@thomasgauvin we use this feature internally its cool.

What we'd like to be able to do potentially.

is to use abc.com for the production environment

and for preview ones we can do a CNAME *.preview.abc.com -> DNS of the static app

This way we don't need to automate any zone creations.

We've figured out oauth2 automation with the non custom domain so we could totally automate the routing rules for preview websites to be secured.

Only thing missing is the ability to say use pr-number.preview.abc.com at the deploy section and re-use the domain verification of *.preview.abc.com instead of adding a verification per environment.

[semics-tech]

@thomasgauvin Are there any updates on this? It is very limiting how it currently works where you can only have a custom domain on the production environment.