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 Datadog Agent Helm chart determines the Agent 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. The Datadog Operator chart is included as a dependency of the Datadog Agent Helm chart by default. As of Datadog Operator chart version 2.19.0, when you install the Operator through that dependency, the Datadog Agent Helm chart's `registryMigrationMode` applies to Agent images managed by the Operator. The Operator Helm chart itself does not define `registryMigrationMode`; 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 Agent Helm chart determines the default Agent image registry from your Datadog site, cluster type, and <code>registryMigrationMode</code>. The Datadog Operator chart is included as a dependency of the Datadog Agent Helm chart by default. As of Datadog Operator chart version 2.19.0, when you install the Operator through that dependency, the Datadog Agent Helm chart's <code>registryMigrationMode</code> applies to Agent images managed by the Operator. The Operator Helm chart itself does not define <code>registryMigrationMode</code>; 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, when the Operator is installed through the Datadog Agent Helm chart dependency, the Datadog Agent Helm chart's `registryMigrationMode` can use `registry.datadoghq.com` for Agent images managed by the Operator. 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 in this deployment path, set `registryMigrationMode: ""` in your Datadog Agent Helm chart `values.yaml`. This setting has no effect when you explicitly set a registry, and it is not a setting in the standalone Operator Helm chart. 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:
+To use another registry for the Operator pod image, such as `public.ecr.aws/datadog`, when installing the standalone Operator 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 Datadog Agent Helm chart determines the Agent 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. The Datadog Operator chart is included as a dependency of the Datadog Agent Helm chart by default. As of Datadog Operator chart version 2.19.0, when you install the Operator through that dependency, the Datadog Agent Helm chart's `registryMigrationMode` applies to Agent images managed by the Operator. The Operator Helm chart itself does not define `registryMigrationMode`; 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, when the Operator is installed through the Datadog Agent Helm chart dependency, the Datadog Agent Helm chart's `registryMigrationMode` can use `registry.datadoghq.com` for Agent images managed by the Operator. 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 in this deployment path, set `registryMigrationMode: ""` in your Datadog Agent Helm chart `values.yaml`. This setting has no effect when you explicitly set a registry, and it is not a setting in the standalone Operator Helm chart. 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.