Deploying Azure Container Apps With Traffic Splits Between Revisions

Deploying a new application version does not always mean sending every user to it immediately. A new release may introduce a performance issue, an unexpected error, or a behavior that only appears under real production traffic. If all requests reach the new version at once, identifying and fixing the problem can become difficult.

Azure Container Apps supports revision-based deployments that let teams run multiple versions of an application and control how traffic is distributed between them. This makes it possible to test a new revision with a small percentage of requests before moving all traffic to it.

For example, an application might send 90% of requests to the current revision and 10% to the new revision. If the new version behaves correctly, the team can gradually increase its traffic share. If errors increase, traffic can be redirected to the stable revision.

This approach is useful for applications that need controlled releases without immediately replacing the version currently serving users.

Understanding Revisions in Azure Container Apps

A revision is an immutable snapshot of an application version in Azure Container Apps. It represents a particular configuration and container image. When a change creates a new revision, the previous revision remains available according to the application's revision and lifecycle settings.

A revision can contain changes such as:

A new container image.
Updated environment variables.
Changes to resource limits.
Modified container settings.
Changes to the application's configuration.

Azure Container Apps supports two revision modes: single and multiple.

Feature	Single revision mode	Multiple revision mode
Active revisions	The platform manages the active revision transition	Multiple revisions can remain active
Traffic splitting	Not intended for manually distributing traffic across active revisions	Supports assigning traffic weights to revisions
Rollback approach	Reactivate or redeploy a suitable version, depending on configuration	Redirect traffic to a previous active revision
Typical use	Applications that should move to one active version	Controlled rollouts, testing, and canary releases

If you want to split traffic between revisions, configure the container app to use multiple revision mode.

Traffic percentages control how Azure Container Apps distributes incoming requests among the configured revisions. They do not guarantee that a particular percentage of unique users will experience each version. A user may make several requests, and each request can be routed according to the platform's traffic distribution behavior.

Configuring Multiple Revision Mode

Before configuring a rollout, make sure the Azure CLI is installed and authenticated, and that you have access to the relevant resource group and container app.

Set variables for the application you want to update:

RESOURCE_GROUP="my-resource-group"
CONTAINER_APP="orders-api"

Enable multiple revision mode:

az containerapp revision set-mode \
  --name "$CONTAINER_APP" \
  --resource-group "$RESOURCE_GROUP" \
  --mode multiple

This allows multiple revisions to remain active so you can assign traffic to each one.

You can inspect the existing revisions with:

az containerapp revision list \
  --name "$CONTAINER_APP" \
  --resource-group "$RESOURCE_GROUP" \
  --output table

Review the revision names and their provisioning and running status before making changes. A revision that exists but is not ready to serve requests should not receive production traffic.

Deploying a New Revision

Suppose the current application version is stable, and you want to deploy an updated container image.

The following command updates the container image:

az containerapp update \
  --name "$CONTAINER_APP" \
  --resource-group "$RESOURCE_GROUP" \
  --image "myregistry.azurecr.io/orders-api:v2"

Use an image tag that identifies the intended release. In production, an immutable image reference or digest can make it easier to identify exactly which build is running.

After deployment, list the revisions again:

az containerapp revision list \
  --name "$CONTAINER_APP" \
  --resource-group "$RESOURCE_GROUP" \
  --output table

Identify the new revision and confirm that it has completed provisioning and is ready to receive traffic. Revision names are generated by the platform, so do not assume a fixed suffix or name.

You can also inspect a specific revision:

az containerapp revision show \
  --name "$CONTAINER_APP" \
  --resource-group "$RESOURCE_GROUP" \
  --revision "orders-api--newrevision"

Replace the example revision name with the actual name returned by the revision list.

Before changing traffic weights, verify that the new revision starts correctly, can connect to required dependencies, and passes any application-level health checks available in your environment.

Splitting Traffic Between Revisions

Once both the stable and new revisions are active, you can assign traffic weights.

Assume the existing revision is named orders-api--stable and the new revision is named orders-api--candidate. The names below are examples; use the actual revision names from your application.

Start by sending most traffic to the stable revision:

az containerapp ingress traffic set \
  --name "$CONTAINER_APP" \
  --resource-group "$RESOURCE_GROUP" \
  --revision-weight orders-api--stable=90 orders-api--candidate=10

This configuration assigns 90% of the traffic to the stable revision and 10% to the candidate revision.

The traffic weights should total 100 for a configuration that distributes all traffic across the listed revisions. Confirm the resulting configuration after applying changes.

To inspect the current traffic settings, run:

az containerapp ingress traffic show \
  --name "$CONTAINER_APP" \
  --resource-group "$RESOURCE_GROUP"

If your installed Azure CLI version exposes the traffic configuration through a different command output format, inspect the command's help and the current container app configuration before making further changes.

A gradual rollout might use the following sequence:

Rollout stage	Stable revision	Candidate revision	Purpose
Initial deployment	100%	0%	Keep the candidate out of production traffic
First test	90%	10%	Check behavior under limited traffic
Wider rollout	50%	50%	Increase exposure after initial validation
Final rollout	0%	100%	Send traffic to the new version

The percentages are examples, not mandatory values. Choose rollout stages based on application risk, traffic volume, and the time needed to collect meaningful monitoring data.

