Application lifecycle management in Azure Container Apps

The Azure Container Apps application lifecycle revolves around revisions.

When you deploy a container app, the first revision is automatically created. More revisions are created as containers change, or any adjustments are made to the template section of the configuration.

A container app flows through four phases: deployment, update, deactivation, and shutdown.


As a container app is deployed, the first revision is automatically created.

Azure Container Apps: Deployment phase


As a container app is updated with a revision scope-change, a new revision is created. You can choose whether to automatically deactivate old revisions (single revision mode), or allow them to remain available (multiple revision mode).

Azure Container Apps: Update phase

Zero downtime deployment

In single revision mode, Container Apps automatically ensures your app does not experience downtime when creating new a revision. The existing active revision is not deactivated until the new revision is ready. If ingress is enabled, the existing revision will continue to receive 100% of the traffic until the new revision is ready.


A new revision is considered ready when one of its replicas starts and becomes ready. A replica is ready when all of its containers start and pass their startup and readiness probes.

In multiple revision mode, you control when revisions are activated or deactivated and which revisions receive ingress traffic. If a traffic splitting rule is configured with latestRevision set to true, traffic does not switch to the latest revision until it is ready.


Once a revision is no longer needed, you can deactivate a revision with the option to reactivate later. During deactivation, containers in the revision are shut down.

Azure Container Apps: Deactivation phase


The containers are shut down in the following situations:

  • As a container app scales in
  • As a container app is being deleted
  • As a revision is being deactivated

When a shutdown is initiated, the container host sends a SIGTERM message to your container. The code implemented in the container can respond to this operating system-level message to handle termination.

If your application does not respond within 30 seconds to the SIGTERM message, then SIGKILL terminates your container.

Next steps