> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Artifact Registry > Artifact Registry APIs with Cloud Adapter. 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 | Environment | Mapping | | ----------- | ------- | | AWS | API | | Azure | API | 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 | Capability | Artifact Registry | AWS | Azure | | ------------ | ----------------- | ---- | ------- | | API coverage | full | high | partial | ## On AWS ### ECR (Elastic Container Registry) | Operation | Area | Support | Depth | Notes | | ------------------------------- | -------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | Per-repository access bindings | Access | Partial | Most usage | Repository-level access becomes a target repository policy. The build shows the rewritten policy because the permission models differ. | | Image push and pull | Registry | Supported | Common | the container registry wire protocol and its token exchange work directly against the target registry | | Non-container formats | Registry | Out of scope | Full surface | Maven, npm, Python and apt repositories have no counterpart on the target, which serves container images only | | Remote and virtual repositories | Registry | Out of scope | Full surface | Remote and virtual repositories are flagged at build time. The target has pull-through caching, but this mapping does not configure it. | | Vulnerability scanning | Registry | Supported | Most usage | The target scans pushed images. | | cleanupPolicies | Registry | Supported | Most usage | expressed as a lifecycle policy on the target repository | | repositories.create / delete | Registry | Supported | Common | a Docker repository becomes a repository on the target | 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) | Operation | Area | Support | Depth | Notes | | ------------------------------ | -------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Per-repository access bindings | Access | Partial | Most usage | Repository-level access becomes registry-wide access. The build identifies this widening of permissions. | | Image path | Registry | Partial | Common | Image references change from host/project/repository/image to registry/image. The build shows the rewrite but cannot update references constructed at runtime. | | Image push and pull | Registry | Supported | Common | the container registry wire protocol and its token exchange work directly against the target registry | | Immutable tags | Registry | Out of scope | Full surface | Immutable tags are flagged at build time. The target supports image locking, but this mapping does not configure it. | | Non-container formats | Registry | Out of scope | Full surface | Maven, npm, Python and apt repositories have no counterpart on the target, which serves container images only | | Vulnerability scanning | Registry | Supported | Most usage | The target scans pushed images. | | repositories.create / delete | Registry | Partial | Common | Source repositories share one target registry. A target repository is created when the first image is pushed to its path. | 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](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.