Deployment Slot
A separate, live instance of an App Service (such as staging) that shares the same App Service Plan as production and can be swapped with it for zero-downtime deployments and instant rollback.
Deployment Slot
Deployment slots let you deploy and warm up a new version in staging, then swap it into production instantly — the swap is a routing change, not a redeploy.
Why It Matters in Production
PhonePe deploys new backend releases to a staging slot, runs smoke tests against it, and only swaps to production once health checks pass — a bad release can be swapped back in seconds.
az webapp deployment slot swap --resource-group phonepe-prod-rg \ --name phonepe-api --slot staging --target-slot productionCommon MistakeForgetting that some app settings are "slot-specific" and don't swap — connection strings pointing at different databases per slot need
Deployment slot settingexplicitly checked.
Frequently Asked Questions
What's the actual mechanism behind a deployment slot swap?
A swap isn't a redeploy — it's a virtual IP address remap between two already-running App Service instances. Because staging and production share the same App Service Plan and both are 'warmed up' before the swap, users experience effectively zero downtime, and Azure runs your app's warm-up requests against the staging slot first if you configure them. Swapping is why slots are cheaper than a full blue-green setup on separate infrastructure — no duplicate compute is provisioned.
What's a gotcha people hit with deployment slots?
App settings and connection strings are swapped by default too, unless you explicitly mark them 'slot-specific' in the portal or ARM template. Forgetting this means your staging slot can accidentally end up pointing at the production database after a swap, or a swap can silently move a staging-only feature flag into production. Also, deployment slots are only available on Standard tier and above — Free and Shared tiers don't support them at all.