Azure Container Registry (ACR)
What it is
Azure Container Registry (ACR) is a managed registry for container images and related artifacts. A registry stores versioned images so an authorized runtime, such as Container Apps, ACI, AKS, or App Service, can pull the exact software it should run.
Why it exists
An application image must live somewhere between its build and deployment. ACR gives an Azure-controlled location for that handoff, with Azure identity, network, automation, and regional options. It can be appropriate for private workloads, but a public registry is not automatically wrong; choose based on trust, accessibility, and delivery needs.
Key ideas
- A registry contains repositories, which contain tagged images and immutable image snapshots. A tag such as
latestcan move; use an immutable digest when a deployment must prove exactly which bytes it ran. - ACR supports Docker-compatible images and related OCI artifacts, such as Helm charts. It can store Linux and Windows images.
- Basic, Standard, and Premium tiers share core registry features. Premium adds capabilities and larger limits, including geo-replication. Check the current SKU comparison before selecting a tier for private connectivity, replication, or capacity.
- ACR Tasks can build images in Azure on demand or from triggers such as source commits and base-image updates. A build trigger still needs a controlled source, tested output, and a release decision.
- Authenticate with Azure identities, service principals, or the registry’s admin account where permitted. Prefer least-privileged Azure RBAC or repository permissions and avoid embedding a registry password in code or deployment manifests.
- ACR integrates with image-pulling runtimes, but image availability is separate from application authorization and runtime network connectivity.
How it fits (diagram)
Northwind example
Northwind’s build pipeline creates an image for the catalogue service, scans and tests it, then pushes it to northwindregistry.azurecr.io/catalogue. It records the resulting digest. Container Apps pulls that digest through an authorized identity, so the deployment uses the bytes that passed testing. When a new base image needs a security patch, ACR Tasks can rebuild the image, but Northwind still tests and promotes the resulting digest before production uses it.
Registry versus image and runtime
| Term | Main job |
|---|---|
| ACR | Store and distribute images and related artifacts. |
| [[container-image | Container image]] |
| [[azure-app-container-apps | Container Apps]], [[aci |
Common confusion
- A registry does not run code. It stores the image that a separate runtime pulls.
- A successful push does not prove the image is secure or ready for production. Scan, test, and promote intentionally.
- A tag is convenient for people but can change. A digest is safer for traceable deployment and rollback decisions.
Related
Sources and re-audit
- Microsoft Learn — Introduction to Azure Container Registry, checked 2026-09-16.