Deployment Slots and Swap

Deployment slots are live, separate environments for an App Service web app, each with its own hostname (e.g., myapp-staging.azurewebsites.net). Slots share the same App Service plan and resources as the production slot but run independently. They enable blue-green deployments — you validate a new release in a staging slot, then swap it into production with zero downtime. Slots are available from the Standard tier and above.

Add a new deployment slot to your web app using the Azure portal or CLI. Each slot gets its own URL, application settings, and connection strings. You can create up to 5 slots on Standard, and up to 20 slots on Premium tier. Common slot names include staging, canary, hotfix, and integration, reflecting different stages of the release pipeline.

Before swapping, it is critical to warm up the staging slot so the new version is fully initialised. A cold App Service instance serves the first requests slowly as the runtime initialises, which is unacceptable in production. Enable Auto Swap or manually send warm-up HTTP requests to the staging slot. App Service also supports a applicationInitialization configuration to define warm-up paths that must return 200 before the slot is considered ready.

A swap atomically exchanges the staging and production slots. During a swap, App Service first routes traffic to the staging instances running the new code, waits for them to initialise, then reroutes all production traffic to the new instances and the old production instances become the new staging slot. This makes rollback trivial — just swap again to revert.

Application settings can be marked as sticky (slot-specific) or non-sticky (swappable). Non-sticky settings travel with the deployment slot when you swap — so your staging database connection string follows the code into production. Sticky settings stay with the slot regardless of swaps — production always keeps its production database connection string. Mark settings as sticky using the 'deployment slot setting' checkbox or the CLI.

App Service supports traffic splitting — routing a percentage of production traffic to a non-production slot without performing a full swap. This enables canary releases where you gradually shift traffic from 5% to 10% to 50% as you gain confidence in the new release, monitoring error rates at each step. Users who land on the canary slot receive a sticky cookie that keeps them on the same version for session consistency.

Auto Swap automatically swaps a staging slot into production whenever new code is deployed to it. It is ideal for CI/CD pipelines where you want every successful deployment to immediately go live. Auto Swap waits for the staging slot's HTTP requests to return 200 before completing the swap. Enable it per slot in the portal or CLI — but use it cautiously, as there is no manual approval gate between deploy and production.

Follow these best practices for deployment slots: always validate in staging before swapping to production, use sticky settings to keep production database connections isolated from staging, run smoke tests against the staging slot URL after deployment, configure health check paths to ensure App Service won't complete the swap if the new version is unhealthy, and tag your deployments so you can trace which commit is live in each slot.

In a typical CI/CD pipeline, the build stage compiles and tests the code, the deploy stage pushes the artifact to the staging slot, an integration test stage runs automated tests against the staging URL, and the swap stage swaps staging into production — optionally gated by a manual approval. This pattern is supported natively in both Azure Pipelines and GitHub Actions with the App Service deploy action.

During and after a slot swap, monitor key metrics in Azure Monitor to confirm the new version is healthy. Watch for spikes in HTTP 5xx errors, average response time, and CPU/memory utilisation. Set up metric alerts that fire if error rates exceed a threshold — this gives you a signal to swap back quickly. Application Insights' smart detection can automatically alert you to anomalies after a deployment.

Deployment slots are preferable to maintaining entirely separate App Service apps for staging and production because slots share the same plan (no extra cost), have one-click swap with rollback, support traffic splitting, and are managed under the same App Service resource. Use separate apps only when staging needs fundamentally different plan SKUs, isolation requirements, or completely separate billing.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: deployment slots provide isolated environments enabling blue-green deployments, slot-sticky settings keep environment-specific configuration (like database URLs) tied to the slot rather than the code, and traffic splitting enables canary releases by routing a percentage of production traffic to a new version. Next up we explore autoscaling and custom domains.