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 in three ordered layers. Each layer must be healthy before the next begins.
| Layer | Chart | Scope | Purpose |
|---|---|---|---|
| 1 | cert-manager | Once per cluster | Certificate management. Installed standalone, always first, so its CRDs exist cluster-wide before anything references a Certificate. It is deliberately never bundled as a subchart. |
| 2 | dynamoai-cluster-prereqs | Once per cluster | Shared cluster services: autoscaling, secrets, monitoring, and GPU support. Every component can be disabled if your cluster already provides it (see Advanced Configuration). |
| 3 | dynamoai-platform | Per tenant | The application umbrella chart: API, UI, identity, and the DynamoGuard and DynamoEval workloads. |
Cluster-scoped layers install once and serve every tenant on the cluster. The platform chart installs once per tenant namespace.
All DynamoAI charts are distributed through the OCI registry at artifacts.dynamo.ai (see the artifact access dependency).
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.