Deploy Container Apps with Azure Developer CLI

Deploys containerized frontend and backend applications to Azure Container Apps using the Azure Developer CLI (azd), with remote builds, managed identity, and idempotent infrastructure. Core workflow: azd auth login, azd init to create azure.yaml and .azure/, azd env new <env-name>, and azd up to provision infrastructure, build, and deploy in one step.

Use this when deploying containerized frontend and backend services to Azure Container Apps via azd: configuring azure.yaml, setting up remote builds, wiring environment variables through Bicep, managing custom domains across redeploys, or assigning managed-identity RBAC.

Not needed for non-Azure deployments, or for Azure services other than Container Apps.

azure.yaml defines services with a project path, language, host: containerapp, and Docker build config with remoteBuild: true, recommended since local builds fail on M1/ARM Macs deploying to AMD64, plus preprovision, postprovision, and postdeploy hooks. Environment variables flow through three levels: a local .env for development only, an azd-managed .azure/<env>/.env auto-populated from Bicep outputs, and infra/main.parameters.json mapping env vars to Bicep parameters via ${VAR_NAME} or ${VAR_NAME=default} syntax, set with azd env set KEY value. Bicep outputs like output SERVICE_FRONTEND_URI string = frontend.outputs.uri auto-populate the environment file and should never be edited manually.

azd auth login
azd init                    # Creates azure.yaml and .azure/ folder
azd env new <env-name>      # Create environment (dev, staging, prod)
azd up                      # Provision infra + build + deploy

azd up is idempotent because Bicep is declarative and resources reconcile to the desired state, remote builds tag images uniquely by deployment timestamp, and ACR reuses unchanged layers. Custom domains added via the Azure Portal can be lost on redeploy unless preserved with preprovision/postprovision hooks that save and verify them, and existing resources like a Container Registry can be referenced with Bicep's existing keyword instead of recreated. Container Apps in the same environment reach each other over internal DNS (http://ca-backend-${resourceToken}), which a frontend nginx config can proxy to. Managed identity is enabled via identity: { type: 'SystemAssigned' } on the Container App resource, with its principalId output used in a postprovision hook to assign RBAC roles such as Cognitive Services OpenAI User or Search Index Data Reader, each guarded with || true to prevent "already exists" errors from failing the deploy. Common commands include azd env list/select/get-values/set, azd provision/deploy/deploy --service backend, azd show, and streaming logs via az containerapp logs show -n <app> -g <rg> --follow.

Developers deploying containerized apps to Azure Container Apps via azd who need concrete azure.yaml, Bicep, and RBAC hook patterns rather than generic Azure documentation.