Azure Container Registry

About Azure Container Registry

Azure Container Registry is Microsoft Azure's managed private registry for storing and distributing container images and OCI artifacts. It is designed for teams that build containerized applications and need a registry that integrates with Azure Kubernetes Service, Azure Container Apps, App Service, CI/CD pipelines, Microsoft Entra identity, private networking, and regional deployment patterns. ACR is not a container runtime: it stores and delivers the images and artifacts that other platforms run. Buyers should choose a tier based on storage, pull and push performance, networking, replication, automation, and security requirements rather than treating every registry as equivalent.

What is Azure Container Registry used for?

Azure Container Registry is used as a private distribution point for Docker-compatible container images and related OCI artifacts. Development teams can push images from local tools or CI/CD pipelines, then pull those images into Azure Kubernetes Service, Azure Container Apps, App Service, virtual machines, or other environments that can authenticate to the registry. Microsoft also documents support for Windows and Linux images plus related artifact formats such as OCI images and Helm content.

The main value is control over the software supply path. Organizations can keep application images inside their Azure environment, use Azure identities and role assignments, place registries near deployment regions, and integrate image build or maintenance workflows with ACR Tasks. ACR does not replace the build pipeline, vulnerability management program, or runtime platform, but it can become the central image source those systems rely on.

How do Basic, Standard, and Premium tiers differ?

Microsoft currently offers Basic, Standard, and Premium Azure Container Registry tiers. All three provide the core private-registry experience, Microsoft Entra authentication options, webhooks, and common registry operations. The pricing page currently lists included storage of 10 GB for Basic, 100 GB for Standard, and 500 GB for Premium. Storage above the included amount is billed separately.

Standard is the practical default for many production workflows and Microsoft's current portal quickstart uses a Standard registry. Premium is intended for higher scale and adds capabilities that Basic and Standard do not provide, including geo-replication, connected registries, higher throughput limits, and private endpoint support. Buyers should compare the actual limits and required network controls before choosing Premium only for the larger included storage amount.

How do geo-replication and reliability work?

Premium registries can use geo-replication to place registry replicas in multiple Azure regions. Microsoft routes clients through one global registry endpoint and synchronizes pushed image content and metadata across configured replicas. This can keep image pulls closer to deployment regions and reduce dependence on a single-region registry for global workloads.

Microsoft's current reliability guidance recommends Premium for production workloads that need the strongest reliability options, choosing a region with Availability Zone support, and configuring geo-replication for multi-region requirements. Replication is not a substitute for lifecycle controls or source-code recovery. Teams should still keep reproducible builds, source repositories, image-retention rules, and deployment manifests so a registry problem does not become the only recovery path.

How do identity, repository permissions, and networking work?

Azure Container Registry supports Microsoft Entra based access through Azure role-based access control. Microsoft documents built-in registry roles for users, managed identities, and service principals, plus custom roles when the built-in permissions do not fit. Newer registry creation flows also support an RBAC plus ABAC repository-permissions mode for more granular repository-level access decisions.

Production registries should avoid relying on the registry admin account for normal application access. Managed identities or service principals can give deployment platforms the specific permissions they need. Premium also supports private endpoint scenarios so teams can restrict registry connectivity through private networking. Authentication, repository authorization, network access, and image-signing or scanning strategy should be designed together rather than handled as separate afterthoughts.

What can ACR Tasks automate?

Azure Container Registry Tasks can build container images in Azure and automate build, test, and maintenance workflows. Microsoft documents on-demand builds plus triggers such as source-code commits and base-image updates. This can be useful for rebuilding images when a base operating system or framework image changes, or for moving container-build work out of developer machines and into an Azure-managed workflow.

Tasks are billed separately based on task compute usage. They should not be confused with a full CI/CD platform. Teams may still prefer GitHub Actions, Azure Pipelines, Jenkins, or another build system for broader workflows, while using ACR as the artifact destination. The best setup depends on where source control, testing, approvals, signing, and deployment orchestration already live.

How does Azure Container Registry pricing work?

Azure Container Registry does not have one universal monthly price. Microsoft prices the registry by service tier, with included storage that varies by Basic, Standard, and Premium. Additional stored data is billed separately, and standard Azure networking charges can apply to data transfer. Premium geo-replication adds charges for replicated regions, and connected registries have their own meter. ACR Tasks are billed according to task compute usage.

Pricing was checked against Microsoft's current Azure Container Registry pricing page on August 26, 2026. Buyers should estimate registry tier, stored image volume, image churn, build-task use, replicated regions, network egress, and the number and location of deployment targets. A registry used by many clusters in several regions can have a very different cost profile from one small development registry.

What limitations and migration issues should buyers consider?

Container registries can accumulate large numbers of old tags, untagged manifests, and duplicate layers. Teams should define retention and cleanup rules instead of assuming storage will remain small. Microsoft provides retention controls for eligible scenarios and documents a preview retention policy for untagged manifests. Deleting old content must be handled carefully because a deployment may still reference an older tag or digest.

Security features also change over time. Microsoft states that Docker Content Trust cannot be enabled on new registries, or on registries where it was not already enabled, starting May 31, 2026. Teams designing a new signing strategy should therefore validate Microsoft's current artifact-signing guidance instead of building a new process around legacy Docker Content Trust instructions. Migration from another registry should also account for image names, tags, digests, credentials, pull secrets, automation, and downstream deployment references.

Who should choose something else?

Teams that only need a public image catalog may prefer a public registry rather than paying for and operating a private Azure registry. Organizations standardized on another cloud or a multicloud artifact platform may prefer a registry that is already integrated with their existing build, policy, and deployment tooling. Very small development projects may also find a simpler hosted registry sufficient if Azure identity, networking, geo-replication, and ACR Tasks provide little value.

Azure Container Registry is strongest when Azure is already part of the application platform and teams need private image storage, Microsoft Entra access, Azure-native deployment integration, regional replication options, and centralized artifact distribution. Buyers should choose ACR because it improves the software delivery path and governance around container artifacts, not simply because the runtime also happens to be in Azure.