Deployment Slots: Staging Environments Inside One Service

Deployment slots give a running service parallel, addressable copies that can be warmed and swapped, reducing release risk without a second cluster.

delivery

Definition

A deployment slot is a secondary instance of a service with its own hostname and configuration that shares the same deployment definition. Traffic can be warmed on the slot, then swapped or shifted to it, and the swap is reversible.

Context and scope

Platforms such as Azure App Service expose slots natively; teams on Kubernetes emulate them with a parallel deployment and a service selector.

Common misconceptions

A slot is just a staging environment — slots share the production plan and are swapped atomically
Swapping is instant and free — connections, caches, and sticky sessions still need attention
Slots remove the need for migration care — schema changes must be compatible with both slots

Anti-patterns

Swapping slots with pending database migrations that only one version understands
Forgetting slot-specific settings such as connection strings and feature flags
Using a slot as a permanent environment without ownership or cost tracking

Related concepts

Authoritative source

https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots

A second copy behind the same front door

A deployment slot runs the same application definition on separate infrastructure, with its own hostname and settings. You deploy to the idle slot, warm it, test it, and then redirect production traffic to it. The previous version stays running in the other slot, which makes rollback a redirect rather than a rebuild.

Warming before the swap

Cold starts are the most common cause of a bad release. A slot lets you hit the new version directly before any real user does: prime caches, open connection pools, run JIT warm-up, and verify configuration. For example, a slot swap that sends traffic to an instance with an empty cache can produce a latency spike that looks like a code regression.

deploy:
  slot: staging
  warmup:
    - url: /healthz
      expect: 200
    - url: /api/warmup
      expect: 200
swap:
  target: production
  rollback: true

What a swap does not fix

A slot does not isolate state. Sessions, in-memory caches, background workers, and database connections all cross the boundary. A swap also does not solve schema compatibility: both slots may briefly serve traffic against the same database, so migrations must be backward compatible for at least one deploy cycle. Sticky sessions need a documented plan, or users will be logged out at swap time.

Compared to rolling and blue-green

Rolling deployment replaces instances gradually and needs no duplicate capacity, but it exposes users to a slow mix of versions. Blue-green achieves the same atomic switch with separate infrastructure and often more cost. Slots sit between them: cheaper than a full second environment, more atomic than a rolling update, and limited to a single service’s scope.

When to use them

Use slots when releases are infrequent enough that duplicate capacity is acceptable and when warm-up materially changes behaviour. For high-frequency deploys, progressive delivery with traffic shifting is usually a better fit.