Update Agent registry documentation defaults

content/en/actions/private_actions/update_private_action_runner.md

@@ -71,20 +71,22 @@ Update the Datadog Operator and Agent image versions in your DatadogAgent manife
    ```bash
    helm repo update
    helm upgrade datadog-operator datadog/datadog-operator \
-       --set image.repository=datadog/operator \
-       --set image.tag=latest # you can pin a specific version, see available tags on [Docker Hub][102]
+       --set image.repository=registry.datadoghq.com/operator \
+       --set image.tag=latest
    ```
 
+   You can pin a specific version. To browse available tags, use [Docker Hub][102].
+
 2. Update the Agent image versions in your `datadog-agent.yaml` manifest:
 
    ```yaml
    override:
      nodeAgent:
        image:
-         name: datadog/agent:<NEW_AGENT_VERSION>
+         name: registry.datadoghq.com/agent:<NEW_AGENT_VERSION>
      clusterAgent:
        image:
-         name: datadog/cluster-agent:<NEW_AGENT_VERSION>
+         name: registry.datadoghq.com/cluster-agent:<NEW_AGENT_VERSION>
    ```
 
 3. Apply the updated manifest:

content/en/actions/private_actions/use_private_actions.md

@@ -184,7 +184,7 @@ Install the Datadog Operator version 1.25.0:
 helm repo add datadog https://helm.datadoghq.com
 helm repo update
 helm install datadog-operator datadog/datadog-operator \
-    --set image.repository=datadog/operator \
+    --set image.repository=registry.datadoghq.com/operator \
     --set image.tag=1.25.0
 ```
 

content/en/agent/configuration/secrets-management.md

@@ -855,7 +855,7 @@ docker service create \
   --env DD_SECRET_BACKEND_TYPE="docker.secrets" \
   --env DD_SITE="datadoghq.com" \
   --env DD_HOSTNAME="dd-agent" \
-  datadog/agent:latest
+  registry.datadoghq.com/agent:latest
 ```
 
 The secret `dd_api_key` is automatically mounted at `/run/secrets/dd_api_key`, and the Agent reads it using the `docker.secrets` backend.
@@ -869,7 +869,7 @@ version: '3.8'
 
 services:
   datadog:
-    image: datadog/agent:latest
+    image: registry.datadoghq.com/agent:latest
     environment:
       - DD_API_KEY=ENC[dd_api_key]
       - DD_SECRET_BACKEND_TYPE=docker.secrets

content/en/agent/guide/agent-v6-python-3.md

@@ -59,7 +59,7 @@ To keep the Datadog Agent updated, edit your `datadog-values.yaml` to remove any
 
 To use a specific container registry, set it with `agent.image.repository` and `clusterChecksRunner.image.repository`. Ensure that `agents.image.tag` and  `clusterChecksRunner.image.tag` are undefined.
 
-The default registry is `gcr.io/datadoghq/agent`.
+When the image repository is unset, the Helm chart derives it from `datadog.site`, cluster type, and `registryMigrationMode`.
 
 ```yaml
 agent:
@@ -143,7 +143,7 @@ spec:
         name: gcr.io/datadoghq/agent:6.33.0
 ```
 
-Use the `spec.global.registry` if you need to change the default registry. The default is `gcr.io/datadoghq`.
+Use `spec.global.registry` if you need to change the registry selected from your Datadog site, cluster type, and `registryMigrationMode`.
 
 Then, pin the Agent 7 image tag in `spec.override.nodeAgent.image.tag`.
 
@@ -279,4 +279,4 @@ datadog_config:
 
 [1]: /agent/versions/upgrade_to_agent_v7/?tab=linux
 [2]: /agent/configuration/agent-configuration-files/#agent-main-configuration-file
-[3]: /agent/configuration/agent-commands/#restart-the-agent
+[3]: /agent/configuration/agent-commands/#restart-the-agent

content/en/agent/guide/install-agent-6.md

