Platform Architecture
This page explains how a DynamoAI deployment is structured. Read it before your first deployment; the Deploy guide assumes this mental model.
Install Model
The platform installs as a set of Helm charts. dynamoai-base carries the shared platform and is always installed first; the product charts install on top of it.
| Chart | Scope | Purpose |
|---|---|---|
| Cluster dependencies | Once per cluster | NVIDIA device plugin, an ingress controller or OpenShift Routes, KEDA, Prometheus, and OpenTelemetry. Install only what your cluster does not already provide. |
dynamoai-base | Per deployment | API, UI, Keycloak identity, core services, and the datastore wiring every other chart reads. |
dynamoai-dynamoguard | Per deployment | Guardrail inference services, custom policy fine-tuning, and model serving. |
dynamoai-dynamoeval | Per deployment | Evaluation workers and job orchestration. |
Which product charts you install depends on your licence: DynamoGuard, DynamoEval, or both. Neither depends on the other, so they install in either order, or one now and the other later. All three charts share one global configuration block, and the Secret and ConfigMap names in that block must match across them.
Chart versions move independently of the application version they carry; all three currently ship application version 3.26.5.
Where State Lives
The platform keeps no durable state inside its own pods. Each store below is a hard dependency, defined in full in the Environment Dependencies registry:
| Store | Backing Service | Holds |
|---|---|---|
| Relational data | PostgreSQL (dfl and keycloak databases) | Platform records and Keycloak identity data |
| Document data | MongoDB (managed endpoint or in-cluster, see External MongoDB) | Document store used by platform services |
| Job queue and progress | Redis (Celery broker and result backend) | Evaluation job queue and transient task state |
| Model artifacts | Object storage, read-only store | Model weights pulled at runtime |
| Platform artifacts | Object storage, writable store | Platform and application artifacts |
Redis carries two Celery connections: the broker, which is the evaluation job queue, and the result backend, which holds task state. Both use logical database 0 by default, and their keys live in separate namespaces, so a single-database managed cache is sufficient. Moving the result backend onto its own logical database is optional and covered in Enable Redis Authentication & TLS.
The two object stores must stay separate; pointing writable-artifact configuration at the read-only models bucket causes runtime AccessDenied failures (see Troubleshooting).
Compute Profile
Platform services (API, UI, identity) run on CPU nodes. DynamoGuard model inference and training run on GPU nodes; DynamoEval runs on CPU nodes and calls external LLM endpoints for data generation and judging. Sizing guidance lives in Resource Guidelines.