Custom domain for SCM site

1 minute read • By Mads Damgård • March 3, 2021

When enabling private endpoint for a web app, both the web app and the Source Control Manager (SCM) site, also sometimes referred to as kudu, are locked down to only receive traffic from the private IP. If you are in the internal network and have setup proper private DNS resolution, you can access both sites by browsing to https://appname[.scm]

Externally public DNS for appname[.scm] will still resolve and route you to the public endpoint in which case you will be met with the blue Forbidden page. To route external traffic to the site or if you prefer to use a custom domain internally, you can setup a reverse proxy like Azure Application Gateway. In a reverse proxy you can override the custom domain with an internal hostname like appname[.scm] All of this has been possible for a while and you can use the SCM APIs by providing the deployment credentials in the request, but what has not been possible is to access the SCM site in the browser and using all the tools available here.

Previously when setting this up and browsing to https://[]/basicauth the browser would challenge you for your deployment credentials, but after validating your credentials, it would redirect you to, which would be blocked. What you can now do, is to use https://[]/basicauthviaproxy. When accessing this link, the backend will look for the originating address in X-Forwarded-Host or X-Original-Host and redirect you to the appropriate address upon successful login.

A few notes:

  • It only works with deployment credentials. SSO is not possible
  • SCM site does not have an unauthenticated health endpoint, so health probes should either be disabled or accept 401 and 403
  • Some response payloads from the SCM APIs contain absolute references defaulting to the incoming host ( To override this and honor the originating address, configure the following App Setting on the web app: SCM_USE_ORIGINALHOST_FOR_REFERENCE = 1