Deployment Technologies¶

Azure Container Apps uses a revision-based deployment model where every meaningful change creates an immutable snapshot of your application. This page explains the available deployment methods, what triggers new revisions, and how deployments behave at the platform level.

Deployment Methods¶

Container Apps supports multiple deployment paths. Each method ultimately creates or updates a revision.

flowchart LR
    subgraph Sources["Deployment Source"]
        A[Source Code]
        B[Container Image]
        C[Artifact JAR/WAR]
    end

    subgraph Methods["Deployment Method"]
        D["az containerapp up<br/>--source"]
        E["az containerapp update<br/>--image"]
        F["az containerapp up<br/>--artifact"]
        G[Bicep / ARM]
        H[GitHub Actions]
    end

    subgraph Target["Container Apps Platform"]
        I[New Revision Created]
    end

    A --> D --> I
    B --> E --> I
    C --> F --> I
    B --> G --> I
    B --> H --> I

Method Comparison¶

Source Code Deployment¶

Deploy directly from application source code without pre-building a container image. The platform uses Buildpacks to create the image automatically.

az containerapp up \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --environment "$ACA_ENV_NAME" \
    --source "./apps/python"

The platform:

1. Detects the language runtime from project files
2. Builds a container image using cloud buildpacks
3. Pushes the image to a managed or specified ACR
4. Creates a new revision with the built image

Artifact Deployment¶

Deploy Java applications (JAR or WAR) without writing a Dockerfile. The platform generates a container image from the artifact.

az containerapp up \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --environment "$ACA_ENV_NAME" \
    --artifact ./target/app.jar \
    --ingress external \
    --target-port 8080

This command:

• Creates an ACR if none exists
• Builds a container image from the artifact
• Pushes the image to the registry
• Creates or updates the Container App with a new revision

Container Image Deployment¶

The standard production deployment method. Build your image externally, push to a registry, and update the app.

# Build and push to ACR
az acr build \
    --registry "$ACR_NAME" \
    --image "$APP_NAME:git-$(git rev-parse --short HEAD)" \
    --file "apps/python/Dockerfile" \
    "apps/python"

# Update app to create new revision
az containerapp update \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --image "$ACR_NAME.azurecr.io/$APP_NAME:git-$(git rev-parse --short HEAD)"

Change Types¶

Changes to a Container App fall into two categories that determine whether a new revision is created.

flowchart TD
    A[Configuration Change] --> B{Change Scope?}
    B -->|Revision-scope| C[New Revision Created]
    B -->|Application-scope| D[Applied to All Revisions]
    C --> E[Traffic Routing Decision]
    D --> F[No New Revision]

Revision-Scope Changes¶

These changes create a new revision. They are defined in the properties.template section of the resource.

Application-Scope Changes¶

These changes apply globally to all revisions without creating a new one. They are defined in the properties.configuration section.

Zero-Downtime Deployment¶

Container Apps ensures zero-downtime in single revision mode through a controlled cutover process.

How it works:

1. New revision is provisioned and starts health checks
2. New revision scales up to match the previous revision's replica count (respecting min/max)
3. All replicas pass startup and readiness probes
4. Traffic shifts from old revision to new revision
5. Old revision is automatically deactivated

The existing revision continues to receive 100% of traffic until the new revision is fully ready.

In multiple revision mode with latestRevision set to true in traffic splitting rules, traffic also waits for the new revision to become ready before shifting.

Deployment Labels (Preview)¶

Labels assign meaningful names to specific revisions, providing dedicated URLs for routing.

# Assign a label to a revision
az containerapp revision label add \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --revision "$APP_NAME--v2" \
    --label staging

Common label patterns:

• staging — Route QA traffic to a candidate revision
• canary — Small percentage of real traffic for validation
• previous — Quick access to the last known-good revision

A label name must consist of lowercase alphanumeric characters or dashes, start with an alphabetic character, end with an alphanumeric character, and be at most 64 characters.

Inactive Revision Management¶

By default, Container Apps retains up to 100 inactive revisions. You can adjust this limit:

az containerapp update \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --max-inactive-revisions 50

Inactive revisions:

• Have no running replicas and incur no compute cost
• Can be reactivated at any time
• Are automatically purged when the inactive count exceeds the limit (oldest first)

See Also¶

• Platform - Revisions Overview
• Operations - Deployment Workflows
• Operations - Deploy with the Azure Developer CLI (azd)
• Best Practices - Revision Strategy
• Platform - Scaling

Sources¶

• Update and deploy changes in Azure Container Apps (Microsoft Learn)
• Deploy an artifact file to Azure Container Apps (Microsoft Learn)
• Deploy your first container app (Microsoft Learn)
• Blue-green deployment in Azure Container Apps (Microsoft Learn)
• Traffic splitting in Azure Container Apps (Microsoft Learn)