> ## 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. # Container Registry (ACR) > Container Registry (ACR) APIs with Cloud Adapter. 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 | Environment | Mapping | | ------------ | ------- | | AWS | API | | Google Cloud | 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 Container Registry (ACR) with its adaptation on each target. A dash means this profile does not state the capability for that target. ### Cloud Adapter | Capability | Container Registry (ACR) | AWS | Google Cloud | | ------------ | ------------------------ | ---- | ------------ | | API coverage | full | high | partial | ## On AWS ### ECR (Elastic Container Registry) | Operation | Area | Support | Depth | Notes | | ------------------------------------------- | -------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | | Repository-scoped tokens | Access | Partial | Most usage | A scoped token becomes a target repository policy. The build shows the rewritten policy because the permission models differ. | | Registry tasks | Build | Out of scope | Full surface | Rejected at build time: the target registry does not execute the image-building, patching and signing tasks. | | Image push and pull | Registry | Supported | Common | the container registry wire protocol and its token exchange map directly onto the target registry | | Push to a repository that was never created | Registry | Supported | Common | A creation rule lets the first push to a new repository path succeed even though the target normally requires the repository to exist first. | | Repositories | Registry | Supported | Common | a repository path under the registry becomes a repository on the target, and manifest and tag metadata come with it | | Retention policies | Registry | Supported | Most usage | held as a lifecycle policy on the target repository, expressed over the same tag and age conditions | | Vulnerability scanning | Registry | Supported | Most usage | The target provides scanning for pushed images. | 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 | Operation | Area | Support | Depth | Notes | | ------------------------ | -------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Repository-scoped tokens | Access | Supported | Most usage | Access remains scoped to individual repositories without widening the grant. | | Registry tasks | Build | Out of scope | Full surface | Rejected at build time: the target registry does not execute the image-building, patching and signing tasks. | | Image path | Registry | Partial | Common | Image references are rewritten to include the target host, project, repository and image. The build shows the change, but cannot rewrite references constructed at runtime. | | Image push and pull | Registry | Supported | Common | the container registry wire protocol and its token exchange map directly onto the target registry | | Repositories | Registry | Supported | Common | Repositories become Docker repositories under a project and location, preserving manifest and tag metadata. | | Retention policies | Registry | Supported | Most usage | held as a cleanup policy on the target repository, expressed over the same tag and age conditions | | Vulnerability scanning | Registry | Supported | Most usage | The target provides scanning for pushed images. | 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](/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.