@@ -763,12 +763,12 @@ For a one-step install, run the following command. Replace `MY_API_KEY` with you
 
 On Amazon Linux v2:
 ```shell
-docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=MY_API_KEY -e DD_SITE="datad0g.com" gcr.io/datadoghq/agent:6
+docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=MY_API_KEY -e DD_SITE="datad0g.com" registry.datadoghq.com/agent:6
 ```
 
 On other operating systems:
 ```shell
-docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=MY_API_KEY -e DD_SITE="datad0g.com" gcr.io/datadoghq/agent:6
+docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=MY_API_KEY -e DD_SITE="datad0g.com" registry.datadoghq.com/agent:6
 ```
 
 #### Troubleshooting
@@ -1235,4 +1235,4 @@ Alternatively, you can build the Agent binary for version 6 following the [Getti
 [9]: https://github.com/DataDog/dd-agent/wiki/Windows-Agent-Installation
 [10]: /agent/guide/windows-agent-ddagent-user/
 [11]: https://github.com/DataDog/datadog-agent/blob/main/docs/dev/agent_omnibus.md#building-inside-docker-linux-only-recommended
-[12]: https://github.com/DataDog/datadog-agent#getting-started
+[12]: https://github.com/DataDog/datadog-agent#getting-started

content/en/containers/amazon_ecs/managed_instances.md

@@ -629,7 +629,7 @@ To collect traces over UDS:
 {
     "containerDefinitions": [
         {
-            "image": "datadog/agent:latest",
+            "image": "public.ecr.aws/datadog/agent:latest",
             "mountPoints": [
                 {
                     "containerPath": "/var/run/datadog",

content/en/containers/cluster_agent/_index.md

@@ -36,7 +36,7 @@ Datadog publishes container images to the Datadog Container Registry, Google Art
 
 {{% container-images-table %}}
 
-By default, the Helm chart pulls images from Google Artifact Registry (`gcr.io/datadoghq`). The Datadog Operator chart is progressively migrating to the Datadog Container Registry (`registry.datadoghq.com`).
+By default, the Helm chart determines the image registry from your Datadog site, cluster type, and `registryMigrationMode`. Depending on these values and environment exclusions, Agent images may be pulled from the Datadog Container Registry (`registry.datadoghq.com`) or from a site-specific registry. As of Datadog Operator chart version 2.19.0, the Operator chart uses the same registry selection logic for Agent images it manages. The Operator pod image is controlled separately by the Operator chart `image.repository` value.
 
 <div class="alert alert-warning">Docker Hub is subject to image pull rate limits. If you are not a Docker Hub customer, Datadog recommends that you update your Datadog Agent and Cluster Agent configuration to pull from another registry. For instructions, see <a href="/agent/guide/changing_container_registry">Changing your container registry</a>.</div>
 

content/en/containers/guide/autodiscovery-with-jmx.md

@@ -299,7 +299,7 @@ If you cannot mount these files in the Agent container (for example, on Amazon E
 For example:
 
 ```Dockerfile
-FROM gcr.io/datadoghq/agent:latest-jmx
+FROM registry.datadoghq.com/agent:latest-jmx
 COPY <PATH_JMX_CONF_FILE> conf.d/tomcat.d/
 COPY <PATH_JMX_METRICS_FILE> conf.d/tomcat.d/
 ```

content/en/containers/guide/changing_container_registry.md

@@ -27,7 +27,7 @@ When selecting a container registry, Datadog recommends the following approach:
 
 4. **Docker Hub**: Avoid unless you have a Docker Hub subscription, as it is subject to rate limits. Only Docker Hub supports Notary for image signature verification.
 
-<div class="alert alert-info">As of version 2.19.0, the Datadog Operator chart is progressively migrating to the Datadog Container Registry (<code>registry.datadoghq.com</code>).</div>
+<div class="alert alert-info">The Datadog Helm chart determines the default Agent image registry from your Datadog site, cluster type, and <code>registryMigrationMode</code>. As of Datadog Operator chart version 2.19.0, the Operator chart uses the same registry selection logic for Agent images it manages. The Operator pod image is controlled separately by the Operator chart <code>image.repository</code> value.</div>
 
 To update your registry, update your registry values based on the type of container environment you are deploying on. You can also use a private registry, but you need to [create a pull secret][1] to pull the images.
 
@@ -39,13 +39,13 @@ To update your containers registry, run the pull command for the new registry. T
 
 ## Kubernetes with Helm chart
 
-To update your containers registry while deploying the Datadog Agent (or Datadog Cluster Agent) with the Datadog helm chart on Kubernetes (including GKE, EKS, AKS, and OpenShift) update the `values.yaml` to specify a different registry:
+To update your containers registry while deploying the Datadog Agent (or Datadog Cluster Agent) with the Datadog Helm chart on Kubernetes (including GKE, EKS, AKS, and OpenShift), update the `values.yaml` to specify a different registry:
 
 ### Datadog Helm chart >= v2.7.0
 
-1. Update your `values.yaml`:
+1. Update your `values.yaml`. For example, to use Amazon ECR:
     ```yaml
-    registry: registry.datadoghq.com
+    registry: public.ecr.aws/datadog
     ```
 2. Remove any overrides for `agents.image.repository`, `clusterAgent.image.repository`, or `clusterChecksRunner.image.repository` in the `values.yaml`.
 
@@ -89,11 +89,11 @@ clusterChecksRunner:
 
 ## Kubernetes with the Datadog Operator
 
-As of Operator chart version 2.19.0, the Datadog Operator is migrating to `registry.datadoghq.com` for both the operator image and Agent images it manages. Previously, Agent images were pulled from site-specific registries (`gcr.io/datadoghq`, `eu.gcr.io/datadoghq`, `asia.gcr.io/datadoghq`, or `datadoghq.azurecr.io`). To keep using the previous site-specific registries, set `registryMigrationMode: ""` in your Operator Helm `values.yaml`.
+As of Datadog Operator chart version 2.19.0, the Datadog Operator can use `registry.datadoghq.com` for Agent images it manages, depending on your Datadog site, cluster type, and `registryMigrationMode`. Earlier versions pulled Agent images from site-specific registries (`gcr.io/datadoghq`, `eu.gcr.io/datadoghq`, `asia.gcr.io/datadoghq`, or `datadoghq.azurecr.io`). To use the previous site-specific registries for Agent images, set `registryMigrationMode: ""` in your Operator Helm `values.yaml`. This setting has no effect when you explicitly set a registry, and it does not control the Operator pod image. To use a different registry for the Operator pod image, set `image.repository` in your Operator Helm `values.yaml`.
 
 To update your registry while deploying the Datadog Agent (or Datadog Cluster Agent) with the Datadog Operator:
 
-1. Update the Datadog Agent manifest file to override the default registry (`registry.datadoghq.com`). For example, with `public.ecr.aws/datadog`:
+1. Update the Datadog Agent manifest file to override the resolved registry. For example, with `public.ecr.aws/datadog`:
 ```yaml
 apiVersion: datadoghq.com/v2alpha1
 kind: DatadogAgent
@@ -134,7 +134,7 @@ For more information about the Datadog Operator, see [Deploying an Agent with th
 
 ### Using another container registry with Helm
 
-You can switch from the default `registry.datadoghq.com` registry to another registry, such as `public.ecr.aws/datadog` when installing the Operator with the Helm chart:
+You can switch from the registry selected by `registryMigrationMode` to another registry, such as `public.ecr.aws/datadog`, when installing the Operator with the Helm chart:
 
 Update [`values.yaml`][6] with the new image:
 

content/en/containers/guide/readonly-root-filesystem.md

@@ -83,7 +83,7 @@ Create a custom Datadog Agent image with pre-defined volumes for writable direct
 
 1. Create a Dockerfile that extends the Datadog Agent image and declares volumes for required paths:
 ```dockerfile
-FROM gcr.io/datadoghq/agent:latest
+FROM registry.datadoghq.com/agent:latest
 
 VOLUME ["/etc/datadog-agent", "/opt/datadog-agent/run", "/var/run/datadog", "/var/log/datadog"]
 
@@ -153,4 +153,3 @@ Agent flare requires write access to `/tmp/`. If generating flares is important
 [2]: https://docs.aws.amazon.com/eks/latest/best-practices/pod-security.html
 [3]: https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF
 [4]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
-

content/en/containers/kubernetes/installation.md

@@ -228,14 +228,14 @@ Datadog publishes container images to the Datadog Container Registry, Google Art
 
 {{% container-images-table %}}
 
-By default, the Helm chart pulls images from Google Artifact Registry (`gcr.io/datadoghq`). The Datadog Operator chart is progressively migrating to the Datadog Container Registry (`registry.datadoghq.com`).
+By default, the Helm chart determines the image registry from your Datadog site, cluster type, and `registryMigrationMode`. Depending on these values and environment exclusions, Agent images may be pulled from the Datadog Container Registry (`registry.datadoghq.com`) or from a site-specific registry. As of Datadog Operator chart version 2.19.0, the Operator chart uses the same registry selection logic for Agent images it manages. The Operator pod image is controlled separately by the Operator chart `image.repository` value.
 
 <div class="alert alert-warning">Docker Hub is subject to image pull rate limits. If you are not a Docker Hub customer, Datadog recommends that you update your Datadog Agent and Cluster Agent configuration to pull from another registry. For instructions, see <a href="/agent/guide/changing_container_registry">Changing your container registry</a>.</div>
 
 {{< tabs >}}
 {{% tab "Datadog Operator" %}}
 
-The Datadog Operator chart is migrating to `registry.datadoghq.com` for both the operator image and Agent images it manages. Previously, Agent images were pulled from site-specific registries (`gcr.io/datadoghq`, `eu.gcr.io/datadoghq`, `asia.gcr.io/datadoghq`, or `datadoghq.azurecr.io`). To keep using the previous site-specific registries, set `registryMigrationMode: ""` in your Operator Helm `values.yaml`.
+As of Datadog Operator chart version 2.19.0, the Datadog Operator chart can use `registry.datadoghq.com` for Agent images it manages, depending on your Datadog site, cluster type, and `registryMigrationMode`. Earlier versions pulled Agent images from site-specific registries (`gcr.io/datadoghq`, `eu.gcr.io/datadoghq`, `asia.gcr.io/datadoghq`, or `datadoghq.azurecr.io`). To keep using the previous site-specific registries for Agent images, set `registryMigrationMode: ""` in your Operator Helm `values.yaml`. This setting has no effect when you explicitly set a registry, and it does not control the Operator pod image. To use a different registry for the Operator pod image, set `image.repository` in your Operator Helm `values.yaml`.
 
 To use a different container registry, modify `global.registry` in `datadog-agent.yaml`.
 

content/en/database_monitoring/setup_mysql/azure.md

@@ -189,7 +189,7 @@ docker run -e "DD_API_KEY=${DD_API_KEY}" \
 Labels can also be specified in a `Dockerfile`, so you can build and deploy a custom agent without changing any infrastructure configuration:
 
 ```Dockerfile
-FROM datadog/agent:7.36.1
+FROM registry.datadoghq.com/agent:7.36.1
 
 LABEL "com.datadoghq.ad.check_names"='["mysql"]'
 LABEL "com.datadoghq.ad.init_configs"='[{}]'

content/en/database_monitoring/setup_postgres/azure.md

@@ -315,7 +315,7 @@ For Postgres 9.6, add the following settings to the instance config where host a
 Labels can also be specified in a `Dockerfile`, so you can build and deploy a custom Agent without changing any infrastructure configuration:
 
 ```Dockerfile
-FROM datadog/agent:<AGENT_VERSION>
+FROM registry.datadoghq.com/agent:<AGENT_VERSION>
 
 LABEL "com.datadoghq.ad.check_names"='["postgres"]'
 LABEL "com.datadoghq.ad.init_configs"='[{}]'

content/en/integrations/guide/jmxfetch-fips.md

@@ -88,7 +88,7 @@ Container installations must use BCFKS key store format. Use the `keytool` utili
    ```shell
    keytool -keystore java-app-keystore -genkey -alias java-app -dname CN=java-app -validity 365 -keyalg ec -storepass changeit
 
-   docker run --rm -v $(pwd):/ssl datadog/agent:latest-fips-jmx \
+   docker run --rm -v $(pwd):/ssl registry.datadoghq.com/agent:latest-fips-jmx \
      keytool -keystore /ssl/jmxfetch-keystore -genkey -alias jmxfetch -dname CN=jmxfetch -validity 365 -keyalg ec -storepass changeit -keypass changeit
    ```
 
@@ -97,7 +97,7 @@ Container installations must use BCFKS key store format. Use the `keytool` utili
    ```shell
    keytool -keystore java-app-keystore -export -alias java-app -rfc -file java-app-cert.pem -storepass changeit
 
-   docker run --rm -v $(pwd):/ssl datadog/agent:latest-fips-jmx \
+   docker run --rm -v $(pwd):/ssl registry.datadoghq.com/agent:latest-fips-jmx \
      keytool -keystore /ssl/jmxfetch-keystore -export -alias jmxfetch -rfc -file /ssl/jmxfetch-cert.pem -storepass changeit
    ```
 
@@ -106,7 +106,7 @@ Container installations must use BCFKS key store format. Use the `keytool` utili
    ```shell
    keytool -keystore java-app-truststore -import -alias jmxfetch -file jmxfetch-cert.pem -storepass changeit -noprompt
 
-   docker run --rm -v $(pwd):/ssl datadog/agent:latest-fips-jmx \
+   docker run --rm -v $(pwd):/ssl registry.datadoghq.com/agent:latest-fips-jmx \
      keytool -keystore /ssl/jmxfetch-truststore -import -alias java-app -file /ssl/java-app-cert.pem -storepass changeit -noprompt
    ```
 

content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md

@@ -152,7 +152,7 @@ When enabling additional Datadog features, always use the Datadog or OpenTelemet
 
 **Note**: As of operator `v1.22.0`, the DDOT container uses the `ddot-collector` image instead of the `-full` agent image.
 - When overriding the node agent image tag, use a tag >= `7.67.0` so the OTel container is scheduled (the `ddot-collector` image is only supported in >= `7.67.0`).
-- The `ddot-collector` image has no `-full` variant. If you need a `-full` image, set `spec.override.nodeAgent.image.name` to a full agent image (for example, `gcr.io/datadoghq/agent:7.72.1-full`).
+- The `ddot-collector` image has no `-full` variant. If you need a `-full` image, set `spec.override.nodeAgent.image.name` to a full agent image (for example, `registry.datadoghq.com/agent:7.72.1-full`).
 
 [1]: /getting_started/site
 [2]: /containers/guide/changing_container_registry/

layouts/shortcodes/csm-fargate-eks-sidecar.en.md

@@ -43,7 +43,7 @@ spec:
            mountPath: "/cws-instrumentation-volume"
            readOnly: true
      - name: datadog-agent
-       image: datadog/agent:latest 
+       image: public.ecr.aws/datadog/agent:latest
        env:
          - name: DD_API_KEY
            value: "<DD_API_KEY>"
@@ -64,4 +64,4 @@ spec:
        - name: cws-instrumentation-volume
      serviceAccountName: datadog-agent
      shareProcessNamespace: true
-```
+```

layouts/shortcodes/dbm-mongodb-agent-setup-docker.en.md

@@ -33,7 +33,7 @@ docker run -e "DD_API_KEY=${DD_API_KEY}" \
       }]
     }
   }' \
-  datadog/agent:${DD_AGENT_VERSION}
+  registry.datadoghq.com/agent:${DD_AGENT_VERSION}
 ```
 
 ### Validate

layouts/shortcodes/dbm-sqlserver-agent-setup-docker.en.md

@@ -24,7 +24,7 @@ docker run -e "DD_API_KEY=${DD_API_KEY}" \
       "env:<CUSTOM_ENV>"
     ]
   }]' \
-  gcr.io/datadoghq/agent:${DD_AGENT_VERSION}
+  registry.datadoghq.com/agent:${DD_AGENT_VERSION}
 ```
 
 Use the `service` and `env` tags to link your database telemetry to other telemetry through a common tagging scheme. See [Unified Service Tagging][3] on how these tags are used throughout Datadog.