How to create a Canary Deployment with Azure App Service and GitHub Actions

This tutorial shows how to create a Canary Deployment using Azure App Service and GitHub Actions to send a percentage of traffic to a new version of the application. It is useful to reduce risk, detect regressions and validate features in production with control.

Prerequisites

• Azure account with permissions to create App Service and Deployment Slots.
• GitHub repository with the application code (e.g.: Node.js or .NET).
• GitHub Actions enabled in the repository.
• Azure CLI installed locally (optional, useful for debugging).
• Basic knowledge of CI/CD and App Service.

Step 1: Create App Service and a Canary deployment slot

Create a primary App Service (production) and a deployment slot named canary. The slot allows an isolated version of the app without affecting the production slot.

az group create --name myResourceGroup --location northeurope
az appservice plan create --name myPlan --resource-group myResourceGroup --sku S1
az webapp create --resource-group myResourceGroup --plan myPlan --name my-prod-app
az webapp deployment slot create --name my-prod-app --resource-group myResourceGroup --slot canary

Step 2: Configure environment variables and connection strings

If the application uses secrets or connection strings, replicate only what is necessary to the canary slot or use Azure App Configuration/Key Vault. For simple tests, disable session affinity if needed.

# copy production settings to the canary slot (beware of secrets)
az webapp config appsettings list --name my-prod-app --resource-group myResourceGroup > settings.json
# edit settings.json and remove sensitive secrets
az webapp config appsettings set --name my-prod-app --resource-group myResourceGroup --slot canary --settings "@settings.json"

Step 3: Create GitHub Secret for deploy

Add a secret in the GitHub repository to allow the workflow to authenticate to Azure. Use an Azure Service Principal with the minimum permissions (contributor on the Resource Group or specific for Web Apps).

# create service principal (local)
az ad sp create-for-rbac --name github-deploy-sp --role contributor --scopes /subscriptions//resourceGroups/myResourceGroup
# outputs: appId, password, tenant
# in GitHub repo: Settings -> Secrets -> AZURE_CREDENTIALS = JSON with the above values

Step 4: Write a GitHub Actions workflow with a Canary step

Create a workflow that first publishes to the canary slot, runs health tests and then, gradually, shifts traffic or performs a partial swap. Below is a simplified example that deploys to the slot and then uses Azure CLI to adjust the traffic percentage.

# .github/workflows/canary-deploy.yml
name: Canary Deploy
on:
  push:
    branches: [ main ]

jobs:
  deploy-canary:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Login to Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - name: Build
      run: |
        # example Node.js
        npm install
        npm run build
    - name: Deploy to canary slot
      uses: azure/webapps-deploy@v2
      with:
        app-name: my-prod-app
        slot-name: canary
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        package: .
    - name: Run smoke tests against canary
      run: |
        # simple healthcheck
        curl -fsS https://my-prod-app-canary.azurewebsites.net/health || exit 1
    - name: Shift 10% traffic to canary
      run: |
        az webapp traffic-routing set --name my-prod-app --resource-group myResourceGroup --distribution '{"canary":10}'
        # monitored by external tooling or by additional steps
    - name: Promote or rollback (manual)
      run: echo "Review results and decide swap or rollback" 

Step 5: Automate traffic progression and rollback

You can automate progression from 10% → 30% → 100% with additional steps that run tests and collect metrics (latency, 5xx errors). In case of failure, the workflow should restore traffic to 0% and remove the slot or redeploy the previous version.

# example to set traffic to 0% on rollback
az webapp traffic-routing set --name my-prod-app --resource-group myResourceGroup --distribution '{"canary":0}'
# optional: swap to production if everything is OK
az webapp deployment slot swap --name my-prod-app --resource-group myResourceGroup --slot canary --target-slot production

Verify the result

Confirm the canary deploy is working by checking the canary slot endpoint and the traffic distribution in the Azure portal or via CLI. Test the health endpoint, analyze logs and metrics (Application Insights) and validate that the traffic percentage changed as configured.

Conclusion

A Canary Deployment with Azure App Service and GitHub Actions reduces risk and allows validating versions in production. Next steps: automate promotion criteria with Application Insights metrics, integrate circuit breakers and implement automatic rollback. Tip: start with 1–5% traffic to produce less impact and test rollback before automating.