Share via

When to use slots

Kyle Dilbeck 20 Reputation points
2026-05-07T23:50:45.3033333+00:00

Should slots be exclusive to production env or stg and test as well? Assuming Dev wouldnt have it

Azure Functions
Azure Functions

An Azure service that provides an event-driven serverless compute platform.

Answer accepted by question author

Rakesh Mishra 9,340 Reputation points Microsoft External Staff Moderator
2026-05-08T01:22:44.4466667+00:00

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):

Hosting Plan Total Slots
Consumption 2(1 extra)
Flex Consumption Not supported
Premium 3 (2 extra)
Dedicated (App Service) Up to 20

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.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-07T23:50:55.28+00:00

    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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.