Deployment slots
What it is
Deployment slots are separate, fully configured staging environments for an App Service web app, each with its own hostname and settings. You deploy to a slot, validate it (warm), then swap (preview) it into production with zero downtime.
Why it exists
Shipping directly to the live site is risky — you want to test the new version against real production settings before cutting it over. Slots let you release safely: deploy to staging, smoke-test with production app settings, then atomic-swap traffic instantly and roll back by swapping again. Common pattern for blue/green deployment.
Key ideas
- Environment per slot: each slot is a full deployment + its own app settings/connection strings (when not marked as deployment slot settings).
- Swap process: preview shows the changes, swap swaps deployment AND slot-specific settings you mark; slot settings (connection strings, app settings flagged
slotSticky) stay with their slot through swap. - Auto-swap: enable to swap automatically after a successful deployment in CI/CD.
- Enables rollback: swap back to the previous version if a regression is found.
- Slots are available on Standard tier and above (not Free/Basic).
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: app-service/deploy-staging-slots
Exam notes
- Slot swap = zero-downtime deployment; the production URL points at the new slot after swap.
- Deployment (slot) settings differ from regular app settings: slot settings persist with the slot across swaps (
WEBSITE_values, connection strings marked as such). - Staging slots require Standard (or higher) plan.
- AZ-104: know how to protect production keys by marking them as slot settings so they don’t get swapped to staging.
Related
Path MOC · app-service · app-service-plan
📘 Source: Microsoft Learn — Deployment Slots