Canary Deployment for Azure Container Apps¶

Canary deployment exposes a small slice of production traffic to a new revision, validates real behavior, and then increases weight in controlled steps. In Azure Container Apps, the platform primitive is weighted traffic split in multiple revision mode.

Why This Matters¶

Canary is useful when you want production confidence without a binary full cutover.

It reduces blast radius.
It produces real traffic evidence.
It supports rollback with a traffic change instead of a rebuild.

flowchart TD
    A[Deploy canary revision] --> B[Route 5 percent]
    B --> C[Check health and telemetry]
    C --> D{Pass gates?}
    D -->|Yes| E[Increase to 20 percent]
    E --> F[Re-check gates]
    F --> G{Pass gates?}
    G -->|Yes| H[Promote to 100 percent]
    D -->|No| I[Rollback to stable]
    G -->|No| I

Recommended Practices¶

1. Keep rollout stages explicit¶

Use fixed promotion steps such as:

95/5
80/20
50/50
0/100

az containerapp ingress traffic set \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --revision-weight "$APP_NAME--stable=95" "$APP_NAME--canary=5"

2. Put metric gates between increments¶

Do not promote on elapsed time alone. Use gates such as:

request success rate
latency percentiles
restart or probe failures
queue lag or downstream saturation

Use the monitoring and alerting docs for the detailed telemetry implementation.

3. Keep the stable revision warm¶

The stable revision should remain active until the canary reaches 100% and clears the post-promotion confidence window.

4. Automate promotion, but automate rollback too¶

CI-driven gradual rollout is useful only if the same pipeline can stop or reverse promotion.

Example promotion progression:

az containerapp ingress traffic set \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --revision-weight "$APP_NAME--stable=80" "$APP_NAME--canary=20"

az containerapp ingress traffic set \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --revision-weight "$APP_NAME--stable=0" "$APP_NAME--canary=100"

5. Use infrastructure code for the baseline, not each promotion step¶

Canary promotion is usually an operational action. Use Bicep to define revision mode and ingress, then let the pipeline update weights between stages.

resource app 'Microsoft.App/containerApps@2026-01-01' = {
  name: appName
  location: location
  properties: {
    configuration: {
      activeRevisionsMode: 'Multiple'
      ingress: {
        external: true
        targetPort: 8080
      }
    }
  }
}

Common Mistakes / Anti-Patterns¶

Jumping from 5% to 100% with no gates
Ignoring revision-specific telemetry during the canary window
Letting the stable revision go inactive too early
Treating canary as a permanent traffic split
Using resource signals alone as promotion gates

Microsoft Learn documents weighted traffic splitting, but not one universal canary schedule

Percentages such as 95/5 or 80/20 are operational patterns, not service defaults. Tune the schedule to your SLOs and downstream capacity.

Validation Checklist¶

Multiple revision mode enabled
Canary percentages defined before deployment
Revision-specific health and latency gates defined
Stable revision still active
Rollback command scripted and tested
Post-promotion observation window defined