Deploy
This guide applies to the current dynamoai-platform chart generation, which installs in three layers. If your environment runs the earlier dynamoai-base three-chart layout, use the Legacy Installation guide instead; your DynamoAI deployment engineer can confirm which generation applies to you.
Before installing, complete the Environment Dependencies checks for your cloud.
Install Order
The platform installs in three ordered layers; each layer must be healthy before the next begins. The Platform Architecture page explains the model in full.
| Layer | Chart | Scope |
|---|---|---|
| 1 | cert-manager: installed standalone, always first, so its CRDs exist cluster-wide before anything references a Certificate. | Once per cluster |
| 2 | dynamoai-cluster-prereqs: shared cluster services (autoscaling, secrets, monitoring, GPU support). Every component can be disabled if your cluster already provides it. | Once per cluster |
| 3 | dynamoai-platform: the application umbrella chart. | Per tenant |
All DynamoAI charts are distributed through the OCI registry at artifacts.dynamo.ai (see the artifact access dependency).
Layer 1: cert-manager
helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \
--version v1.20.2 \
--namespace cert-manager --create-namespace \
--set crds.enabled=true
Installing the platform on a cluster where cert-manager CRDs do not yet exist fails with no matches for kind "Certificate". cert-manager is deliberately never bundled as a subchart.
Layer 2: Cluster Prerequisites
The dynamoai-cluster-prereqs chart installs once per cluster (namespace dynamoai-system). Each component is gated by <component>.enabled and defaults to on; disable anything your cluster already provides. Advanced Configuration explains the bring-your-own model and what happens when a component is disabled.
| Component | Purpose | Disable If You Already Run |
|---|---|---|
| external-dns (DynamoAI wrapper) | DNS record automation | Your own DNS automation, or manage records manually |
| external-secrets (ESO) | Sync secrets from cloud secret managers | Your own secrets operator, or plain Kubernetes Secrets |
| aws-load-balancer-controller | Ingress on EKS (AWS only) | Your own ingress or load-balancer controller |
| keda | Event-driven autoscaling for evaluation workloads | An existing KEDA installation |
| nvidia-device-plugin | GPU scheduling | An existing GPU operator or device plugin |
| dcgm-exporter | GPU metrics | An existing GPU metrics pipeline |
| kube-prometheus-stack | Metrics and alerting | An existing Prometheus stack |
| opentelemetry-collector | Telemetry pipeline | An existing collector |
Cloud safety: the chart refuses to render AWS-only components when the target cloud is set to Azure, GCP, or OpenShift, so a wrong values file fails fast instead of deploying broken components.
helm install dynamoai-cluster-prereqs oci://artifacts.dynamo.ai/charts/dynamoai-cluster-prereqs \
--namespace dynamoai-system --create-namespace \
--values ./prereqs-values.yaml
On AWS/EKS, Karpenter node autoscaling is not part of the prerequisites chart; it requires an IAM role and SQS queue provisioned through infrastructure-as-code first (see the AWS dependencies page).
Layer 3: Platform Chart
helm install dynamoai oci://artifacts.dynamo.ai/charts/dynamoai-platform \
--version <VERSION> \
--namespace <namespace> --create-namespace \
--values ./platform-values.yaml
Configure values against the environment facts you assembled in Environment Dependencies: database endpoints, object storage, domains, and secrets (provided as Kubernetes Secrets, never embedded in values files). Your DynamoAI deployment engineer provides the values interface reference for your platform version.
Create license secrets with echo -n or printf (a trailing newline crash-loops the API), and keep the writable-artifact store separate from the read-only models bucket. Both symptoms are described in Troubleshooting.
Verify
kubectl get pods -n <namespace>
Then run the Deployment Validation checks before handing the environment over for product testing.