Container Registry (ACR)

This page describes how Container Registry (ACR) maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

​

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

​

How the targets compare

Each row compares a capability of Container Registry (ACR) with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On AWS

​

ECR (Elastic Container Registry)

Azure Container Registry repositories become ECR repositories. Image push and pull use the same container registry protocol; retention settings become lifecycle policies, and ECR provides image scanning.

​

Images, credentials, and repository state

Clients push and pull manifests and layers using the container registry protocol. Source repository-management settings are adapted to the target registry, including the supported retention and access controls. Test a push and a pull with the actual workload credentials; permission to manage a registry does not necessarily grant permission to read an image.

​

Preparing consumers

Copy the required image manifests and layers before starting workloads on the target. Update image references and pull credentials together, preserving digest references where the deployment uses them. Review cleanup rules after transfer so they do not remove versions still needed for deployment or rollback.

​

Compatibility differences

Azure can create a repository on the first push to a new path. This mapping declares an ECR creation rule so that push can succeed. Registry tasks are rejected because ECR stores images but does not run the in-registry build and patch jobs.

​

On Google Cloud

​

Artifact Registry

Images are stored in Artifact Registry Docker repositories under a Google Cloud project and location. Push and pull use the same registry protocol. Image references change to include the target host, project and repository; the build shows these rewrites, but cannot update references your application constructs at runtime.

​

Images, credentials, and repository state

Clients push and pull manifests and layers using the container registry protocol. Source repository-management settings are adapted to the target registry, including the supported retention and access controls. Test a push and a pull with the actual workload credentials; permission to manage a registry does not necessarily grant permission to read an image.

​

Preparing consumers

Copy the required image manifests and layers before starting workloads on the target. Update image references and pull credentials together, preserving digest references where the deployment uses them. Review cleanup rules after transfer so they do not remove versions still needed for deployment or rollback.

​

Compatibility differences

Scoped tokens map to repository-level permissions without widening access. Registry tasks are rejected because Artifact Registry does not run their image-build jobs.

​

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

​

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.