Deploying Zero-Downtime Releases with App Service Deployment Slots

Overview and What You Will Learn

In this lab, you will create a staging slot for an App Service, deploy a new version of an application to it while production keeps serving live traffic unaffected, verify the new version works correctly, then swap it into production - and see how quickly that swap can be reversed if something goes wrong.

Why This Matters in Production

A team at Swiggy deploys a new release directly to their single production App Service, discovers a bug affecting live orders within minutes, and has to scramble to redeploy the previous version while customers are actively affected. Deployment Slots let that same team test the new release on its own live URL first, with production completely untouched, and make the actual cutover an operation that can be undone in seconds if needed.

Core Principles

A Deployment Slot is a fully separate, live instance of an App Service, with its own distinct URL, sharing the same underlying App Service Plan as production.

A swap exchanges which slot is considered production - the new version becomes live, and the previous production version now sits in the staging slot, ready to be swapped back instantly if the new release causes a problem.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group, App Service Plan, and web app:

Note

Deployment Slots require a Standard tier (S1) or higher App Service Plan - the Free and Shared tiers do not support this feature.

2. Create a staging slot:

3. Deploy a new version of the application specifically to the staging slot, leaving production entirely untouched:

4. Visit the staging slot's own distinct URL to test the new version live, without affecting production traffic at all:

5. Once verified, swap the staging slot into production:

6. Confirm the new version is now live on the main production URL:

7. If a problem is discovered after the swap, reverse it immediately by swapping back:

8. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Deploying new code directly to the production slot with no staging step at all, then discovering a critical bug only after customers are already affected. A staging slot costs nothing extra beyond the existing App Service Plan and gives you a real, live testing environment before any customer sees the new version.

Tip

A slot swap is nearly instantaneous and immediately reversible - this makes it one of the lowest-risk ways to deploy, since a bad release can be undone in seconds rather than requiring a full redeploy of the previous version from source control.

• Slot-specific settings stay with the slot during a swap, not with the code. Configure settings like connection strings correctly per slot before swapping, since a setting marked as "slot-specific" will not move to production during the swap - it stays behind in whichever slot it was originally set on.
• Warm up the staging slot before swapping by sending it a few real requests first, so the application's cold-start initialization has already happened before it becomes production traffic.

Quick Reference & Troubleshooting Commands