A low-traffic application may not generate enough requests to evaluate a 10% rollout quickly. A high-traffic application may produce useful signals within a shorter period, but it still needs enough time to capture relevant workflows and background activity.

Monitoring the New Revision

Traffic splitting reduces the risk of a release, but it does not automatically determine whether the new revision is healthy. You must monitor application behavior while the candidate receives traffic.

Useful signals include:

HTTP 5xx error rate.
Request latency, especially the 95th and 99th percentiles.
Container restarts and failed starts.
CPU and memory consumption.
Dependency failures, such as database timeouts.
Business-level indicators, such as failed orders or incomplete transactions.

Azure Monitor and Log Analytics can help you investigate application logs and platform telemetry when diagnostic settings and logging are configured.

For example, if the new revision introduces a database query that performs poorly under concurrent load, its error rate might remain normal while its latency increases. Monitoring only successful responses would miss that regression.

Compare the candidate revision with the stable revision wherever the available telemetry allows it. The comparison should use the same time window and account for differences in traffic volume.

A practical release process might look like this:

Deploy the candidate revision.
Confirm that the revision is ready.
Assign a small traffic percentage.
Observe errors, latency, and resource usage.
Test important user journeys.
Increase the traffic percentage if the results remain acceptable.
Complete the rollout or return traffic to the stable revision.

For critical systems, define acceptable error and latency thresholds before deployment. This avoids making rollout decisions based only on subjective impressions.

Rolling Back a Problematic Revision

Suppose the candidate revision begins producing elevated errors after receiving 10% of production traffic. If the stable revision is still active, you can direct all traffic back to it.

az containerapp ingress traffic set \
  --name "$CONTAINER_APP" \
  --resource-group "$RESOURCE_GROUP" \
  --revision-weight orders-api--stable=100 orders-api--candidate=0

Confirm the resulting traffic configuration and monitor the application to verify that the problem has stopped affecting new requests.

Setting a revision's traffic weight to zero removes its share of routed traffic, but it does not necessarily delete the revision. This is useful when you need to investigate the failed release or deploy a corrected version.

Rollback also has limits. Requests already in progress may not be undone, and changes made to external systems are not automatically reversed. For example, if the candidate applied an incompatible database migration, redirecting traffic to the previous application version may not restore compatibility.

For this reason, database changes should generally follow an expand-and-contract strategy: introduce backward-compatible schema changes first, deploy code that supports the transition, and remove obsolete schema elements only after the older application versions are no longer needed.

Common Mistakes to Avoid

Using Single Revision Mode for Traffic Splitting

Single revision mode does not provide the same manual traffic-splitting workflow as multiple revision mode. If you need to keep a stable revision active while gradually exposing a candidate, configure multiple revision mode.

Assigning Traffic Before the Revision Is Ready

A successful deployment command does not prove that the application can handle requests. Check provisioning status, startup behavior, health checks, and dependency connectivity before increasing traffic.

Using Mutable Container Image Tags

If a tag such as latest points to different image contents over time, it becomes harder to determine which build a revision uses. Prefer unique release tags or image digests and retain build metadata for troubleshooting.

Increasing Traffic Too Quickly

Moving directly from 10% to 100% leaves little opportunity to detect problems that appear only under higher load. Use staged increases when the risk justifies them.

Deleting the Previous Revision Too Early

Keep the stable revision available until the new release has passed its observation period and the rollback plan is no longer required. Removing it too early can complicate recovery.

Treating Traffic Percentages as User Assignments

A traffic weight is not the same as a persistent user-level experiment assignment. If you need the same user to remain on the same version across multiple requests, design and test that behavior explicitly rather than assuming traffic weights provide session affinity.

Best Practices for Production Deployments

Use the following practices to make revision-based deployments more predictable:

Keep a known-good revision available during the rollout.
Use immutable container image references where practical.
Verify that health checks reflect actual application readiness.
Define error-rate and latency thresholds before deploying.
Increase traffic gradually when the application's risk profile requires it.
Monitor the candidate and stable revisions separately when possible.
Keep application configuration and database changes compatible with both versions during the transition.
Automate traffic changes only after defining clear success and rollback conditions.
Test the rollback procedure before relying on it during an incident.
Record the image version, revision name, deployment time, and rollout decision for later investigation.

Traffic splitting should be part of a broader release process. It does not replace integration testing, load testing, access control, or a reliable observability setup.

Advantages and Limitations

Revision-based traffic splitting provides several advantages. It reduces the initial exposure of a new release, supports gradual production validation, and makes it possible to return traffic to a stable version without immediately rebuilding the application.

It also introduces operational responsibilities. Teams must manage revision names, traffic weights, monitoring, and cleanup. A rollout can appear healthy at low traffic levels but fail under higher concurrency. Furthermore, traffic splitting does not automatically provide user-level A/B testing or reverse incompatible database changes.

The approach works best when the application is observable, revisions can run side by side, and the deployment process has clear promotion and rollback criteria.

Summary

Azure Container Apps revisions provide a practical way to manage application releases without immediately routing all requests to a new version. By enabling multiple revision mode, deploying a candidate, assigning traffic weights, and monitoring its behavior, teams can reduce the risk of production changes.

The key is to treat traffic splitting as a controlled release process rather than simply a configuration change. Verify revision readiness, compare real application signals, increase exposure gradually, and keep a tested rollback path available. These steps make deployments easier to evaluate and safer to operate.