App Service deployment slots: deploy to staging, swap into production, no downtime

The scariest moment in running a web app is the deploy: for a few seconds the app restarts, cold, and real users hit the gap. Deployment slots turn that moment into a non-event — you push to a warm copy first, then flip a switch that redirects traffic with nothing dropped, and if the new build is bad you flip it straight back.

On Azure App Service, a deployment slot is a live app with its own hostname, running alongside your production app on the same plan. Microsoft's line is exact: deployment slots are "live apps with their own host names," and "app content and configuration elements can be swapped between two deployment slots, including the production slot." They are available on the Standard, Premium, and Isolated tiers, and there is no extra charge for using them. The usual setup is one production slot and one staging slot — and that pair opens up a genuinely better way to ship.

The move: deploy to staging, warm up, swap

Instead of deploying straight to production, you deploy your new build to the staging slot. It is a real, running instance, so you can hit its URL and validate the change against production-like config before a single user sees it. When you are happy, you swap. And here is the part that makes it zero-downtime: before the swap completes, App Service makes sure every instance of the staging slot is fully warmed up — started, JIT-compiled, caches primed — and only then switches the routing rules. Because the new app is already warm when it takes over, there is no cold-start gap. Microsoft is blunt about the payoff: this "eliminates downtime when you deploy your app... No requests are dropped because of swap operations." The swap is a routing change, not a restart of your production traffic.

A swap does not restart production and hope. It warms the new build first, then redirects traffic to something already running — the cold start happens where no user is watching.

Rollback is just another swap

This is the feature that lets you sleep. After a swap, the slot that used to be production now holds the previous version — your last known good site, still running. If the new build misbehaves in production, you do not scramble to redeploy the old code from source and wait for a build. You just swap the same two slots again, and the previous version is instantly back in production. Rollback goes from a tense, minutes-long redeploy to a single click that takes seconds. Shipping stops being scary when undo is that cheap.

Sticky settings: the sharp edge to know

The one thing that trips people up: when you swap, most configuration travels with the app to production — language runtime version, app settings, connection strings — but some settings you deliberately want to stay put. A connection string pointing at your staging database must not follow the build into production and start writing to test data. So App Service lets you mark an app setting or connection string as a deployment slot setting (a "sticky" or slot-specific setting): it stays pinned to its slot and does not swap. The rule of thumb: anything that should differ between staging and production — a database that points somewhere different, a feature flag, a test API key — should be sticky. Getting this wrong is the classic "why is production suddenly talking to the staging database?" incident.

The takeaway

Deployment slots make shipping a web app boring in the best way. Deploy to a live staging slot, validate it, and swap — App Service warms the new build first and switches routing with no dropped requests, so production never sees a cold start. If it goes wrong, swap again to restore the previous version in seconds. Just remember to mark environment-specific config as sticky slot settings so your staging database doesn't ride along into production. "Deploy to staging, warm-swap into production for zero downtime, keep the old slot as an instant rollback, and pin the slot-specific settings" is the answer of someone who has shipped on a Friday without fear.