Deployment Slots

What Are Deployment Slots?

Each deployment slot is a fully independent App Service instance with its own:

• Hostname: myapp-staging.azurewebsites.net
• App settings and connection strings
• Deployment source configuration
• Application code

Slots run on the same App Service Plan as the production slot — sharing compute resources. The production slot is always named "production" (accessible at myapp.azurewebsites.net).

Creating Slots

# Create a staging slot
az webapp deployment slot create \
  --name mywebapp-2026 \
  --resource-group myRG \
  --slot staging

# Deploy to staging slot (not production)
az webapp deploy \
  --name mywebapp-2026 \
  --resource-group myRG \
  --slot staging \
  --src-path myapp.zip \
  --type zip

# List all slots
az webapp deployment slot list \
  --name mywebapp-2026 \
  --resource-group myRG \
  --output table

The staging slot is accessible at: https://mywebapp-2026-staging.azurewebsites.net

The Swap Process

When you swap slots, App Service:

1. Warms up the source slot — Applies target slot's settings to source, restarts it, sends warm-up requests until it responds
2. Switches routing — Updates the host name routing atomically — source becomes target, target becomes source
3. Post-swap — Old production is now in the staging slot, ready for rollback if needed

# Swap staging slot to production
az webapp deployment slot swap \
  --name mywebapp-2026 \
  --resource-group myRG \
  --slot staging \
  --target-slot production

# Rollback (swap back)
az webapp deployment slot swap \
  --name mywebapp-2026 \
  --resource-group myRG \
  --slot staging \
  --target-slot production

What Gets Swapped vs Stays

Understanding what moves with the slot vs what stays is critical — it's frequently tested in AZ-104.

Slot Settings (Sticky Settings)

By default, App Settings and Connection Strings swap with the code. But sometimes you want a setting to stay in its slot — for example, a connection string that should always point to the production database regardless of which code is deployed.

Mark a setting as a Slot Setting (also called "sticky") to prevent it from swapping. Common examples:

• Production database connection string — should always point to prod DB
• Environment name variable (ENVIRONMENT=production)
• Third-party API keys that differ between environments

# Set a sticky app setting
az webapp config appsettings set \
  --name mywebapp-2026 \
  --resource-group myRG \
  --slot staging \
  --slot-settings DATABASE_URL=staging-connection-string

Traffic Splitting

Traffic splitting (also called Testing in Production) routes a percentage of real user traffic to a non-production slot — useful for A/B testing or canary releases.

• Configure a percentage (e.g., 10%) to route to staging
• Users are sticky — once assigned to a slot, they stay there for the session
• Azure adds an x-ms-routing-name cookie to track which slot a user is in

# Route 10% of traffic to staging slot
az webapp traffic-routing set \
  --name mywebapp-2026 \
  --resource-group myRG \
  --distribution staging=10

Auto-Swap

Configure a slot to automatically swap into production whenever new code is deployed to it. Enables fully automated zero-downtime deployment pipelines.

• Enable Auto-Swap on the staging slot
• Set the target slot (usually production)
• After each successful deployment to staging, App Service automatically swaps to production

Swap with Preview

A two-phase swap for extra safety:

1. Phase 1 — Apply production's slot settings to staging, restart staging. Preview the result at the staging URL with production settings.
2. Verify — Test that staging works with production settings.
3. Phase 2 — Complete the swap — routing switches to the staged code.