Feat Req: Custom Domain Support

[Gyarbij]

What is the problem you're trying to solve

Azure Container Registry (ACR) does not currently support custom domains (vanity hostnames) for registry endpoints.
This limitation forces all users—regardless of scale, regulatory requirements, or deployment model—to depend on the fixed *.azurecr.io namespace.

This becomes a recurring problem for:

• Regulated and sovereign environments (defence, government, critical infrastructure)
• Air-gapped or semi-disconnected deployments
• Enterprise platform teams that require consistent, organization-owned domains
• Long-lived products where vendor-specific endpoints leak into customer-facing artefacts, documentation, and contracts

Despite the documentation being updated recently, the functional limitations and lack of a roadmap signal have remained unchanged for more than two years, leaving teams to implement unsupported or operationally complex workarounds.

---

Describe the solution you'd like

Support first-class custom domain configuration for Azure Container Registry, similar in spirit (not necessarily implementation) to custom domains on Azure Storage, Front Door, or App Service.

At a minimum, the solution should include:

• Ability to associate a custom DNS name (e.g. registry.example.com) with an ACR instance

• Microsoft-managed TLS certificates for the custom domain (or optional BYO cert)

• Compatibility with:

  • Docker / OCI clients
  • Azure AD / workload identity auth
  • ACR Tasks
  • Private Endpoint + Private DNS

• Clear guidance on:

  • DNS configuration
  • Certificate lifecycle
  • Supported network topologies (public, private, hybrid)

This does not require exposing the internal control plane or breaking existing *.azurecr.io endpoints — both can coexist, as with other Azure services.

---

Additional context

Because custom domains are not supported today, customers are forced into one of the following sub-optimal patterns:

• Running and maintaining separate OCI registries (Harbor, Artifactory, Nexus) purely to gain domain and certificate control

• Leaking *.azurecr.io endpoints into:

  • Customer documentation
  • Deployment scripts
  • Long-term contracts and defence programmes

• Implementing unsupported proxy or gateway patterns that break Docker TLS validation

• Maintaining dual registries (ACR upstream + mirrored downstream), increasing cost and operational risk

In regulated sectors, domain ownership and endpoint control are not cosmetic concerns — they are often contractual, legal, or compliance requirements.

The repeated interest in this feature over multiple years, combined with recent documentation updates, suggests strong customer demand. A clear roadmap position or supported implementation would significantly reduce friction and prevent customers from abandoning ACR for third-party registries purely due to domain constraints.

The current support-ticket-based approach demonstrates that custom domains are achievable in ACR, but without productisation it remains unsuitable for modern enterprise, regulated, and sovereign deployments.

[terencet-dev]

Hi @Gyarbij, we have custom domains as a private preview feature. You can refer to #816.

Adding @toddysm for visibility

[Gyarbij]

Thanks for the response and while I understand that there exist a method. It has been in the same state in excess of 2 years and is cumbersome compared to a service like FrontDoor which is cumbersome compared to App Service as an example for assigning a custom domain and adding a cert.

[terencet-dev]

Acknowledged the feedback, @Gyarbij