To accommodate diverse infrastructure requirements and organizational preferences, Dynatrace images are available on selected public registries. These images adhere to best practices, ensuring immutability and signing for enhanced security and resilience against potential supply chain risks.
Explore our supported public registries with multi-arch Dynatrace container images supporting ARM64 (AArch64), x86-64, s390x, and PPC64le CPU architectures on Linux, ensuring compatibility across various platforms.
This page provides instructions for using Dynatrace signed and immutable container images hosted on supported public registries.
Start using these fortified images today for a safer and more efficient containerized monitoring experience:
Before you begin, be sure to meet the following prerequisites:
Note that the following configurations are not supported in combination with public registries:
Dynatrace publishes its container images to Amazon ECR Public and Docker Hub. When using automatic image resolution, set spec.publicRegistryOverride to public.ecr.aws for Amazon ECR Public or registry-1.docker.io for Docker Hub to request images from a specific registry.
| Amazon ECR Public | Docker Hub |
|---|---|
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-activegate | registry-1.docker.io/dynatrace/dynatrace-activegate |
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-codemodules | registry-1.docker.io/dynatrace/dynatrace-codemodules |
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-eec | registry-1.docker.io/dynatrace/dynatrace-eec |
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-k8s-node-config-collector | registry-1.docker.io/dynatrace/dynatrace-k8s-node-config-collector |
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-logmodule | registry-1.docker.io/dynatrace/dynatrace-logmodule |
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-oneagent | registry-1.docker.io/dynatrace/dynatrace-oneagent |
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-operator | registry-1.docker.io/dynatrace/dynatrace-operator |
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-otel-collector | registry-1.docker.io/dynatrace/dynatrace-otel-collector |
public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-sql-extension-executor | registry-1.docker.io/dynatrace/dynatrace-sql-extension-executor |
public.ecr.aws/registry-1.docker.io/dynatrace/edgeconnect | registry-1.docker.io/dynatrace/edgeconnect |
Be aware that, when accessing public registries, there is a potential risk of encountering rate limiting. To ensure a smoother experience and reduce this risk, we recommend using a private registry.
Dynatrace employs version-based image tagging for its container images and does not use mutable image tags like latest. For more information on tags, please visit the respective public registry repository.
Dynatrace Operator version 1.10.0+
Dynatrace Operator can automatically resolve the latest public image URIs for managed components from your Dynatrace environment, without manual image field configuration.
When this feature is active, Dynatrace Operator periodically syncs the image references for each component from your Dynatrace environment and applies them automatically.
Remove the image and codeModulesImage fields from your DynaKube if set — their values take precedence over automatically resolved images for the affected component.
Set the feature.dynatrace.com/use-public-registry annotation on your DynaKube:
apiVersion: dynatrace.com/v1beta6kind: DynaKubemetadata:name: dynakubenamespace: dynatraceannotations:feature.dynatrace.com/use-public-registry: "true"spec:apiUrl: https://ENVIRONMENTID.live.dynatrace.com/api...
When your DynaKube uses a platform token, Dynatrace Operator enables public registry resolution automatically. No annotation is required. You can set spec.publicRegistryOverride to use a specific supported public registry.
To request images from a specific supported public registry, set spec.publicRegistryOverride to one of the registry hosts listed in Supported public registries — for example, public.ecr.aws for Amazon ECR Public or registry-1.docker.io for Docker Hub. Dynatrace Operator forwards the host to your Dynatrace environment when resolving image URIs.
spec.templates field.After enabling, confirm that Dynatrace Operator is resolving images from the public registry:
kubectl get dynakube <dynakube-name> -n dynatrace -o jsonpath='{.status.activeGate.source}'
A value of public-registry confirms the ActiveGate image was resolved from the public registry. Check status.oneAgent.source and status.codeModules.source similarly for OneAgent and CodeModules.
The Dynatrace Operator Helm chart is available as an OCI artifact from both Amazon ECR and Docker Hub.
Regardless of which registry you use to pull the chart, container image references default to Amazon ECR. If you install the chart from Docker Hub and want all images pulled from Docker Hub as well, you can use --set imageRef.repository=docker.io/registry-1.docker.io/dynatrace/dynatrace-operator with your helm install or helm upgrade command.
Dynatrace Operator consists of multiple components (operator, webhook, CSI driver), all of which use the same dynatrace-operator image with specific deployment configurations per component.
If you are using Helm version 4.0+, you must use --rollback-on-failure instead of the --atomic flag.
The following command installs Dynatrace Operator and configures container images to be pulled from a public registry:
helm install dynatrace-operator oci://public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-operator \--create-namespace \--namespace dynatrace \--atomic
Alternatively, an existing installation can be upgraded as follows:
helm upgrade dynatrace-operator oci://public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-operator \--reset-then-reuse-values \--atomic \--namespace dynatrace
Classic Full-Stack monitoring is not supported in combination with a public registry.
For PPC64le architecture, additional configuration is required. For details, see ActiveGate container image.
To use images from a public registry, configure the respective image fields in the DynaKube custom resource. Dynatrace Operator then deploys the configured images to your Kubernetes cluster to set up monitoring components. Alternatively, Dynatrace Operator can resolve public image references automatically from your Dynatrace environment, without manual configuration.
The following DynaKube snippet demonstrates how to configure Cloud-Native Full-Stack monitoring setup leveraging the public Amazon ECR registry.
apiVersion: dynatrace.com/v1beta5kind: DynaKubemetadata:name: dynakubenamespace: dynatracespec:...oneAgent:cloudNativeFullstack:...image: public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-oneagent:<tag>codeModulesImage: public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-codemodules:<tag># version: # has no effect - see note below...activeGate:...image: public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-activegate:<tag>...
Note that the version field has no effect when the image and/or codeModulesImage fields are set.
After configuring the required fields, the DynaKube custom resource must be applied to the Kubernetes cluster.
The following custom resource describes how to configure DynaKube for Application Observability and Kubernetes observability:
apiVersion: dynatrace.com/v1beta5kind: DynaKubemetadata:name: dynakubenamespace: dynatracespec:...oneAgent:applicationMonitoring:...codeModulesImage: public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-codemodules:<tag># version: # has no effect...activeGate:...image: public.ecr.aws/registry-1.docker.io/dynatrace/dynatrace-activegate:<tag>...
All of our immutable and signed container images adhere to best practices, enhancing security and shielding against supply chain attacks. To learn how to verify signatures and guarantee software integrity, see Verify Dynatrace image signatures.