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.
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 mirrored. | Cluster nodes pull platform images from this registry at deploy and scale time. | 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 DynamoAI dependency systems deploy successfully from the DynamoAI Helm chart: NVIDIA Device Plugin, Karpenter, KEDA, DynamoAI Operator, OpenTelemetry, and monitoring components. | GPU scheduling, autoscaling, reconciliation, 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. |