Helm chart overview
DIAL ships as a set of Helm charts that deploy the platform to any Kubernetes cluster. This page explains what the charts are, how they map to your cloud infrastructure, and how to choose a deployment path. It is for DevOps and platform engineers who already run Kubernetes and want to understand the deployment model before following a provider-specific guide.
For running DIAL on a single machine without Kubernetes, see Local setup instead.
The DIAL Helm charts
DIAL publishes its charts to the registry at https://charts.dialx.ai. Add the repository once:
helm repo add dial https://charts.dialx.ai
helm repo update
The repository contains four charts: the platform assembly, standalone Core, container-based extensions, and Admin. Their roles, dependencies, default images, and releases are documented in Services > DIAL Helm. The configuration reference explains the value scopes and the boundary between Helm values and service settings.
The umbrella dial chart is the entry point for a cluster deployment:
helm install dial dial/dial -f values.yaml --version <CHART_VERSION> --namespace dial
Pin <CHART_VERSION> to a released chart version rather than tracking latest, so upgrades are deliberate.
How DIAL maps to cloud infrastructure
DIAL is cloud-agnostic. The same charts run on AWS, Azure, GCP, or a self-managed cluster — only the backing services and credentials change. A production deployment relies on four classes of infrastructure:
| Class | Purpose | AWS | Azure | GCP |
|---|---|---|---|---|
| Object storage | Permanent storage for user and system files | S3 | Azure Blob Storage | Cloud Storage |
| Cache | Volatile cache for DIAL Core | ElastiCache | Azure Cache for Redis | Memorystore for Redis |
| Model provider | Language models behind an adapter | Bedrock | Azure OpenAI | Vertex AI |
| Identity provider | Authentication via OpenID Connect / OAuth2 | Cognito | Microsoft Entra ID | Cloud Identity |
DIAL Core stores resources outside its service instances. Valkey can hold pending writes before synchronization to object storage, so recovery must account for both stores. See State and data lifecycle.
The example-based deployment model
The Helm repository provides ready-made value files for each cloud under charts/dial/examples/<cloud>/, in two variants:
simple— a minimal, single-provider install for evaluation and lower environments. The provider guides in this section are built on these examples.complete— a production-leaning configuration with a managed Redis-compatible cache, an identity provider, and multiple model providers.
The simple examples omit production concerns such as authentication, encryption, and high availability. Do not run them in production unmodified. See the Production architecture section of each provider guide for hardening guidance.
Choosing a deployment path
| Your target | Guide |
|---|---|
| Amazon EKS with S3 and Bedrock | AWS deployment |
| Azure AKS with Blob Storage and Azure OpenAI | Azure deployment |
| Google GKE with Cloud Storage and Vertex AI | GCP deployment |
| A self-managed or on-premises cluster | Generic Kubernetes |
| Reading secrets from Azure Key Vault | Azure Secrets deployment |
| Deploying your own application alongside DIAL | Custom Apps deployment |
| Enabling the Quick Apps feature | Quick Apps installation |
| Running the DIAL Admin interface | DIAL Admin installation |