What happens during a slot swap?

During a swap, Azure first applies the target slot's sticky settings to the source slot and restarts the workers, then waits for every instance in the source slot to complete a warm-up request. Once all instances are warm and responding, Azure swaps the virtual IPs so traffic flows to the newly warmed instances. The previous production code is now in the staging slot, making rollback a simple re-swap. The entire process maintains at least one slot handling traffic at all times.

Which settings should be slot-sticky?

Any setting that should differ between environments should be slot-sticky: database connection strings, API keys for environment-specific backends, feature flags, Application Insights instrumentation keys (if different per slot), and diagnostic settings. Settings that should travel with the code — like application behavior configuration that changes with each release — should not be sticky. A common mistake is making all settings sticky, which prevents new settings from reaching production during swaps.

Can I route a percentage of production traffic to a staging slot?

Yes, Azure App Service supports traffic routing percentages to deployment slots. You can configure production to send, for example, 10% of requests to a staging slot for canary testing. Azure uses cookie-based affinity (x-ms-routing-name) to ensure individual users consistently see the same slot during their session. This lets you validate new code with real production traffic before performing a full swap.

Azure Web App Slot Config Builder

ComputeAzure

Build App Service deployment slot configurations with sticky settings and traffic routing.

Last verified: May 2026

App Service Configuration

Build App Service deployment slot configurations with sticky settings, traffic routing, and auto-swap.

Required Fields

appNameslotNamesiteConfigappSettings

{
  "appName": "app-orders-prod",
  "resourceGroup": "rg-webapp",
  "slotName": "staging",
  "siteConfig": {
    "alwaysOn": true,
    "autoSwapSlotName": "production",
    "http20Enabled": true,
    "minTlsVersion": "1.2",
    "healthCheckPath": "/api/health"
  },
  "appSettings": [
    { "name": "ASPNETCORE_ENVIRONMENT", "value": "Staging", "slotSetting": true },
    { "name": "APP_CONFIG_ENDPOINT", "value": "https://appconfig-staging.azconfig.io", "slotSetting": true },
    { "name": "APPLICATIONINSIGHTS_CONNECTION_STRING", "value": "InstrumentationKey=00000000-0000-0000-0000-000000000000", "slotSetting": false }
  ],
  "connectionStrings": [
    {
      "name": "DefaultConnection",
      "value": "Server=sql-staging.database.windows.net;Database=orders-db;...",
      "type": "SQLAzure",
      "slotSetting": true
    }
  ],
  "trafficPercentage": 10,
  "routingRules": [
    {
      "actionHostName": "app-orders-prod-staging.azurewebsites.net",
      "reroutePercentage": 10,
      "changeStep": 5,
      "changeIntervalInMinutes": 10,
      "minReroutePercentage": 5,
      "maxReroutePercentage": 50
    }
  ]
}

Generated Output

Output will appear here...

About This Tool

Azure App Service deployment slots enable zero-downtime deployments by letting you deploy to a staging slot, validate the deployment, and then swap it into production. Slots share the same App Service Plan but can have independent configurations — app settings, connection strings, managed identity assignments, and custom domains. Configuring slots requires understanding which settings are slot-sticky (remain with the slot during swap) versus which travel with the code. The Slot Config Builder helps you design slot configurations with correct sticky settings, auto-swap rules, and pre-swap warm-up paths.

Real-World Scenario

Your team is implementing zero-downtime deploys for a customer-facing web app. The builder generates a 2-slot setup (production + staging) with: connection strings to a staging DB marked slot-sticky, custom domain routing 5% of traffic to staging for canary, warm-up path /healthz that hits 3 critical endpoints, manual swap approval. After deploy, the team validates the staging slot at 5% traffic for 30 minutes before swapping. Production deploys went from 'risky weekend events' to 'routine Tuesday afternoons' with measurably lower incident rates.

When to Use This Tool

•Building deployment slot configurations with slot-sticky database connection strings that point staging to a staging database and production to the production database
•Configuring auto-swap settings that automatically promote staging to production after successful health checks
•Setting up custom warm-up paths that pre-load caches and JIT-compile code before a slot swap completes
•Creating slot configurations for blue-green deployments with traffic routing that sends a percentage of users to the staging slot for canary testing

Pro Tips

TIP

The most-misused setting is making EVERY app setting slot-sticky. If staging swaps to production carrying its own connection strings, the new prod code uses staging's database — and writes to it. Only mark TRULY environment-specific settings as sticky (DB connections, env-specific API endpoints). Behavior config that should travel with code stays non-sticky.

TIP

Pre-warm the staging slot BEFORE the swap by hitting a custom warm-up path. Add a `WEBSITE_SWAP_WARMUP_PING_PATH=/warmup` setting and implement an endpoint that pre-loads caches and JIT-compiles common code paths. Without this, the swap completes but the first 30+ seconds of production traffic hits cold instances.

TIP

Auto-swap is dangerous in practice. It promotes staging to prod after deploy succeeds — but 'deploy succeeded' just means the build artifact uploaded, not that the app works. Always require manual approval after explicit smoke tests, even if it means an extra step in the pipeline.

How It Works Under the Hood

The builder constructs deployment slot configurations across three concerns: which app settings are slot-sticky vs. slot-traveling, auto-swap behavior, and warm-up settings. Output includes az webapp deployment slot create + config commands, the explicit list of sticky setting names for the slot config, and Terraform azurerm_app_service_slot resources.

Frequently Asked Questions

What happens during a slot swap?: During a swap, Azure first applies the target slot's sticky settings to the source slot and restarts the workers, then waits for every instance in the source slot to complete a warm-up request. Once all instances are warm and responding, Azure swaps the virtual IPs so traffic flows to the newly warmed instances. The previous production code is now in the staging slot, making rollback a simple re-swap. The entire process maintains at least one slot handling traffic at all times.
Which settings should be slot-sticky?: Any setting that should differ between environments should be slot-sticky: database connection strings, API keys for environment-specific backends, feature flags, Application Insights instrumentation keys (if different per slot), and diagnostic settings. Settings that should travel with the code — like application behavior configuration that changes with each release — should not be sticky. A common mistake is making all settings sticky, which prevents new settings from reaching production during swaps.
Can I route a percentage of production traffic to a staging slot?: Yes, Azure App Service supports traffic routing percentages to deployment slots. You can configure production to send, for example, 10% of requests to a staging slot for canary testing. Azure uses cookie-based affinity (x-ms-routing-name) to ensure individual users consistently see the same slot during their session. This lets you validate new code with real production traffic before performing a full swap.

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.