Revision mode tells Azure Container Apps how many versions of your app are allowed to run at once. In single mode, the platform moves traffic to the newest healthy revision and deprovisions the old active one. In multiple mode, several revisions can stay active so teams can split traffic, test labels, run blue-green releases, or keep a rollback path open. It is a release-behavior setting, not just a display preference, because it changes how traffic and active replicas are managed.
Revision mode tells Azure Container Apps how many versions of your app are allowed to run at once. In single mode, the platform moves traffic to the newest healthy revision and deprovisions the old active one. In multiple mode, several revisions can stay active so teams can split traffic, test labels, run blue-green releases, or keep a rollback path open. It is a release-behavior setting, not just a display preference, because it changes how traffic and active replicas are managed.
In Azure architecture, revision mode belongs to the Container Apps configuration that governs deployment flow, ingress traffic, active revision count, and rollback strategy. It affects how revisions, labels, traffic weights, health probes, and replica scaling work during updates. Changing revision mode does not create a new revision, but it changes how existing and future revisions can be active. Operators manage it through portal revision management, Azure CLI revision set-mode, ARM or Bicep configuration, and pipeline release gates.
Why it matters
Revision mode matters because it determines whether a release is mostly automatic or deliberately controlled. Single mode is simpler and safer for many services because a healthy new revision replaces the old one only after readiness checks. Multiple mode gives teams powerful release patterns, such as canary, A/B testing, labels, and blue-green cutover, but it also creates more operational responsibility. If traffic weights or labels are wrong, users can keep hitting an old version or an untested candidate. If multiple active revisions keep minimum replicas, cost and capacity can rise. Choosing the mode is a release-management decision, not a cosmetic setting.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Container Apps Revision management blade, revision mode appears as Single or Multiple and controls whether traffic splitting and multiple active revisions are available.
Signal 02
In Azure CLI, az containerapp revision set-mode changes the mode, while show and revision list output confirm activeRevisionMode and currently active revisions. during rollout checks.
Signal 03
In deployment pipelines, revision mode appears as a preflight check before traffic-weight, label, canary, or blue-green commands run against the container app. before public cutover.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Switch to multiple mode before a blue-green release where the new revision must be tested through a label-specific URL.
Keep single mode for simple APIs where the newest healthy revision should automatically replace the old one.
Enable canary traffic percentages when a risky image needs limited production exposure before full cutover.
Prevent stale revision exposure by returning to single mode or deactivating old revisions after a controlled rollout.
Standardize pipeline preflight checks so staging and production use the same revision behavior before deployment.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Insurance quote service enables measured canary rollout
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An insurer wanted to release a new quote-scoring API but feared incorrect premiums for a small set of drivers. The existing Container App ran in single revision mode, so traffic splitting was unavailable.
🎯Business/Technical Objectives
Expose the new scoring revision to only five percent of traffic.
Keep the previous quote engine available for immediate rollback.
Compare premium-calculation latency and error rate by revision.
Prevent stale canary traffic after release approval.
✅Solution Using Revision mode
The platform team changed Revision mode to multiple before deployment, then created a new revision with a clear suffix and routed five percent of ingress traffic to it. Azure CLI preflight checks confirmed activeRevisionMode, active revisions, minimum replicas, and the expected rollback revision. Monitoring separated quote latency, validation errors, and downstream rating-service calls by revision. After business signoff, traffic moved to the new revision, the old revision stayed available for one hour, and then the team deactivated the canary and documented the mode, weights, and timestamps.
📈Results & Business Impact
The canary caught a premium-rounding bug affecting 1.7 percent of sampled quotes.
Production impact stayed below 90 affected sessions because traffic was limited.
Full rollout completed two days later with p95 latency 18 percent lower.
Old revision cleanup prevented about $1,200 in extra monthly replica and logging cost.
💡Key Takeaway for Glossary Readers
Revision mode turns Container Apps from automatic replacement into a controlled release mechanism when risk demands it.
Case study 02
Media platform uses labels for blue-green validation
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A media streaming platform needed to validate a new recommendations service with editors before sending viewers to it. The team wanted a stable test URL that would not change each deployment.
🎯Business/Technical Objectives
Run blue and green revisions side by side during editorial testing.
Give editors a label-specific URL for the candidate version.
Switch viewer traffic only after relevance and latency checks passed.
Avoid leaving both versions active after cutover.
✅Solution Using Revision mode
The release team set Revision mode to multiple and used revision labels for blue and green recommendation-service versions. Editors tested the green label URL while public traffic stayed on blue. Azure CLI captured the app mode, labels, traffic weights, and revision FQDNs before each cutover step. Metrics compared recommendation latency, click-through proxy events, and error rate by revision. Once green passed editorial and performance checks, traffic weights moved to green, the label followed, and blue was deactivated after a short rollback window.
📈Results & Business Impact
Editorial validation found two ranking regressions before viewer traffic moved.
Traffic cutover completed in 11 minutes with no DNS or app URL changes.
Recommendation p95 latency improved from 310 milliseconds to 220 milliseconds.
Parallel revision cost was limited to a four-hour release window.
💡Key Takeaway for Glossary Readers
Multiple revision mode plus labels gives teams a clean blue-green pattern without changing the stable application endpoint.
Case study 03
University scheduler keeps single mode for predictable operations
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A university research scheduler briefly enabled multiple revisions for every deployment. Students kept reaching old booking behavior because a test label and traffic weight were left behind.
🎯Business/Technical Objectives
Return routine deployments to predictable latest-version behavior.
Eliminate stale revision exposure for student-facing scheduling.
Keep rollback possible through inactive revision retention.
Document when multiple mode is allowed for experiments.
✅Solution Using Revision mode
The cloud team reviewed Revision mode and decided the scheduler did not need side-by-side active versions for normal releases. They set the app back to single mode, removed obsolete labels, and deactivated old active revisions after confirming no traffic remained. Pipelines were updated to assert single mode before routine deployments and to require approval before switching to multiple mode for experiments. Operators still listed inactive revisions before cleanup so a known-good rollback target remained available during release windows. Support leaders received a change calendar.
📈Results & Business Impact
Student reports of inconsistent booking behavior dropped from 38 tickets to 3 in the next term.
Active revision count returned to one after each routine deployment.
Minimum-replica spend fell by about 22 percent for the scheduler app.
Release notes now record the approved exception when multiple mode is used.
💡Key Takeaway for Glossary Readers
The right revision mode is not always the most flexible one; predictable single-mode behavior can be safer for simple services.
Why use Azure CLI for this?
I prefer Azure CLI for revision mode because it makes release behavior explicit and automatable. The portal is fine for a quick view, but CLI can show the current activeRevisionMode, set the mode, list revisions, inspect traffic weights, and export evidence before a production cutover. In mature environments, this belongs in pipelines and change records, not memory. CLI also helps compare dev, staging, and production so teams do not accidentally test multiple-revision blue-green flows in one environment while production remains in single mode. That mismatch is a classic release-night surprise. before, during, and after each controlled release. with auditable evidence.
CLI use cases
Show the container app configuration to confirm the current revision mode before deployment.
Set revision mode to multiple before applying traffic weights or labels for a staged rollout.
List active revisions after a mode change to verify the expected versions are available.
Inspect traffic weights so production users are not accidentally routed to an old revision.
Return to single mode or deactivate old revisions after canary or blue-green validation completes.
Check whether mode changes, traffic changes, or deactivation commands are allowed in the current change window.
Verify labels, traffic weights, minimum replicas, private endpoints, managed identity, and output format before altering production behavior.
Know the rollback command and which revision should receive traffic if the mode change causes confusion.
What output tells you
Container app show output reveals the active revision mode and whether multiple active revisions are allowed.
Revision list output shows which revisions are active, inactive, labeled, or available as rollback targets.
Ingress traffic output proves how much user traffic each active revision or label is receiving.
Activity and deployment output helps correlate a mode change with release timing, cost changes, or an incident.
Mapped Azure CLI commands
Revision mode Azure CLI commands
operational
az containerapp show --name <container-app> --resource-group <resource-group> --query properties.configuration.activeRevisionMode
az containerappdiscoverContainers
az containerapp revision set-mode --name <container-app> --resource-group <resource-group> --mode multiple
az containerapp revisionoperateContainers
az containerapp revision list --name <container-app> --resource-group <resource-group> -o table
az containerapp revisiondiscoverContainers
az containerapp ingress traffic show --name <container-app> --resource-group <resource-group>
az containerapp ingress trafficdiscoverContainers
az containerapp ingress traffic set --name <container-app> --resource-group <resource-group> --revision-weight <revision>=100
az containerapp ingress trafficconfigureContainers
Architecture context
Architecturally, revision mode is the switch that defines whether Azure Container Apps behaves like an automatic rolling service or a traffic-managed release platform. Single mode suits straightforward services where the latest healthy revision should take all traffic and old active revisions should deprovision. Multiple mode suits services that need side-by-side active versions, labels, canary percentages, blue-green validation, or manual rollback windows. Architects should design mode choice with ingress, health probes, minimum replicas, observability, deployment pipeline steps, cost windows, and rollback policy. The wrong mode can turn a safe release plan into confusion. across environments and teams. and deployment regions.
Security
Security impact is indirect but important. Revision mode does not grant permissions or encrypt data, but it controls whether older code and configuration can remain active. In multiple mode, an old revision with vulnerable code, outdated dependencies, or obsolete secrets may continue receiving traffic if weights or labels are wrong. Labels can expose revision-specific URLs for testing, so access expectations must be clear. Restrict who can change revision mode, traffic weights, and labels. Audit image provenance, secret updates, ingress exposure, managed identities, and role assignments before allowing several revisions to run side by side. before release approval. during security audits.
Cost
Revision mode affects cost through active replicas and release duration. In single mode, the old active revision is deprovisioned after the new one becomes ready, so steady-state cost is usually easier to predict. In multiple mode, several revisions can run at once, and each may keep minimum replicas, consume workload profile capacity, emit logs, and handle traffic. That is worth it for controlled releases, but expensive if teams forget to deactivate old revisions after testing. FinOps owners should track active revision count, traffic weights, replica minimums, workload profile capacity, logging volume, and how long blue-green or canary windows remain open.
Reliability
Reliability impact is direct. Single mode supports zero-downtime style replacement by keeping the old revision active until the new revision is ready, then routing all traffic to the new version. Multiple mode improves release resilience when teams need canary, blue-green, or manual rollback, but it also introduces traffic-split mistakes and stale revision risk. Reliable operations require checking active revisions, readiness probes, traffic weights, labels, replica counts, and rollback targets before and after mode changes. Do not switch modes casually during an incident; know which revision is healthy, which is serving users, and how to restore the prior behavior. safely. during incidents.
Performance
Performance impact comes from how traffic is distributed across versions. Single mode gives one active runtime path after cutover, which makes metrics easier to interpret. Multiple mode allows direct comparison between revisions, but only if traffic weights, labels, and monitoring dimensions are clear. A slower canary can be hidden by app-level averages if most traffic still goes to the old revision. Active parallel revisions can also compete for workload profile capacity. Measure latency, error rate, scale-out time, cold starts, CPU, memory, and request volume by revision before moving traffic or declaring a mode change successful. during staged rollouts. under load.
Operations
Operators use revision mode during release planning and incident response. They confirm whether the app is in single or multiple mode, list active revisions, check traffic weights, assign or move labels, and decide when to deactivate old revisions. Pipelines should assert the expected mode before deployment, because traffic commands behave differently when only one revision can be active. Runbooks should explain when multiple mode is allowed, who approves it, how long parallel revisions may run, and how to return to a simpler state after cutover. Monitoring must separate revision health from overall app health during staged releases. after each release.
Common mistakes
Trying to set traffic weights while the app is still in single revision mode.
Leaving multiple revisions active after testing and paying for extra minimum replicas and logs.
Routing users to an old labeled revision because labels were not moved during cutover.
Changing revision mode during an incident without confirming which revision is healthy and serving traffic.