The SCM site is the special App Service endpoint used by deployment and Kudu tooling. For many web apps it appears as a separate scm.azurewebsites.net address beside the public app address. It is where zip deployments, advanced tools, log access, debug console features, and some deployment APIs operate. The SCM site is not the customer-facing website, but it can change files, reveal runtime details, and affect deployments, so it deserves the same operational respect as the app itself.
Kudu site, Advanced Tools site, App Service SCM endpoint, scm.azurewebsites.net, deployment endpoint
Difficulty
intermediate
CLI mappings
6
Last verified
2026-05-23
Microsoft Learn
Microsoft Learn describes Kudu as the App Service engine behind source-control-based deployment and several deployment methods. The App Service SCM site exposes Kudu tools and APIs, commonly through the app's scm endpoint, for deployment, diagnostics, and advanced troubleshooting. securely.
In Azure architecture, the SCM site belongs to the App Service platform for Web Apps and many Function Apps. It is tied to the app resource, deployment credentials, access restrictions, private endpoints, DNS, slots, and Kudu APIs. Deployment pipelines, portal Advanced Tools, zip deploy, log streaming, and diagnostic workflows may reach the SCM endpoint even when the main app endpoint behaves correctly. In private endpoint designs, the scm hostname often needs its own DNS resolution path, and access restrictions can differ from the production app endpoint.
Why it matters
SCM site matters because deployment and troubleshooting often fail at this endpoint, not at the main website. A web app can serve users while the deployment pipeline receives 403, 404, or DNS errors against the scm hostname. If teams ignore the SCM site, private endpoints, access restrictions, disabled publishing credentials, or IP rules can block releases at the worst moment. The endpoint also exposes powerful Kudu capabilities, so weak controls become a security issue. Good operators know whether deployment uses Kudu, how the scm hostname resolves, who can access it, and how to prove restrictions before production releases. under pressure.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the App Service Advanced Tools blade, the Go link opens the app-specific SCM or Kudu site for deployment diagnostics and support investigations after releases.
Signal 02
In deployment pipeline logs, zip deploy or source-control deployment failures often reference the scm.azurewebsites.net hostname rather than the public site endpoint during releases.
Signal 03
In private endpoint DNS records, teams must resolve both the app hostname and the scm hostname to the private endpoint path for deployment traffic reliably.
Signal 04
In access restriction settings, SCM-specific rules can allow or block deployment clients independently from the main application endpoint during secure release reviews and audits too.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Troubleshoot a pipeline that cannot zip deploy because the scm endpoint is blocked while the public app still responds.
Design private App Service access by adding DNS coverage for both the app hostname and the Kudu or SCM hostname.
Restrict deployment tooling to approved build agents without accidentally opening Kudu to the internet.
Use Kudu diagnostics to inspect deployment logs, process state, or files during a production incident.
Validate slot-specific deployment behavior before swapping traffic to a newly deployed App Service slot.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Media subscription app fixes private deployment DNS before launch night
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A media subscription app moved App Service behind a private endpoint before a major sports launch. The public site tested well, but the release pipeline could not reach Kudu for zip deploy.
🎯Business/Technical Objectives
Restore deployment access without reopening the app to the internet.
Prove private DNS worked for both app and scm hostnames.
Keep launch-night rollback available from the build network.
Document the release path for future private endpoint apps.
✅Solution Using SCM site
The platform team discovered that the private DNS zone contained the app hostname but not the SCM hostname needed by Kudu. They added DNS coverage for the scm endpoint, validated resolution from the self-hosted build agents, and reviewed access restrictions so only the build subnet and operations VPN could reach deployment tooling. Azure CLI captured the web app configuration, access restriction settings, and deployment attempt output before and after the fix. The team also added a preflight pipeline step that resolved both hostnames and performed a read-only Kudu health check before any artifact upload.
📈Results & Business Impact
Pipeline deployment success returned to 99.6 percent across launch-week releases.
Emergency rollback time fell from an untested estimate of 45 minutes to a verified 11 minutes.
No public SCM exposure was introduced during troubleshooting.
The DNS preflight caught two later slot misconfigurations before release windows opened.
💡Key Takeaway for Glossary Readers
Private App Service designs must treat the SCM hostname as part of the production release path, not as an optional troubleshooting detail.
Case study 02
Investment analytics team locks down Kudu after credential review
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An investment analytics team found old publishing profiles stored in several release tools. The App Service main site was restricted, but Kudu access was not reviewed with the same rigor.
🎯Business/Technical Objectives
Reduce exposure from legacy publishing profiles.
Limit SCM access to approved deployment agents and administrators.
Keep deployment evidence for compliance reviews.
Avoid breaking a critical weekly analytics release.
✅Solution Using SCM site
Engineers inventoried App Service deployment settings and SCM access restrictions with Azure CLI. They moved the main release path to a managed pipeline identity, rotated old publishing credentials, and limited SCM access to the build-agent subnet plus a privileged operations VPN. The team tested zip deployment, log tailing, and rollback through the approved path before removing obsolete credentials from release tools. Kudu Advanced Tools access was documented as privileged production access, and activity logs were included in the weekly change report. The configuration was then captured in infrastructure code so future apps inherited the same SCM restrictions.
📈Results & Business Impact
Legacy publishing profiles were removed from five release tools and two shared password stores.
SCM endpoint exposure was reduced from broad corporate access to two approved network paths.
The weekly analytics release completed with no downtime after the credential change.
Compliance evidence collection dropped from a manual half day to a repeatable CLI export.
💡Key Takeaway for Glossary Readers
The SCM site is powerful enough to deserve dedicated access governance, especially when older publishing credentials still exist.
Case study 03
University portal restores emergency diagnostics without changing app code
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A university admissions portal returned intermittent 500 errors during application week. Developers could not reproduce the issue locally and needed production diagnostics quickly.
🎯Business/Technical Objectives
Inspect deployment logs and runtime files without exposing the public app.
Identify whether the latest zip deployment changed configuration unexpectedly.
Collect evidence for rollback within 20 minutes.
Preserve access controls while using Kudu diagnostics.
✅Solution Using SCM site
Operations opened the SCM site through the approved VPN path and used Kudu deployment logs to compare the latest artifact with the previous release. Azure CLI confirmed the app state, access restrictions, and relevant app settings, then tailed logs while the admissions team reproduced the failure. The team found that a static file was missing from the deployment package, causing one application path to fail. They used the existing zip deployment pipeline to redeploy the corrected artifact and verified startup through logs and synthetic tests. After the incident, a pipeline check was added to validate required files before pushing to Kudu.
📈Results & Business Impact
Root cause was identified in 14 minutes instead of escalating to a full platform outage bridge.
Admissions form failure rate dropped from 7.8 percent to below 0.2 percent after redeployment.
No temporary public Kudu access or broad firewall exception was added.
The new artifact validation step blocked three incomplete packages during the next semester.
💡Key Takeaway for Glossary Readers
A well-controlled SCM site gives teams fast deployment and diagnostic evidence without weakening the application's security boundary.
Why use Azure CLI for this?
I use Azure CLI for SCM site work because deployment problems usually involve configuration spread across App Service, access restrictions, slots, private endpoints, DNS, and app settings. The portal can show pieces, but CLI lets me capture the app resource, deployment settings, SCM access restrictions, publishing state, logs, and slot configuration consistently. After years of production releases, I do not trust a deployment path until I can prove it from a shell or pipeline. The SCM endpoint is too important to leave as a mystery behind a failed zip deploy message. It also exposes deployment risk before open release windows.
CLI use cases
Show the App Service resource and host names before diagnosing an SCM endpoint failure.
Inspect access restrictions to confirm whether SCM rules differ from main-site rules.
Run a controlled zip deployment from a pipeline identity and capture failure details.
Tail application logs after deployment to verify the app started without relying only on Kudu pages.
Review publishing credentials carefully when legacy deployments still depend on profiles.
Before you run CLI
Confirm tenant, subscription, resource group, app name, slot, region, plan, deployment method, and output format before collecting details.
Check whether the app uses private endpoints, custom DNS, access restrictions, disabled basic auth, slots, or run-from-package.
Treat deployment and credential commands as sensitive or mutating because they can expose secrets or replace application content.
What output tells you
Web app output confirms host names, state, default hostname, HTTPS settings, identity, and App Service plan context.
Access restriction output shows whether SCM-specific rules allow the pipeline agent, corporate network, or private endpoint path.
Deployment and log output reveals whether Kudu accepted the artifact, rejected access, failed extraction, or left runtime errors after deployment.
Mapped Azure CLI commands
App Service SCM site access and deployment operations
direct
az webapp config access-restriction show --resource-group <resource-group> --name <app-name>
az webapp config access-restrictiondiscoverWeb
az webapp config access-restriction set --resource-group <resource-group> --name <app-name> --use-same-restrictions-for-scm-site false --scm-default-action Deny
az webapp show --resource-group <resource-group> --name <app-name> --query "{name:name,defaultHostName:defaultHostName,hostNames:hostNames,state:state}"
az webappdiscoverWeb
Architecture context
Architecturally, the SCM site is the management and deployment sidecar for an App Service app. It should be designed as part of the app's release path, not discovered during an outage. In public apps, that means controlling who can authenticate and which networks can reach Kudu. In private apps, it means planning DNS records for both the app hostname and scm hostname, especially when private endpoints or custom DNS servers are involved. For slots, each slot has deployment behavior that must match pipeline expectations. I review SCM access with deployment identity, publishing credentials, private endpoint DNS, access restrictions, and rollback procedure.
Security
Security impact is direct because the SCM site can expose deployment APIs, environment details, process information, files, logs, and debug tooling. Attackers who gain access may be able to alter application content or harvest sensitive operational data. Operators should restrict SCM access, prefer managed deployment identities over publishing profiles where possible, disable basic publishing credentials when appropriate, protect private endpoint DNS, and audit deployment activity. Main-site restrictions are not enough if SCM restrictions are weaker. Secrets should not be left in files or logs visible through Kudu. Access to Advanced Tools should be treated as privileged production access. and releases.
Cost
The SCM site has no separate billing meter, but it affects cost through failed deployments, support time, idle release windows, and emergency engineering effort. Misconfigured SCM access can leave teams paying for hot standby capacity, delayed cutovers, or extended incident bridges while a pipeline cannot deploy. Kudu diagnostics can reduce cost by shortening troubleshooting, but unrestricted access can create security incidents that are far more expensive. Private endpoint designs may add DNS and networking operations that need ownership. FinOps reviews usually focus on App Service plan cost, but release-path failures around SCM can be a major hidden operational cost. directly.
Reliability
Reliability impact is direct for release flow and indirect for runtime recovery. The SCM site is often the path used for zip deploy, diagnostics, log access, and emergency troubleshooting. If it is blocked by DNS, access restrictions, private endpoint misconfiguration, or credential changes, teams may be unable to deploy a fix even while the app is failing. Reliable designs test SCM reachability from the same network and identity used by the pipeline. They also define alternate deployment or rollback methods, slot swap behavior, and runbooks for Kudu unavailability. A healthy app endpoint does not prove the release path is healthy.
Performance
Runtime performance is usually not directly improved by the SCM site, because it is primarily a deployment and diagnostics endpoint. Performance impact appears during releases and troubleshooting. Slow or blocked zip deploys delay fixes, while heavy diagnostic activity can add operational pressure if used carelessly during peak traffic. Kudu access can help identify CPU, file, process, or log issues faster, reducing diagnostic time. Operators should avoid using debug console activity as a substitute for proper observability and should test deployment duration, artifact size, run-from-package behavior, and slot warm-up. The performance value is mostly release speed and diagnostic speed. quickly.
Operations
Operators use the SCM site through Advanced Tools, Kudu APIs, deployment logs, log streaming, debug console, and pipeline deployment actions. Operational checks include verifying scm hostname DNS, access restrictions, publishing credentials, slot settings, deployment method, and whether private endpoints include the required scm record. Troubleshooting often compares main-site reachability with SCM reachability, then checks 403 responses, IP restrictions, authentication, and DNS resolution. CLI helps gather app configuration and logs, while Kudu gives process and file-level diagnostics when access is allowed. SCM checks should be part of release readiness, not just emergency debugging. during release, rollback, and incident response windows safely.
Common mistakes
Testing only the public app URL and assuming the deployment path through the SCM hostname is healthy.
Creating a private endpoint for App Service but forgetting DNS resolution for the scm hostname.
Leaving SCM access broader than main-site access because deployment troubleshooting was done under deadline pressure.