When to use slots

Hey Kyle, great question! Deployment slots are not exclusive to production — but how heavily you use them should reflect the criticality and deployment needs of each environment. Here's the practical breakdown:

1. Production - strongly recommended

This is where slots provide the most value. Deploy new builds to a non-production slot (e.g., staging), validate them, then swap into production. Per the official docs, the key benefits are:

• Zero dropped requests: traffic redirection during a swap is seamless; the next function trigger is routed to the swapped slot.
• Prewarming: instances warm up before going live, reducing cold starts for HTTP-triggered workloads.
• Instant rollback: if something goes wrong post-swap, a reverse swap immediately restores your last known good state.
• Minimize restarts: app setting changes can be staged and swapped in without restarting your production app directly.

2. Staging / Pre-production - recommended

If your staging environment is customer-facing or mirrors production behavior closely, slots are equally worthwhile here. Deploying to a slot first and then swapping gives you the same safety guarantees as production.

3. Test / QA - situational

Use slots if the environment must stay available during deployments, or if you need to validate the swap process itself. If tests are short-lived or environments are frequently torn down and recreated, plain re-deployments without slots may be simpler and sufficient.

4. Dev - generally not needed

Dev environments typically keep things simple. Slots add cost and complexity that usually aren't justified at this stage. That said, if you specifically need to test slot-swap behavior end-to-end, you could add a slot to a dev app.

Slot limits by hosting plan (total slots including production):

Important: If you're on the Flex Consumption plan, deployment slots are not currently supported — this is a common gotcha worth checking before designing your deployment strategy.

CI/CD best practice: Your pipeline should always deploy to a non-production slot, then trigger a swap into production rather than deploying directly to the production slot. This ensures prewarming and gives you a rollback path.

Note: This response is drafted with the help of AI systems.

Slots should be used wherever zero-downtime deployment, validation before release, and easy rollback are important, not only in production.

Typical pattern:

1. Production environment
   • Strongly recommended to use slots.
   • Deploy new builds to a non-production slot (for example, staging) and then swap into the production slot.
   • Benefits for Azure Functions and App Service:
     • Prewarming instances to avoid cold starts and downtime.
     • Seamless traffic redirection with no dropped requests.
     • Instant rollback by swapping back to the previous slot.
2. Staging / pre‑production environment
   • Also a good candidate for slots when that environment is customer-facing or mission‑critical.
   • Same pattern: deploy to a secondary slot, validate/smoke test, then swap into the staging “production” slot.
   • This mirrors production behavior and helps catch deployment issues early.
3. Test / QA environments
   • Use slots if:
     • The test environment must stay available during deployments, or
     • Multiple versions need to be validated with quick swap/rollback.
   • If tests are short‑lived or environments are frequently recreated, plain re-deployments without slots might be sufficient.
4. Dev environments
   • Often kept simple without slots to reduce cost and complexity.
   • However, slots can still be used if developers need to:
     • Test slot swap behavior itself.
     • Reproduce production-like deployment flows end-to-end.

Key constraints and considerations:

• Plan/tier limits
  • Azure Functions: number of slots depends on hosting plan (Consumption, Premium, Dedicated, etc.).
  • App Service: slots are available only on Standard tier or higher; each tier has a maximum number of slots.
• Best practice for CI/CD
  • Continuous deployment should target non-production slots, then use swap into the production slot instead of deploying directly to production.

So slots are not exclusive to production; they are most critical there, but can be very useful in staging and some test environments. Dev commonly runs without slots unless there is a specific need to mirror production deployment behavior.

References:

• Azure Functions deployment slots
• Deployment best practices
• Set up staging environments in Azure App Service
• Set up deployment slots to enable zero downtime in Azure Logic Apps
• Deploy to Azure App Service deployment slots with Azure Developer CLI