Azure Container Registry, explained: where your images live before they run
You built a container image. Now it needs a home that your pipeline can push to and your production can pull from — privately, securely, close to where it runs. That home is a container registry, and Azure's is ACR.
A container image is useless sitting on your laptop. To ship it, you need somewhere central to push it from your build and pull it into your runtime — a registry. You could use a public one, but production images want to be private, access-controlled, and hosted near your workloads. Azure Container Registry (ACR) is that: Microsoft describes it as "a managed registry service based on the open-source Docker platform" for storing and managing "container images and related artifacts." Standard docker push and docker pull, but private and yours.
What it stores
ACR is not Docker-only. It holds images built to the OCI (Open Container Initiative) spec, plus related artifacts like Helm charts, and both Windows and Linux images. Because it speaks standard registry protocols, it slots straight into your existing container tooling — the same commands, the same workflows, now pointed at a registry you control. Deployment targets pull from it: AKS, App Service, Container Apps, or any Kubernetes cluster.
The three tiers
ACR comes in three SKUs, and the differences are mostly about scale and reach:
| Tier | For | Notable |
|---|---|---|
| Basic | Learning, small projects | Same core features, lowest storage/throughput |
| Standard | Most production workloads | More storage and throughput |
| Premium | Scale & enterprise | Geo-replication, private endpoints, content trust |
All tiers share the essentials — webhooks, Entra ID authentication, and image deletion. The one that most often justifies Premium is geo-replication: a single registry replicated across regions so each deployment pulls from a local copy, which matters when you run the same app in many regions.
ACR is not just storage; it can build. ACR Tasks offloads docker build to Azure and can trigger automatically — on a source-code commit, or, powerfully, when a base image updates. So when a security patch lands in the base OS image you depend on, ACR can rebuild your application image automatically. That turns "we should rebuild to pick up that CVE fix" from a manual chore into a pipeline that patches itself.
A registry is the handoff point: the pipeline pushes what it built, production pulls what it runs — and nothing untrusted comes in between.
Authentication: no password in the pipeline
This is where ACR ties back to good cloud hygiene. You can authenticate with an admin account, but the grown-up pattern is Entra ID with a managed identity and RBAC — your pipeline or your AKS cluster pulls images using its own Azure identity, with no registry password stored anywhere. It is the same "no secrets in code" story as reading a secret from Key Vault: the thing that authenticates is an identity you granted, not a credential you have to guard. Premium adds private endpoints to keep registry traffic off the public internet entirely, and Defender for Cloud can scan images for vulnerabilities as they are pushed.
The takeaway
Once you are building containers, you need a registry, and for an Azure workload ACR is the natural choice: private, standard-compatible, close to your deployments, and integrated with the rest of Azure's identity and security. Pick Basic to learn, Standard for most production, Premium when you need geo-replication or private networking. Push from your pipeline, pull with a managed identity, and let ACR Tasks rebuild on base-image updates. Say "a private ACR, pulled by managed identity, with Tasks rebuilding on base-image patches" and you are describing a container supply chain, not just a place to dump images.