Automate OS and framework patching with ACR Build

Containers provide new levels of virtualization, isolating application and developer dependencies from infrastructure and operational requirements. What remains, however, is the need to address how this application virtualization is patched.

ACR Build is a suite of features within Azure Container Registry. It provides cloud-based container image building for Linux, Windows, and ARM, and can automate OS and framework patching for your Docker containers.


ACR Build is currently in preview. Previews are made available to you on the condition that you agree to the supplemental terms of use. Some aspects of this feature may change prior to general availability (GA).

What is ACR Build?

Azure Container Registry Build is an Azure-native container image build service. ACR Build enables inner-loop development in the cloud with on-demand container image builds, and automated builds on source code commit and base image update.

Trigger container image builds automatically when code is committed to a Git repository, or when a container's base image is updated. With base image update triggers, you can automate your OS and application framework patching workflow, maintaining secure environments while adhering to the principals of immutable containers.

Quick Build: inner-loop extended to the cloud

The beginning of lifecycle management starts before developers commit their first lines of code. ACR Build's Quick Build feature enables an integrated local inner-loop development experience, offloading builds to Azure. With Quick Builds, you can verify your automated build definitions prior to committing your code.

Using the familiar docker build format, the az acr build command in the Azure CLI takes a context (the set of files to build), sends it to the ACR Build service and, by default, pushes the built image to its registry upon completion.

The following table shows a few examples of supported context locations for ACR Build:

Context location Description Example
Local filesystem Files within a directory on the local filesystem. /home/user/projects/myapp
GitHub master branch Files within the master (or other default) branch of a GitHub repository.
GitHub branch Specific branch of a GitHub repo.
GitHub PR Pull request in a GitHub repo.
GitHub subfolder Files within a subfolder in a GitHub repo. Example shows combination of PR and subfolder specification.
Remote tarball Files in a compressed archive on a remote webserver. http://remoteserver/myapp.tar.gz

ACR Build also follows your geo-replicated registries, enabling dispersed development teams to leverage the closest replicated registry.

ACR Build is designed as a container lifecycle primitive. For example, integrate ACR Build into your CI/CD solution. By executing az login with a service principal, your CI/CD solution could then issue az acr build commands to kick off image builds.

Learn how to use Quick Builds in the first ACR Build tutorial, Build container images in the cloud with Azure Container Registry Build.

Automatic build on source code commit

Use ACR Build to automatically trigger a container image build when code is committed to a Git repository. Build tasks, configurable with the Azure CLI command az acr build-task, allow you to specify a Git repository and optionally a branch and Dockerfile. When your team commits code to the repository, an ACR Build-created webhook triggers a build of the container image defined in the repo.

Learn how to trigger builds on source code commit in the second ACR Build tutorial, Automate container image builds with Azure Container Registry Build.

Automate OS and framework patching

The power of ACR Build to truly enhance your container build pipeline comes from its ability to detect an update to a base image. When the updated base image is pushed to your registry, ACR Build can automatically build any application images based on it.

Container images can be broadly categorized into base images and application images. Your base images typically include the operating system and application frameworks upon which your application is built, along with other customizations. These base images are themselves typically based on public upstream images, for example: Alpine Linux, Windows, .NET, or Node.js. Several of your application images might share a common base image.

When an OS or app framework image is updated by the upstream maintainer, for example with a critical OS security patch, you must also update your base images to include the critical fix. Each application image must then also be rebuilt to include these upstream fixes now included in your base image.

Because ACR Build dynamically discovers base image dependencies when it builds a container image, it can detect when an application image's base image is updated. With one preconfigured build task, ACR Build then automatically rebuilds every application image for you. With this automatic detection and rebuilding, ACR Build saves you the time and effort normally required to manually track and update each and every application image referencing your updated base image.

Learn about OS and framework patching in the third ACR Build tutorial, Automate image builds on base image update with Azure Container Registry Build.


For the initial preview, base image updates trigger builds only when both the base and application images reside in the same Azure container registry or publicly accessible Docker Hub repositories.

Next steps

When you're ready to automate OS and framework patching by building your container images in the cloud, check out the three-part ACR Build tutorial series.