Deploy Container Apps with Azure Developer CLI

This skill teaches an agent to deploy containerized frontend and backend applications to Azure Container Apps with the Azure Developer CLI (azd), using remote builds, managed identity, and idempotent Bicep infrastructure. The flow is azd auth login, azd init to create azure.yaml and a .azure/ folder, azd env new <env-name> to create an environment, then azd up to provision infrastructure, build, and deploy in one step. Deployments stay idempotent because Bicep reconciles resources to a declarative desired state, remote builds tag images uniquely per deployment, and Azure Container Registry reuses unchanged layers.

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

Use it when setting up or maintaining an azd-based deployment for services hosted as Azure Container Apps - defining azure.yaml service blocks, wiring environment variables through the three-level configuration (local .env, azd-managed .azure/<env>/.env, and main.parameters.json), or writing preprovision, postprovision, and postdeploy hooks. It targets the Container Apps host (host: containerapp) with Bicep infrastructure specifically; it is not a general guide for other Azure compute targets. Always set remoteBuild: true - local builds fail when deploying from an M1/ARM Mac to the AMD64 Container Apps runtime.

Inputs: an azure.yaml defining services (project path, language, host: containerapp, Docker path/context, remoteBuild: true), Bicep modules under infra/ with main.parameters.json mapping ${VAR_NAME} or ${VAR_NAME=default_value} syntax to Bicep parameters, and hooks (preprovision, postprovision, postdeploy) written as shell scripts. Secrets should be set with azd env set KEY value rather than defaulted in main.parameters.json. Outputs: provisioned Azure Container Apps infrastructure, deployed container images, and environment variables auto-populated into .azure/<env>/.env straight from Bicep outputs, such as SERVICE_FRONTEND_URI, SERVICE_BACKEND_URI, and BACKEND_PRINCIPAL_ID.

Azure Container Apps, Azure Container Registry (via remoteBuild: true), Bicep for infrastructure-as-code, Azure role-based access control for granting a Container App's managed identity access to dependent services - for example the Cognitive Services OpenAI User role for Azure OpenAI or Search Index Data Reader for Azure AI Search - and internal DNS-based service discovery between Container Apps in the same environment, such as an nginx proxy_pass to a backend's internal URL.

Developers and platform engineers deploying multi-service (frontend plus backend) applications to Azure Container Apps who want a repeatable, idempotent azd-driven pipeline instead of manual az CLI provisioning, including handling RBAC role assignment and preserving Portal-added custom domains across redeploys.