Zero-Downtime Deployments with Azure App Service Deployment Slots

Deploying directly to a production Azure App Service instance introduces risk: if the new version fails to start or behaves incorrectly under load, users are immediately affected. Deployment slots eliminate this risk by letting you deploy and warm up a new version in a staging environment, then swap it into production in a single atomic operation that takes seconds and does not drop connections.

This post covers creating and configuring deployment slots, managing slot-specific settings, and using traffic splitting for gradual rollouts.

1. How Deployment Slots Work

Each deployment slot is a fully independent instance of your App Service app with its own hostname, configuration, and deployment history. A swap operation exchanges the app content and most of the configuration between two slots — typically staging and production — and Azure handles the traffic cutover internally.

The key property of a slot swap is that it is warm: before traffic is redirected to the incoming slot, Azure sends HTTP requests to the slot's root path and waits for a successful response. This ensures you are not exposing a cold-started or misconfigured instance to production traffic.

Deployment slots are available on the Standard, Premium, and Isolated tiers. The Standard tier supports up to 5 slots per app, which is sufficient for most single-pipeline workflows.

2. Creating a Staging Slot

1. Navigate to App Service > Deployment slots
2. Select + Add Slot
3. Provide a Name (for example, staging)
4. Under Clone settings from, select the production slot to inherit its current configuration
5. Select Add

Once created, the staging slot is accessible at https://<app-name>-staging.azurewebsites.net. Deploy your new version to this slot using the same mechanism you use for production — Azure DevOps, GitHub Actions, or the Azure CLI.

Following is the Azure CLI command to deploy a zip package to a specific slot:

az webapp deployment source config-zip \
  --resource-group <resource-group> \
  --name <app-name> \
  --slot staging \
  --src ./release.zip

3. Slot-Specific Application Settings

Some configuration values — database connection strings, feature flags, or external service endpoints — must differ between staging and production. By default, application settings are cloned from the source slot, which is not always the correct behaviour.

Marking a setting as slot-specific prevents it from travelling with the app content during a swap. The setting stays bound to the slot it was configured on.

To mark a setting as slot-specific:

1. Navigate to App Service > Configuration > Application settings
2. Add or edit the setting
3. Check the Deployment slot setting checkbox
4. Select Save

Following is a practical pattern for slot-specific settings:

Setting	Staging value	Production value
ASPNETCORE_ENVIRONMENT	Staging	Production
ConnectionStrings__DefaultConnection	Staging database connection string	Production database connection string
FeatureFlags__NewCheckoutFlow	true	false

Settings that are not marked as slot-specific travel with the app content on swap. This is appropriate for settings that represent the app version rather than the environment — for example, an API version identifier or a build number.

4. Swapping Slots to Production

Before performing a swap, validate the staging slot by opening its URL directly and running any smoke tests relevant to the release.

To perform a swap:

1. Navigate to App Service > Deployment slots
2. Select Swap
3. Confirm Source is staging and Target is production
4. Review the Config Changes tab to confirm which settings will change as a result of the swap
5. Select Swap

The swap operation completes in under a minute for most apps. Critically, the previous production version is now resident in the staging slot, making rollback trivial: swap again to restore the previous state.

To automate a swap at the end of a deployment pipeline:

az webapp deployment slot swap \
  --resource-group <resource-group> \
  --name <app-name> \
  --slot staging \
  --target-slot production

5. Traffic Splitting for Gradual Rollouts

Rather than switching all traffic at once, you can route a percentage of production requests to the staging slot while the remainder continues to the current production version. This is useful when you want to observe error rates and response times on real traffic before completing the rollout.

1. Navigate to App Service > Deployment slots
2. Under the staging slot row, set Traffic % to the desired initial percentage (for example, 10)
3. Select Save

Azure assigns a session-pinning cookie (x-ms-routing-name=staging) to users routed to the staging slot, so their subsequent requests go to the same slot for consistency.

Increase the percentage incrementally — 10%, 25%, 50% — monitoring error rates in Application Insights at each step. Once satisfied, complete the rollout with a full swap and reset the traffic percentage to 0.

Summary

Deployment slots are the most practical tool Azure App Service provides for reducing deployment risk. Slot-specific settings keep environment configuration cleanly separated, the swap mechanism ensures warm instances are promoted to production, and traffic splitting allows confidence-building on real traffic before full cutover. Adding a staging slot to an existing App Service app takes under five minutes and pays back that time on the first deployment that would otherwise have caused an incident.