Jon Gallant
Deploy Containers to Azure App Service with azd

Deploy Containers to Azure App Service with azd

3 min read

azd 1.27.0 can deploy container images to Azure App Service. Set language: docker on a service hosted with host: appservice, and azd builds the image, pushes it to Azure Container Registry, and points the site at it. Before this, the App Service target only supported zip deploy.

I built it after running into a case where a container had to run on App Service and Container Apps wasn’t an option (a mix of corporate policy and Azure Front Door restrictions), but it works for any Web App for Containers setup. Here’s how it works and how to use it.

How it works

You already describe how each service is hosted in azure.yaml. To deploy a container to App Service, set language: docker alongside host: appservice:

azure.yaml showing language docker and host appservice with a docker path

That’s the entire configuration change. As text:

name: my-app
services:
web:
project: ./src/web
language: docker # build and push a container image
host: appservice # to a Linux App Service
docker:
path: ./Dockerfile

When you run azd deploy, azd:

  1. Passes the container artifact through the package phase instead of building a zip.
  2. Pushes the image to your Azure Container Registry, reusing the same ContainerHelper as the Container Apps target.
  3. Verifies the site is configured for containers (Linux, with a DOCKER| container config).
  4. Updates the site’s linuxFxVersion to point at the new image.

If you’ve deployed a Container Apps service before, this will feel familiar. That’s deliberate. I reused the publishing path so the behavior is consistent across targets.

Deploy updates the image, not your config

azd doesn’t modify your infrastructure configuration at deploy time. It doesn’t enable ACR managed identity credentials, assign identities, or rewrite site settings. That all lives in your Bicep or Terraform and is provisioned before you deploy. Deploy updates the running image, and nothing else.

This mirrors the Container Apps target: your infrastructure as code owns configuration, and deploy owns the artifact. Keeping that boundary means no configuration drift and environments you can reproduce.

If the site isn’t set up for containers, azd returns a clear error instead of changing settings for you. Configure the App Service for containers in your IaC (Linux, a container-capable plan, and ACR pull access), and deploy handles the image from there.

What’s in scope

I kept the first release focused. In 1.27.0:

  • Linux App Service only. It sets linuxFxVersion, so Windows containers aren’t covered.
  • A single container. docker-compose multi-container support isn’t included yet.
  • language: docker or a prebuilt image:. Bring a Dockerfile or point at an existing image.
  • env: app settings aren’t wired up for container deploy yet. That’s tracked separately.

Getting started

This shipped in azd 1.27.0. Update from https://aka.ms/azd:

Terminal window
# Update to the latest
azd update
# Confirm you're on 1.27.0 or later
azd version

Confirm your azure.yaml service uses language: docker and host: appservice, confirm your Bicep or Terraform provisions a Linux App Service with ACR access, then run:

Terminal window
azd up

azd builds the image, pushes it to ACR, and points the site’s container configuration at it.

The pull request has the full implementation, and the azure.yaml schema reference documents the container deploy mode.

Share:
Share on X