Environment Dependencies
This page is the single source of truth for what your environment must provide for a DynamoAI platform deployment. Cloud-agnostic requirements are listed here; cloud-specific details (instance types, managed services, add-ons) live on the cloud pages:
Requirements are grouped by phase. Each row states why the dependency exists and how to verify it. Placeholders such as <domain> and <namespace> are yours to substitute.
Who Provides What
Everything on this page is customer-owned. DynamoAI does not provision or operate your cloud environment; it provides the charts, images, model weights, licence, and the deployment engineering that installs onto what you provide. The full split is in the Deployment Runbook.
Cluster provisioning is deliberately not documented as a procedure here. Managed Kubernetes changes faster than documentation can track it, and every organization provisions through its own approved tooling. What this page gives you instead is the target state your environment must reach and the command that verifies each part of it. When every row verifies, the environment is ready for deployment; that is the exit criterion, however you got there.
Required, Conditional, and Optional
Unless a row says otherwise, everything below is Required. These are the exceptions, and they matter before you source infrastructure:
| Dependency | Status |
|---|---|
| GPU nodes, and the NVIDIA device plugin | Conditional: required only if DynamoGuard is licensed. A DynamoEval-only deployment needs no GPU capacity. |
| Utility LLM | Conditional: required for custom policy creation and DynamoEval data generation. Not needed if you run only foundation guardrails. |
| Ingress controller | Conditional: not required on OpenShift, which uses built-in Routes. |
| KEDA | Conditional: required for event-driven scaling of evaluation and fine-tuning workloads. |
| In-cluster MongoDB, PostgreSQL, MinIO | Conditional: required only where you do not provide a managed equivalent. Production deployments normally provide their own. |
| Entra identity for AI systems | Conditional: required only on Azure, where AI systems or the LLM used for judging and data generation authenticate with Microsoft Entra ID; see the Azure page. |
| Prometheus, OpenTelemetry | Optional: skipping them means no bundled metrics or telemetry pipeline; the platform runs without them. |
Before Deployment
| Dependency | Requirement | Why It Is Needed | Verify |
|---|---|---|---|
| Kubernetes cluster | A conformant Kubernetes cluster with a CNI plugin, CoreDNS, and a CSI storage driver providing a default StorageClass. Node autoscaling must be able to supply CPU and GPU capacity on demand. | Every platform component runs in this cluster; storage provisioning and pod networking are hard prerequisites. | kubectl get nodes returns Ready nodes; kubectl get pods -n kube-system shows CNI, CoreDNS, and CSI pods Running. |
| PostgreSQL | A highly available PostgreSQL instance with the pg_partman and vector (pgvector) extensions available, sized for the deployment region. Two databases must exist: dfl and keycloak. | Primary relational store for the platform and for Keycloak (identity). pg_partman handles table partitioning; vector backs embedding storage. | psql -h <host> -U <user> -l lists dfl and keycloak; SELECT name FROM pg_available_extensions WHERE name IN ('pg_partman', 'vector'); returns both. |
| MongoDB | One of: a customer-provided managed MongoDB endpoint (for example Atlas), or an in-cluster MongoDB deployed by DynamoAI. The choice must be made and documented before deployment; see External MongoDB for the decision criteria. | Document store used by platform services. An undecided option blocks environment configuration. | Connection string reachable from the cluster: kubectl run -it mongosh --rm --image=mongo -- mongosh "<connection-string>" --eval "db.runCommand({ping: 1})" |
| Object storage | S3-compatible object storage with two logical stores: one for model artifacts, one for platform/application artifacts. | Model weights and platform artifacts are pulled from object storage at runtime. | Credentials tested from the cluster; bucket/container names documented for environment configuration. |
| Domain names | Final domain names for apps.<domain>, auth.<domain>, and api.<domain> confirmed in writing. DNS records are not required before deployment. | The three domains are required inputs to environment configuration; changing them later forces reconfiguration. | Written confirmation exists; values entered in the environment configuration. |
| Artifact access | Access to https://artifacts.dynamo.ai/: either allow-listed in network policy, or a mirroring/proxy mechanism that pulls Helm charts, container images, and models into your environment. | All deployment artifacts are distributed through this registry; without access nothing can be installed. | A test pull of a sample chart and image succeeds from inside the environment. |
| Container registry | A container registry the cluster can pull from (for example ECR, ACR, or Artifact Registry), into which DynamoAI images are copied. A pull-through or proxying remote repository is not sufficient on its own; see Container Image Delivery. | Cluster nodes pull platform images from this registry at deploy and scale time. Worker images exceed 5 GiB with a single layer above 4 GiB, which commonly exceeds a proxy's timeout on a cache miss. | A mirrored test image pulls successfully onto a cluster node. |
| Utility LLM | An LLM service for synthetic data generation and judging: an external provider or a sufficiently capable self-hosted endpoint (minimum Llama-8B class, OpenAI-compatible API). | Custom policy creation and DynamoEval data generation call this service. | An authenticated completion request succeeds from inside the cluster. |
| GPU nodes | GPU nodes whose driver supports the CUDA version required by the DynamoGuard inference image (currently CUDA 13.0). Concrete instance types are listed per cloud. | DynamoGuard model inference and training run on these nodes. | GPU nodes join the cluster and advertise nvidia.com/gpu capacity: kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.capacity.nvidia\.com/gpu |
| CPU nodes | General-purpose or compute-optimized CPU node capacity, reliably available. Concrete families are listed per cloud. | DynamoGuard base functions and DynamoEval run on CPU nodes (DynamoEval relies on external LLMs for data generation and judging). | Autoscaling provisions CPU nodes on demand; capacity documented against projected workload. |
| Deployment access | DynamoAI deployment engineers need working access to the target cluster (directly or through a virtual desktop or equivalent), including Kubernetes permissions, CI/CD access, and logging access, plus a named contact who can unblock environment issues promptly. | Deployment stalls measured in days are almost always access stalls; every dependency on this page is verified through this access. | Access validated end to end before the deployment window starts. |
Acceptance criteria detail (expand for the full per-dependency criteria)
- Kubernetes cluster: the CSI driver can provision a test PersistentVolume through the default StorageClass.
- PostgreSQL: deployed across multiple availability zones with automated failover where the environment supports it; instance sizing (vCPU, memory, storage, IOPS) documented against projected workload; connection endpoint, credentials, and network path (security groups, VNet/VPC integration, or firewall rules) confirmed reachable from the cluster.
- MongoDB: if customer-provided: connection configuration, credentials, and network access (IP allow-list or private connectivity) tested from the cluster. If DynamoAI-deployed: persistent storage configured.
- Object storage: least-privilege access scoped per service; names/ARNs documented for environment configuration.
- Artifact access: the chosen access method and its configuration owner are documented.
- Model storage options: three accepted patterns, described in Model Storage.
- Utility LLM options: supported external providers include OpenAI (GPT family), Mistral, and Databricks, or any service compliant with the OpenAI API schema at Llama-8B-class capability or better. Alternatively the utility LLM deploys in-cluster, which requires additional GPU capacity.
- Target AI system integration: external systems with OpenAI-compatible APIs (OpenAI, Azure OpenAI, Databricks, Mistral, AWS Bedrock) integrate out of the box through the UI ("Connect AI System" with "Remote Model"); systems inside the same cluster use "Local Model". Integration happens after deployment.
During Deployment
| Dependency | Requirement | Why It Is Needed | Verify |
|---|---|---|---|
| Kubernetes RBAC | The deployer can create, update, patch, edit, and delete resources in the cluster. | Without these permissions no platform resource can be installed or upgraded. | kubectl auth can-i create deployments -n <namespace> (repeat for update/patch/delete). |
| Node join path | Control-plane-to-node networking works and new nodes join the cluster successfully. | Autoscaling (Karpenter) registers new nodes through this path; a broken join path silently blocks scale-up. | Update a node pool and confirm a new node reaches Ready. |
| Cluster add-on health | CNI plugin, CSI storage driver, CoreDNS, and the ingress/load-balancer controller are healthy. | Each add-on backs one capability: pod networking, volume provisioning, service discovery, ingress traffic. | kubectl get pods -n kube-system shows all add-on pods Running and Ready. |
| Platform dependency systems | The cluster-level dependencies are healthy: NVIDIA device plugin (if GPU workloads are in use), KEDA, OpenTelemetry, and monitoring components. These install alongside the platform rather than as part of it; see Deploy. | GPU scheduling, autoscaling, and observability for DynamoGuard and DynamoEval. | kubectl get pods -n <namespace> shows dependency system pods Running with no CrashLoopBackOff. |
| Storage safety | In-cluster stateful services (for example Redis) use a StorageClass with reclaimPolicy: Retain. Managed databases have deletion protection enabled. | A Delete reclaim policy or an unprotected managed database can silently destroy production data on claim or instance removal. | kubectl get storageclass -o custom-columns=NAME:.metadata.name,RECLAIM:.reclaimPolicy; deletion protection visible in the cloud console. |
| LLM connectivity | The cluster reaches the inference APIs for the model set required by your platform version (currently: Llama 3.1 8B, openai/gpt-4.1-mini, openai/gpt-4.1, mistral/mistral-small; confirm the exact set with your DynamoAI deployment engineer). | DynamoEval and DynamoGuard run core evaluation and guardrail logic against these models; without connectivity both products are non-functional. | curl each endpoint from a pod inside the cluster and confirm an authenticated response. |
| Secrets handling | Application credentials and sensitive configuration are provided as Kubernetes Secrets, not embedded in Helm values. | Values files end up in version control and release history; Secrets prevent credential leakage. | Review values files for credentials; kubectl get secrets -n <namespace> lists the expected Secrets. |
| Target AI system connectivity | The cluster can reach the AI system that will be evaluated and guardrailed. | Evaluating or guardrailing an unreachable system is impossible; this is the basic precondition for both products. | curl the target system endpoint from a pod inside the cluster. |
| External access | The application is exposed through ingress on apps.<domain>, auth.<domain>, and api.<domain>, with certificates, and all three endpoints are verified before handover. | End-to-end usability from outside the cluster is the final precondition for product testing. | All three endpoints respond over HTTPS from the customer network. |
Runtime and Test-Time Dependencies
These do not block installation, but evaluation and guardrail runs fail without them. Surface them to the customer team that operates the platform.
| Dependency | Requirement | Why It Is Needed | Verify |
|---|---|---|---|
| Target endpoint guardrails relaxed for evaluation | Safety guardrails and content filters on the LLM endpoint under test must be disabled or relaxed for DynamoEval runs. | If the target system refuses more than the failure-threshold share of prompts (for example 40% of a batch), the test fails, caused by the target's own guardrails, not the platform. | A sample adversarial prompt batch returns responses rather than refusals before a full test run. |
| External LLM provider health | The external providers used for data generation, attack supplementation, and judging (for example OpenAI, Mistral, Anthropic, Gemini) are healthy. | Provider downtime cascades into downstream attack and judging failures. | Check the provider status page before starting a test run. |
| Provider rate limits | The AI system under test can absorb the test's request volume without rate limiting or timeouts. | Rate-limited responses count as failures and skew results. | Confirm rate limits and quotas against the planned batch size. |
| No concurrent load on a policy | A policy in use by an evaluation run is not concurrently used for benchmarking or load tests. | Resource contention produces inaccurate or failed results for both runs. | Check running tests before starting a new one against the same policy. |
| Supporting infrastructure health | Guardrail pods healthy, no kill signals mid-execution, API not overloaded, databases and managed services responsive. | Test runs fail on unhealthy infrastructure for reasons unrelated to the system under test. | Platform monitoring dashboards show green before long test runs. |