Artifact Registry

This page describes how Artifact Registry 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 Artifact Registry 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)

An Artifact Registry Docker repository becomes an ECR repository. Image push and pull use the same registry protocol; ECR provides scanning and lifecycle cleanup.

​

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

Repository-level access becomes an ECR repository policy. The build shows that policy because the permission models differ. Maven, npm, Python and apt repositories are unsupported on this target, which stores container images.

​

On Azure

​

Container Registry (ACR)

Artifact Registry Docker repositories become repositories in an Azure Container Registry. Azure creates each repository when an image is first pushed to its path. Multiple source repositories share one registry, and image references change from host/project/repository/image to registry/image.

​

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

The build shows these rewrites but cannot update references your application constructs at runtime. Repository-level access also becomes registry-wide access; the build identifies this widening of permissions.

​

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.