What creates a new revision, and how single and multiple revision modes change deployments.
From Ultra Transcenders AI-200 by Tony Rough (publishing soon)
Revisions are how Container Apps versions, deploys and rolls back an app, and knowing which changes create one explains most deployment behaviour.
A revision is an immutable snapshot of a version of the app. The first deployment creates the initial revision automatically. Container Apps keeps up to 100 inactive revisions by default and purges the oldest beyond that; inactive revisions aren’t charged. The --max-inactive-revisions parameter (preview) changes the limit.
| Change type | Template section | Creates a revision? | Examples |
|---|---|---|---|
| Revision-scope | properties.template |
Yes | Container image, container configuration (environment variables, CPU and memory, probes), scale rules, revision suffix |
| Application-scope | properties.configuration |
No; applies to all revisions | Secret values, revision mode, ingress (on/off, traffic splitting, labels), registry credentials, Dapr settings |
Managed identity changes also don’t create a revision.
Common trap: Expecting a change of revision mode, traffic weights or ingress to produce a new revision to roll back to - these are application-scope changes in
properties.configuration; onlyproperties.templatechanges create revisions.
| Mode | Behaviour | Default |
|---|---|---|
| Single | One active revision. A new revision is provisioned, activated and scaled; traffic switches when it is ready; old revisions are deprovisioned automatically. If the update fails, traffic stays on the old revision | Yes |
| Multiple | Several active revisions; you split traffic and decide when to deactivate old ones | No |
| Deployment labels (preview) | Named labels such as dev, staging and prod assigned to revisions, for traffic splitting, swapping and rollback | No |
Set the mode with az containerapp revision set-mode --mode single|multiple; changing the mode doesn’t create a revision.
Zero downtime in single revision mode. The existing revision keeps 100% of traffic until the new revision is ready, meaning it has provisioned, scaled to match the previous revision’s replica count (within its own min and max), and all replicas have passed startup and readiness probes. In multiple revision mode, a traffic rule with latestRevision: true also waits for readiness.
| Phase | Statuses |
|---|---|
| Provisioning | Provisioning, Provisioned, Provisioning failed |
| Running | Scale to 0, Activating, Activation failed, Scaling / Processing, Running, Running (at max), Deprovisioning, Degraded, Failed |
| Inactive | No provisioning or running state; can be reactivated |
The revisions page documents the name format as <CONTAINER_APP_NAME>-<REVISION_SUFFIX>; platform-generated names shown elsewhere on Learn use a double dash, such as my-containerapp--20mh1s9. Suffixes are generated automatically unless you set one in the ARM template, with az containerapp create or update, or in the portal when creating a revision. A custom suffix must be lower-case alphanumerics or dashes, start with a letter, end with an alphanumeric, have no --, and be at most 64 characters.
| Task | Command |
|---|---|
| Deploy a new image or settings | az containerapp update --image ... |
| List or show revisions | az containerapp revision list / show |
| New revision from an existing one | az containerapp revision copy |
| Activate or deactivate | az containerapp revision activate / deactivate (deactivation stops all replicas) |
| Restart (for example after a secret change) | az containerapp revision restart |
This note is one section of Ultra Transcenders AI-200: Developing AI Cloud Solutions on Azure, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Publishing soon on Amazon in Kindle and paperback editions.
About the book · AI-200 terms in the glossary · All AI-200 study notes
The five Cosmos DB consistency levels, their RU and latency trade-offs, and when to choose each.
How to tell commands, discrete events and telemetry streams apart and pick the right Azure messaging service.
How to define KEDA scalers for queues, topics and other event sources in Container Apps.
Exact search versus approximate IVFFlat, HNSW and DiskANN indexes, and how to tune each for recall and latency.
The main Redis caching patterns, how to expire and invalidate entries, and the trade-offs of each.
How the Functions hosting plans differ in scaling, networking and cold start, and which to choose.
Control plane versus data plane, Azure RBAC versus vault access policies, and the roles apps need.