A Container Apps revision is a saved version of a container app deployment. It captures the revision-level configuration, such as image, command, environment variables, scale rules, and some ingress behavior, so Azure can run, compare, deactivate, or route traffic to that version. Think of it as the release unit for Container Apps. The app name can stay stable while revisions change behind it, which lets teams test a new image, split traffic, roll back quickly, and keep evidence of what served users during an incident.
Microsoft Learn explains that a Container Apps revision is created at first deployment and whenever revision-scope settings change. Revision mode controls whether one or multiple revisions stay active, enabling traffic splitting, labels, rollbacks, and safer updates without changing the whole container app resource. in controlled production releases.
Technically, a revision belongs to a specific Container Apps app inside a Container App environment. Azure creates revisions when you deploy the app or update revision-scope properties. The revision has its own name, running state, provisioning state, replica behavior, labels, traffic weights, and log stream context. App-scope settings such as secrets can be referenced by revisions, but secret updates do not automatically rewrite old revision definitions. Revisions interact with ingress, KEDA scale rules, Dapr configuration, managed identity, registry pulls, and release automation.
Why it matters
Container Apps revisions matter because they turn deployment into controlled traffic management instead of a blind replacement. Without revision discipline, teams cannot prove which image was live, which configuration broke a dependency, or how to roll back without building another release. Multiple revision mode supports canary and blue-green patterns, while single revision mode keeps simpler apps moving with automatic replacement. Revisions also protect operators during incidents because the failed release can be isolated, logged, compared, and deactivated. For business teams, this reduces release anxiety, failed launches, and customer-visible downtime when container changes behave differently under real load. It also keeps release evidence tied to customer impact.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Container Apps revision blade, you see revision names, active state, provisioning state, labels, replicas, images, and traffic weights during rollout review. during release reviews.
Signal 02
In az containerapp revision list output, revision mode, creation time, running status, and latest revision markers help identify the version serving traffic. during release reviews.
Signal 03
In deployment pipelines and logs, revision suffixes connect image digests, configuration changes, traffic splits, and rollback actions to a specific release. during release and incident reviews.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Roll back a broken container image by shifting traffic to the previous active revision instead of rebuilding under pressure.
Run canary or blue-green releases by sending a small percentage of traffic to a new revision before promotion.
Keep partner validation or compliance testing on a labeled revision while production users remain on a stable version.
Compare latency, error rate, and dependency behavior between two revisions during a controlled release window.
Deactivate vulnerable or stale revisions after confirming no traffic, jobs, or labels still depend on them.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Ticketing platform rolls back payment API
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Contoso Events deployed a new payment authorization API to Container Apps two hours before a major ticket sale. Early users saw intermittent checkout failures tied to a new dependency timeout.
🎯Business/Technical Objectives
Limit exposure of the new payment image during the sale.
Rollback in less than five minutes if authorization errors doubled.
Preserve logs showing which release served each failed request.
Avoid redeploying code while customer traffic was peaking.
✅Solution Using Container Apps revision
The team used multiple revision mode and deployed the new image as a separate Container Apps revision with a descriptive suffix and label. Traffic started at 5 percent while Application Insights dashboards compared authorization latency, dependency failures, and checkout completion rate by revision. When gateway timeouts increased, the release captain used Azure CLI to move traffic back to the previous stable revision and left the failed revision active only for diagnostic review. The incident record captured revision names, image digests, traffic weights before and after rollback, and the dependency error query. After vendor confirmation, the failed revision was deactivated and a corrected image was deployed as a new revision the next morning.
📈Results & Business Impact
Rollback finished in three minutes and eighteen seconds after the alert fired.
Failed checkout attempts were contained to 4.7 percent of traffic during the canary.
No emergency rebuild was needed during the sale window.
Post-incident review identified the exact revision responsible for 100 percent of observed failures.
💡Key Takeaway for Glossary Readers
Container Apps revisions turn a bad release into a traffic-routing decision instead of a frantic rebuild.
Case study 02
Logistics fleet tests routing algorithm
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A logistics company wanted to test a new delivery-routing algorithm for one region without changing the stable API used by dispatchers nationwide.
🎯Business/Technical Objectives
Expose the new algorithm to a controlled share of regional API traffic.
Compare route calculation latency between old and new versions.
Keep dispatchers on the stable revision if driver arrival predictions degraded.
Document promotion criteria for the platform and data science teams.
✅Solution Using Container Apps revision
Engineers deployed the new routing container as a labeled revision and kept the current production revision active. The application used request metadata to measure candidate revision performance for regional traffic while the platform team managed traffic weights in Container Apps. Azure CLI checks ran after every pipeline stage to confirm active revisions, labels, image digests, and traffic distribution. Data scientists reviewed route accuracy, while operators watched replica readiness, CPU usage, and request latency by revision. When metrics stayed within the agreed tolerance for two business days, traffic moved from 10 percent to 50 percent and then to full promotion. The older revision remained inactive for the rollback retention window.
📈Results & Business Impact
Average route calculation latency improved 22 percent for the tested region.
Driver arrival prediction variance stayed within the approved 3 percent threshold.
Traffic promotion required no DNS change, endpoint change, or customer communication.
Release evidence satisfied both operations and data science approval gates.
💡Key Takeaway for Glossary Readers
A revision gives teams a safe way to validate behavior changes under real traffic while the application endpoint stays stable.
Case study 03
Education portal manages semester launch
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A university learning portal expected a traffic surge on registration day and needed to launch a redesigned course-search service without risking the enrollment window.
🎯Business/Technical Objectives
Warm the new service version before student traffic arrived.
Keep the previous revision available throughout registration week.
Confirm search latency and error rate by revision before promotion.
Reduce manual release coordination between developers and operators.
✅Solution Using Container Apps revision
The platform team configured multiple revision mode and deployed the redesigned search service as a candidate revision several days before launch. Operators used CLI commands to list revisions, verify the candidate was running, and confirm scale rules matched the expected search volume. Synthetic requests and staff-only traffic were routed to the candidate label first. Dashboards compared search latency, failed queries, and container restart counts between revisions. On launch morning, traffic moved in planned steps, with rollback commands already written in the change record. The stable revision remained available for the full registration period, then was deactivated after logs showed the new revision handled peak traffic cleanly.
📈Results & Business Impact
Peak course-search latency stayed under 420 milliseconds during registration.
Manual release coordination calls dropped from four handoffs to one approval checkpoint.
No student-facing rollback was required during the launch week.
The previous revision remained ready for seven days and was removed after evidence review.
💡Key Takeaway for Glossary Readers
Revision planning gives high-pressure launches a measured promotion path and a credible fallback.
Why use Azure CLI for this?
As an Azure engineer, I use Azure CLI for revisions because release mistakes often hide in small differences between active revisions. The portal is fine for a quick look, but CLI output gives exact revision names, active states, labels, traffic percentages, image references, and provisioning details that can be pasted into change records. It is also safer for automation: pipelines can list revisions, confirm the expected revision is ready, move traffic gradually, and deactivate stale revisions after evidence is captured. During incidents, CLI commands remove guesswork by showing what is actually receiving traffic right now. That evidence makes promotion, rollback, and incident review dependable.
CLI use cases
List revisions and identify which revision is active, latest, labeled, or still receiving production traffic.
Show a specific revision to confirm image, provisioning state, replica readiness, labels, and traffic-related settings.
Set revision mode before a release that requires either simple replacement or multiple active versions.
Move traffic to a stable revision during rollback and capture the exact command in the incident record.
Deactivate stale revisions after retention review so old images and configuration no longer stay runnable.
Before you run CLI
Confirm tenant, subscription, resource group, app name, environment, and revision mode before changing production traffic.
Verify permissions for Container Apps updates because traffic and revision changes can affect live users immediately.
Check whether the app uses labels or direct revision names so rollback commands target the intended release.
Review active connections, scheduled releases, and monitoring thresholds before splitting or moving traffic.
Use JSON output for evidence when comparing image digests, provisioning state, and traffic weights across revisions.
What output tells you
Revision names and suffixes identify the exact release unit behind a stable container app name.
Active, inactive, running, and provisioning fields reveal whether a revision can serve traffic safely.
Traffic weight and label fields show how user requests are distributed across active revisions.
Image and template details help compare what changed between the stable release and the candidate release.
Timestamps and replica status support audit evidence, incident timelines, and cleanup decisions after deployment.
Mapped Azure CLI commands
Container Apps revision CLI commands
direct
az containerapp revision list --name <app-name> --resource-group <resource-group> --output table
az containerapp revisiondiscoverContainers
az containerapp revision show --name <app-name> --resource-group <resource-group> --revision <revision-name>
az containerapp revisiondiscoverContainers
az containerapp revision set-mode --name <app-name> --resource-group <resource-group> --mode multiple
az containerapp revisionoperateContainers
az containerapp ingress traffic set --name <app-name> --resource-group <resource-group> --revision-weight <revision-name>=100
az containerapp ingress trafficconfigureContainers
az containerapp revision deactivate --name <app-name> --resource-group <resource-group> --revision <revision-name>
az containerapp revisionoperateContainers
Architecture context
In architecture terms, a Container Apps revision is the point where platform design meets release engineering. I use revisions to separate app identity from deployed version, which lets DNS, custom domains, identities, and environment placement remain stable while traffic moves between versions. The design choice is whether one active revision is enough or whether the workload needs multiple active revisions for canary, A/B testing, delayed rollback, or partner validation. Architects should define traffic movement, inactive retention, label conventions, telemetry comparison, and rollback authority before the first production release, not after the first bad image ships. Make the revision strategy explicit in pipelines, dashboards, and rollback runbooks.
Security
Security for revisions focuses on every active revision, not only the newest one. Older revisions can still contain vulnerable images, stale secret references, broad environment variables, public ingress behavior, or over-permissive identities. Teams should check image digests, registry provenance, managed identity access, secret references, labels, traffic weights, and revision retention. Deactivating a vulnerable revision is often as important as deploying a fixed one. Strong RBAC is also needed because anyone who can shift traffic or activate an old revision can change production exposure without touching source code. Review old active revisions because forgotten traffic can preserve vulnerable images or risky settings.
Cost
Revision cost comes from running more than one version at the same time. Multiple active revisions can duplicate minimum replicas, telemetry, queue consumers, outbound calls, and dependency usage during canary windows. Inactive revisions mainly create operational clutter, but stale active revisions can generate real compute and observability charges. Costs also rise when failed revisions trigger retries, scale out unnecessarily, or keep expensive workload profiles warm. FinOps reviews should tie traffic splits, minimum replica settings, revision retention, and log volume to release policy so safer deployment does not become uncontrolled parallel capacity. Clean up active revisions because idle replicas, logs, and scale rules still cost money.
Reliability
Reliability is the main reason to understand revisions. A healthy revision gives operators a rollback target, a canary destination, and a known-good baseline during incidents. Reliability falls apart when teams delete inactive revisions too quickly, skip readiness checks, route traffic before dependencies are ready, or forget that different revisions may scale differently. Monitor provisioning status, replica readiness, HTTP errors, latency, queue depth, and dependency failures by revision. A rollback plan should identify the exact revision, label, traffic command, owner approval, and post-rollback evidence before production changes begin. Test rollback commands before releases so operators do not improvise during customer outages later.
Performance
Performance depends on which revision receives traffic and whether it is ready for the workload shape. A new revision may use a larger image, slower startup path, different environment variables, changed scale rules, or a dependency version that behaves differently. Traffic splitting helps compare latency and errors before full promotion, but only if metrics are sliced by revision. Operators should watch cold start time, replica readiness, request latency, CPU and memory, scale-out behavior, and queue backlog. Revisions make performance troubleshooting sharper because the old and new versions can be measured side by side. Compare metrics by revision or slow canaries disappear inside app-wide averages.
Operations
Operations teams use revisions to inspect release history, compare traffic routing, capture incident evidence, and clean up stale runtime versions. A practical runbook lists active revisions, latest revision state, labels, image tags or digests, traffic percentages, scale settings, and diagnostic queries. Operators should document whether the app uses single or multiple revision mode and who can change it. After releases, teams should deactivate old revisions based on retention policy, not habit. Good revision operations make release reviews factual instead of dependent on pipeline names or developer memory. Record revision ownership so support teams know which release, image, and commit changed.
Common mistakes
Assuming every configuration change creates a new revision, even when the setting is app-scoped rather than revision-scoped.
Routing traffic to a revision before readiness, dependency authentication, and application health checks are verified.
Keeping too many active revisions with minimum replicas and then blaming the environment for unexpected cost.
Deleting or deactivating the last known-good revision before the new release has completed a stable soak period.
Using mutable image tags without recording image digests, making later revision comparison and incident review unreliable.