Azure App Service hosts web applications and APIs while Azure manages the underlying web platform, operating-system patching, health infrastructure, and deployment integration.
The App Service plan determines compute capacity and major features; the web app contains code, settings, identity, domains, networking, and deployment configuration.
A reliable App Service release uses immutable artifacts, slot-specific configuration, health checks, managed identity, and a tested slot swap or rollback procedure.
Choose an operating system, runtime, Region, and plan tier that support the required scaling, networking, slots, and certificates. Multiple apps on one plan share its compute resources.
Store non-secret settings in App Service configuration and retrieve secrets from Key Vault using managed identity. Mark environment-specific slot settings so they do not move during a swap.
Configure custom domains and TLS, then decide whether inbound access is public, access-restricted, or private. VNet integration provides outbound connectivity and does not by itself make the app private.
Deploy to a staging slot, warm it, run smoke tests, and swap only after health succeeds. Application Insights, App Service logs, metrics, and deployment logs should explain failed startup or requests.
An App Service plan supplies compute capacity and feature availability to the apps and slots placed on it. Apps on the same plan share worker instances, scale behavior, and contention risk even though they are separate web-app resources. Group them only when shared capacity, ownership, operating system, Region, and failure impact are acceptable.
Choose Windows, Linux, or custom-container hosting and a plan tier that supports the required deployment slots, VNet integration, zone redundancy, private endpoints, certificates, and scaling. Feature and regional support changes over time, so verify the exact plan and Region rather than relying on a generic App Service checklist.
Measure CPU, memory working set, request queue, response time, file-system use, connections, and downstream latency per app. Moving one noisy app to a separate plan can be safer than scaling every app together. Include staging slots in temporary and steady capacity calculations.
Select a supported built-in runtime version or deploy a controlled container image. Track end-of-support dates and test upgrades with native dependencies, startup commands, certificates, time zones, and file paths. The platform patches its hosting layer, while the application team remains responsible for code and package vulnerabilities.
Build an immutable artifact once and promote the same package or image through environments. Avoid deployment mechanisms that rebuild from a moving branch on the production app. Record source commit, build, artifact digest, runtime, and release identity so logs and rollback point to exact bytes.
App Service local file storage has platform-specific persistence and sharing behavior and should not become an accidental system of record. Put durable user data in Storage or a database, keep temporary files bounded, and test application behavior across restart, scale-out, and instance replacement.
App settings are exposed to the application as configuration and are encrypted by the platform at rest, but they remain readable to sufficiently privileged resource administrators. Store ordinary non-secret configuration there and use managed identity with Key Vault for secrets that need separate control, rotation, and audit.
A system-assigned identity follows the app or slot resource, while a user-assigned identity has an independent lifecycle. Managed identity is configured per slot. Grant the identity narrow data roles at downstream resources and coordinate role propagation before swapping traffic to a revision that requires new access.
Key Vault references reduce secret copying but do not remove network, identity, version, refresh, or availability design. Mark environment-specific settings as deployment-slot settings, validate every required value during startup, and make missing secret behavior fail clearly without printing the secret.
A custom domain and certificate establish the public name and TLS path, while access restrictions, private endpoints, built-in authentication, Front Door, or Application Gateway shape inbound access. A private endpoint gives a private inbound address; it does not configure the applications outbound path.
VNet integration sends supported outbound traffic from the app into a delegated subnet so it can reach private endpoints, databases, or controlled egress. Plan subnet capacity, routes, DNS, NAT or firewall, and service endpoints. VNet integration by itself does not make the public app endpoint private.
Private DNS must return the correct private address from integrated and connected networks. Test name resolution and TLS from the running app, not only from a portal test. Record outbound addresses or route-all behavior only as part of the selected architecture, because scaling and network configuration can affect the source path.
A deployment slot is a live app with its own hostname, configuration, identity, and potentially shared plan capacity. Deploy the candidate artifact to staging, apply slot-specific settings, warm startup paths and dependencies, run smoke tests, then preview or perform the swap according to the release procedure.
During a swap, selected configuration moves while settings marked as slot settings remain. Authentication, managed identity, network, Key Vault references, caches, and background jobs need explicit testing because a healthy HTTP page may not prove the full application is ready. Prevent both slots from processing the same scheduled or queue work unless duplicate handling is designed.
Swap back can restore routing to the old slot, but it cannot undo database writes, external messages, or incompatible schema. Use expand-and-contract changes and preserve the old revisions configuration until the observation window ends. Record which app and slot own the production hostname after every release.
Scale up changes worker capability; scale out adds instances. Choose autoscale signals tied to demand and downstream capacity, set safe minimum and maximum counts, and account for warm-up. Session affinity can hide stateful design and distribute load unevenly, so keep session state in a shared durable service where practical.
Configure a health-check path that proves application readiness without making one shared dependency outage recycle every worker. Application Insights and Azure Monitor should cover request rate, failure, latency percentiles, dependency calls, exceptions, worker saturation, restarts, and deployment markers. Set log retention and redact request data.
Exercise failed startup, unavailable Key Vault, broken private DNS, dependency slowdown, bad slot swap, scale-out, and plan restart. Verify rollback and data compatibility. App Service reduces server operations, but production ownership still includes runtime support, application security, network paths, capacity, telemetry, and recovery.
Before each release, verify the App Service runtime, operating system, plan generation, TLS policy, certificate, networking features, deployment extension, and Application Insights integration remain supported. Test a plan or runtime upgrade in a slot or representative app, including startup, native packages, managed identity, private DNS, and swap behavior.
Deployment slots let you validate a new build before traffic is switched, which is one of the safest production patterns in App Service.
az webapp deployment slot create \
--resource-group rg-cloud-lab \
--name app-web-prod \
--slot staging
az webapp deployment slot swap \
--resource-group rg-cloud-lab \
--name app-web-prod \
--slot staging \
--target-slot productionA release uses a staging slot but one secret and one connection string must remain production-specific.
Constraints: Slot settings must not move; warm-up must complete before traffic switches; rollback must be quick.
Decision: Mark environment-specific values as slot settings, validate staging health, swap with preview, then complete the swap.
Verification: Production keeps its secret references, the new build is warm, and the old build remains available in staging.
Failure test: Break the staging health endpoint and confirm the swap is stopped before customer traffic moves.Expected evidence: Production keeps its secret references, the new build is warm, and the old build remains available in staging.Explore 500+ free tutorials across 20+ languages and frameworks.