Skip to content

Deployment Slots Validation

Use staging slots to validate deployments before production swap, with health checks and automated safeguards in GitHub Actions.

flowchart TD
    A[Deploy to staging slot] --> B[Apply slot-sticky settings]
    B --> C[Run /health and /info checks]
    C --> D[Run /readyz validation]
    D --> E{Checks pass?}
    E -- Yes --> F[Swap to production]
    E -- No --> G[Fix and redeploy staging]

Prerequisites

  • App Service plan supports deployment slots
  • Production app already running
  • CI/CD pipeline can deploy to specific slot

Main content

1) Create staging slot

az webapp deployment slot create \
  --resource-group "$RG" \
  --name "$APP_NAME" \
  --slot "staging" \
  --output json
Flag Description
--resource-group "$RG" Creates the slot under the resource group that contains the production app.
--name "$APP_NAME" Selects the web app that will receive the new deployment slot.
--slot "staging" Names the new slot staging.
--output json Returns the created slot configuration as JSON.

2) Configure slot-sticky settings

Mark environment-specific values so they do not swap:

az webapp config appsettings set \
  --resource-group "$RG" \
  --name "$APP_NAME" \
  --slot "staging" \
  --slot-settings NODE_ENV=staging FEATURE_FLAG_USE_BETA=true \
  --output json
Flag Description
--resource-group "$RG" Targets the resource group that contains the slot.
--name "$APP_NAME" Selects the web app whose staging slot settings will be updated.
--slot "staging" Applies the configuration change to the staging slot instead of production.
--slot-settings NODE_ENV=staging FEATURE_FLAG_USE_BETA=true Writes slot-sticky app settings that stay with the staging slot during swaps.
--output json Returns the updated settings payload as JSON.

3) Deploy artifact to staging slot

az webapp deploy \
  --resource-group "$RG" \
  --name "$APP_NAME" \
  --slot "staging" \
  --src-path "release.zip" \
  --type zip \
  --output json
Flag Description
--resource-group "$RG" Targets the resource group that contains the staging slot.
--name "$APP_NAME" Selects the web app that should receive the deployment.
--slot "staging" Deploys the package to the staging slot instead of production.
--src-path "release.zip" Uploads the release.zip package as the deployment artifact.
--type zip Tells App Service to treat the uploaded artifact as a Zip Deploy package.
--output json Returns deployment details as JSON.

4) Add explicit health endpoint checks

curl --fail --silent "https://$APP_NAME-staging.azurewebsites.net/health"
curl --fail --silent "https://$APP_NAME-staging.azurewebsites.net/info"

5) Add version-aware validation endpoint

app.get('/readyz', (req, res) => {
  res.json({
    status: 'ready',
    environment: process.env.NODE_ENV || 'production',
    buildVersion: process.env.BUILD_VERSION || 'unknown'
  });
});

6) Swap staging to production

az webapp deployment slot swap \
  --resource-group "$RG" \
  --name "$APP_NAME" \
  --slot "staging" \
  --target-slot "production" \
  --output json
Flag Description
--resource-group "$RG" Targets the resource group that contains the source and target slots.
--name "$APP_NAME" Selects the web app whose slots will be swapped.
--slot "staging" Uses the staging slot as the source of the swap.
--target-slot "production" Promotes the staging slot into the production slot.
--output json Returns swap-operation details as JSON.

7) Optional auto-swap configuration

az webapp deployment slot auto-swap \
  --resource-group "$RG" \
  --name "$APP_NAME" \
  --slot "staging" \
  --auto-swap-slot "production" \
  --output json
Flag Description
--resource-group "$RG" Targets the resource group that contains the slot configuration.
--name "$APP_NAME" Selects the web app whose slot should auto-swap.
--slot "staging" Enables auto-swap on the staging slot.
--auto-swap-slot "production" Configures production as the automatic swap target.
--output json Returns the updated auto-swap configuration as JSON.

Linux Limitation

Auto-swap is not supported for web apps on Linux and Web App for Containers. Use manual swap or CI/CD-triggered swap instead. See Deployment Slots for details.

Use auto-swap only when health checks and deployment confidence are high.

8) GitHub Actions staged deployment example

name: Staged Deployment

on:
  push:
    branches: [ main ]

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to staging slot
        uses: azure/webapps-deploy@v3
        with:
          app-name: ${{ secrets.AZURE_WEBAPP_NAME }}
          slot-name: 'staging'
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE_STAGING }}
          package: .

  validate:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: Check staging health
        run: curl --fail --silent "https://${{ secrets.AZURE_WEBAPP_NAME }}-staging.azurewebsites.net/health"

  swap:
    needs: validate
    runs-on: ubuntu-latest
    steps:
      - name: Azure Login
        uses: azure/login@v2
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
      - name: Swap slots
        run: |
          az webapp deployment slot swap \
            --resource-group ${{ secrets.AZURE_RESOURCE_GROUP }} \
            --name ${{ secrets.AZURE_WEBAPP_NAME }} \
            --slot staging \
            --target-slot production \
            --output none
Command Description
az webapp deployment slot swap --resource-group ${{ secrets.AZURE_RESOURCE_GROUP }} --name ${{ secrets.AZURE_WEBAPP_NAME }} --slot staging --target-slot production --output none Swaps the validated staging deployment into production from the GitHub Actions job without printing a JSON payload.

Validate before swap, always

A successful deployment is not the same as a healthy runtime. Require endpoint validation and telemetry checks before production swap.

Verification

  • Staging serves expected build version.
  • Production remains stable before swap.
  • Swap completes without config leakage.
  • Post-swap /health remains healthy.
curl --include "https://$APP_NAME.azurewebsites.net/health"

Troubleshooting

Staging healthy, production fails after swap

  • Check slot-sticky config alignment.
  • Verify hostnames/certs for slot-specific behavior.
  • Confirm staging used production-like dependencies where required.

Swap operation blocked

Validate no pending restart/operation exists and check App Service Activity Log for conflicts.

Auto-swap caused unexpected release

Disable auto-swap and enforce manual approval stage in GitHub Actions for high-risk environments.

Run It in the Portal

Portal view: Deployment slots with Swap dialog (validated promotion)

Swap pane from the staging slot to the production slot with a Source slot changes table listing app settings and their old and new values

Purpose: Show the configuration changes a swap will apply before you start it.

Look for: The Source and Target slots, Perform swap with preview, and the Config Changes table.

Expected result: The table lists every setting that changes on swap; review each row before selecting Start Swap.

The Deployment slots blade with the Swap panel open is the Portal counterpart to the az webapp deployment slot swap command this recipe drives from CI. The Source: app-test-20251107-staging and Target: app-test-20251107 selectors mirror the staging-to-production promotion direction the recipe validates against. The Config Changes table at the bottom previews how slot-sticky settings will move during the swap, including the APPLICATIONINSIGHTS_CONNECTION_STRING and SCM_DO_BUILD_DURING_DEPLOYMENT rows visible here — the same delta you should inspect before clicking Start Swap. Use this Portal view as the manual checkpoint complementing the automated pre-swap validation calls (health probe, smoke test) the recipe issues against the Node.js staging slot.

See Also

Sources