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 shut down.

Note

Azure Container Apps jobs don't support revisions. Jobs are deployed and updated directly.

Deployment

When you deploy a container app, you automatically create the first revision.

Azure Container Apps: Deployment phase

Update

When you update a container app with a revision scope-change, you create a new revision. 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

When you use single revision mode, Container Apps automatically switches between revisions to support zero downtime deployment.

Deactivate

When you no longer need a revision, you can deactivate it and reactivate it later if needed. During deactivation, the containers in the revision are shut down.

Azure Container Apps: Deactivation phase

Shutdown

The containers shut down in the following situations:

  • When a container app scales in
  • When a container app is deleted
  • When a revision is 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 doesn't respond within 30 seconds to the SIGTERM message, then SIGKILL terminates your container.

Make sure your application can gracefully handle shutdowns. Containers restart regularly, so don't expect state to persist inside a container. Instead, use external caches for expensive in-memory cache requirements.

Next steps