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, and s390x 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.
Before you begin, be sure to meet the following prerequisites:
Note that the following configurations are not supported in combination with public registries:
Start using these fortified images today for a safer and more efficient containerized monitoring experience:
Dynatrace publishes its container images to Amazon ECR and Docker Hub:
Amazon ECR
Docker Hub
public.ecr.aws/dynatrace/dynatrace-activegate
dynatrace/dynatrace-activegate
public.ecr.aws/dynatrace/dynatrace-codemodules
dynatrace/dynatrace-codemodules
public.ecr.aws/dynatrace/dynatrace-oneagent
dynatrace/dynatrace-oneagent
public.ecr.aws/dynatrace/dynatrace-operator1
dynatrace/dynatrace-operator
public.ecr.aws/dynatrace/dynatrace-k8s-node-config-collector
not available
Available from Dynatrace Operator version 1.0.0
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 or authenticating against the respective 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.
By default, the Dynatrace Operator image dynatrace/dynatrace-operator
is served by the public registry on AWS ECR.
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.
Classic Full-Stack monitoring is not supported in combination with a public registry.
The Dynatrace Operator can easily be instructed to use images from a public registry by configuring the respective image
fields in the DynaKube custom resource. The configured images will be deployed to your Kubernetes cluster to set up monitoring components.
The following DynaKube snippet demonstrates how to configure Cloud-Native Full-Stack monitoring setup leveraging the public Amazon ECR registry.
apiVersion: dynatrace.com/v1beta2kind: DynaKubemetadata:name: dynakubenamespace: dynatracespec:...oneAgent:cloudNativeFullstack:...image: public.ecr.aws/dynatrace/dynatrace-oneagent:<tag>codeModulesImage: public.ecr.aws/dynatrace/dynatrace-codemodules:<tag># autoUpdate: true # has no effect - see note below# version: # has no effect - see note below...activeGate:...image: public.ecr.aws/dynatrace/dynatrace-activegate:<tag>...
Note that the autoUpdate
and version
fields have 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/v1beta2kind: DynaKubemetadata:name: dynakubenamespace: dynatracespec:...oneAgent:applicationMonitoring:...codeModulesImage: public.ecr.aws/dynatrace/dynatrace-codemodules:<tag># autoUpdate: true # has no effect# version: # has no effectuseCSIDriver: true # required; defaults to false...activeGate:...image: public.ecr.aws/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.