Skip to main content

Deploy DIAL on GCP

Deploy the full DIAL stack to Google Kubernetes Engine (GKE) using the umbrella Helm chart, with Cloud Storage for files and Vertex AI as the model provider. This guide assumes you operate a GKE cluster and are familiar with Helm and kubectl. For the chart model and infrastructure mapping, read the Helm chart overview first.

Prerequisites​

  • A GKE cluster, version 1.24 or higher, with kubectl and Helm 3.8.0 or higher configured against it

  • The Ingress-NGINX controller and, optionally, cert-manager installed in the cluster

  • Workload Identity Federation for GKE configured

  • A Cloud Storage bucket for DIAL file storage

  • Vertex AI enabled in your project with at least one model available

  • A Google OAuth client (Google Cloud Console → APIs & Services → Credentials) for DIAL Chat sign-in

  • A domain and a cert-manager ClusterIssuer for TLS

  • The DIAL Helm repository added:

    helm repo add dial https://charts.dialx.ai
    helm repo update

Step 1: Create a values file​

Start from the upstream GCP simple example and fill in your environment. The required values are:

core:
  # Workload Identity Federation service account for Core
  serviceAccount:
    annotations:
      iam.gke.io/gcp-service-account: <GCP_CORE_SERVICE_ACCOUNT>
  env:
    aidial.storage.bucket: <GCP_CORE_STORAGE_BUCKET_NAME>
    aidial.identityProviders.google.userInfoEndpoint: "https://openidconnect.googleapis.com/v1/userinfo"
    aidial.identityProviders.google.rolePath: "fn:getGoogleWorkspaceGroups"
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      cert-manager.io/cluster-issuer: <CLUSTER_ISSUER>
    hosts:
      - dial.<DOMAIN>
    tls:
      - secretName: dial-tls-secret
        hosts:
          - dial.<DOMAIN>

vertexai:
  serviceAccount:
    annotations:
      iam.gke.io/gcp-service-account: <GCP_VERTEXAI_SERVICE_ACCOUNT>
  env:
    aidial.vertexai.project: <GCP_PROJECT_ID>
    aidial.vertexai.region: <GCP_REGION>

chat:
  env:
    AUTH_CALLBACK_BASE_URL: "https://chat.<DOMAIN>"
    AUTH_POST_LOGOUT_REDIRECT_URI: "https://chat.<DOMAIN>"
    DIAL_CORE_URL: "http://dial-core.dial.svc.cluster.local"
    CORS_ORIGIN: "https://chat.<DOMAIN>"
  secrets:
    AUTH_SESSION_SECRET: <AUTH_SESSION_SECRET>
    AUTH_GOOGLE_CLIENT_ID: <AUTH_GOOGLE_CLIENT_ID>
    AUTH_GOOGLE_SECRET: <AUTH_GOOGLE_SECRET>
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      cert-manager.io/cluster-issuer: <CLUSTER_ISSUER>
    hosts:
      - chat.<DOMAIN>
    tls:
      - secretName: chat-tls-secret
        hosts:
          - chat.<DOMAIN>

DIAL Core and DIAL Chat each get their own Ingress-NGINX host and cert-manager-issued certificate, under core.ingress and chat.ingress; see the GCP example - simple for the full values file.

core.env registers Google as the identity provider DIAL Core trusts for user tokens; chat.env/chat.secrets configure DIAL Chat's own sign-in flow against the same OAuth client. In the OAuth client, set the authorized redirect URI to match AUTH_CALLBACK_BASE_URL.

Replace the placeholders:

  • <GCP_CORE_SERVICE_ACCOUNT> — the federated service account for DIAL Core's storage access
  • <GCP_CORE_STORAGE_BUCKET_NAME> — the Cloud Storage bucket name
  • <GCP_VERTEXAI_SERVICE_ACCOUNT> — the service account for Vertex AI access
  • <GCP_PROJECT_ID> — your GCP project ID
  • <GCP_REGION> — the region where Vertex AI models are available
  • <DOMAIN> — your base domain; DIAL Core is exposed at dial.<DOMAIN> and DIAL Chat at chat.<DOMAIN>, for example example.com
  • <AUTH_GOOGLE_CLIENT_ID> — the OAuth client ID
  • <AUTH_GOOGLE_SECRET> — the OAuth client secret
  • <AUTH_SESSION_SECRET> — a random secret DIAL Chat uses to encrypt session cookies
  • <CLUSTER_ISSUER> — the cert-manager issuer, for example letsencrypt-production

Generate the DIAL API key, encryption key, Redis password, and <AUTH_SESSION_SECRET> before installing and supply them as values or Kubernetes secrets.

Step 2: Install the chart​

helm install dial dial/dial \
  -f values.yaml \
  --version <CHART_VERSION> \
  --namespace dial \
  --create-namespace

Pin <CHART_VERSION> to a released chart version.

Step 3: Verify the deployment​

Check that the pods are running:

kubectl get pods -n dial

Once the ingress has an address and both certificates are issued, DIAL Chat is reachable at https://chat.<DOMAIN>/; open it in a browser and sign in with your Google account. Confirm the Unified API responds:

curl https://dial.<DOMAIN>/openai/deployments \
  -H "Api-Key: <YOUR_DIAL_API_KEY>"

Result​

DIAL Core, DIAL Chat, Valkey, and the Vertex AI adapter run on your GKE cluster, with files persisted to Cloud Storage and models served from Vertex AI.

Note

The vertexai alias of the dial chart deploys the standalone Vertex AI adapter, which will be deprecated. DIAL Model Provider replaces it. Deploy it with the DIAL Extension chart and move your models as described in Migrate from the standalone adapters.

Production architecture​

The simple example is a starting point. For a production deployment, size the GCP services and configure redundancy as follows.

GCP serviceConfiguration / tier
Google Kubernetes EngineStandard, regional cluster with zone redundancy
Ingress-NGINX controllerFronted by an internal or external passthrough Network Load Balancer
Cloud StorageStandard, dual-region or multi-region
Memorystore for RedisStandard tier, HA configuration
Vertex AISized to capacity requirements; usage-based pricing

Dependencies whose technology may follow corporate standards:

DependencyGoogle Cloud service
SSOCloud Identity
FirewallCloud Armor for WAF, plus VPC firewall rules
Logging and monitoringGoogle Cloud Observability
Container registryArtifact Registry
Secret storageSecret Manager

Scalability​

DIAL services are stateless, so they run as multiple concurrent copies. As a baseline, run two copies of each service on different nodes for high availability. The services are not resource-intensive and handle thousands of users without further scaling.

To absorb load spikes, configure autoscaling for DIAL Core based on CPU usage (for example, scale out when usage exceeds 80% of the CPU limit for one minute), and enable cluster autoscaling so new nodes are added when existing nodes lack capacity.

Scaling language models is the more common need, because a single model instance is often capped by request rate limits. With Vertex AI there are four levels of scaling, applied in order:

  1. Increase the number of model instances in the same region.
  2. Request a regional quota extension through the GCP console — each region has a fixed tokens-per-minute (TPM) quota per model type.
  3. Deploy model instances in additional regions.
  4. Use multiple GCP projects to access model endpoints.

High availability​

Achieve high availability through regional and multi-zone capabilities: run DIAL service copies in a multi-zone GKE cluster and use highly available configurations for the supporting services.

ServiceAvailability SLAResilient to zone-wide outages
Google Kubernetes Engine99.95% with zone redundancy, otherwise 99.5%Yes, if configured explicitly
Cloud Identity99.9%–99.99%Yes
Cloud Storage99.95% (dual/multi-region), otherwise 99.9%Yes
Memorystore for Redis99.9% with zone redundancyYes, if configured explicitly
Vertex AI99.5%–99.9%Depends on configuration
Secret Manager99.95%Yes
Artifact Registry99.95%Yes (regional)

To improve resilience beyond the Vertex AI SLA, define multiple model endpoints in different regions. If one region becomes unavailable, DIAL automatically tries the next endpoint in the list.

Disaster recovery​

DIAL has two parts with separate recovery policies: DIAL Core and the optional DIAL Analytics.

DIAL Core consists of stateless services plus a single permanent store on Cloud Storage (Memorystore for Redis is a cache and can be safely restarted). For a region-wide failure:

  • Cloud Storage — dual-region or multi-region buckets provide built-in cross-region redundancy. After a regional failure, review and re-establish the multi-region configuration as needed.
  • All other services — being stateless, redeploy the full set in a secondary region and re-route the DIAL domain name to the new entry point. To meet a tight recovery time objective, keep a passive DIAL Core deployment in the secondary region and activate it on failure.

DIAL Analytics keeps ingested rows in ClickHouse and its catalog of tables, pipelines, saved queries, and dashboards in PostgreSQL. Back up PostgreSQL to keep those definitions. Replicate the usage-log blobs it reads like any other permanent store: the backfill endpoint can re-ingest a date range from them, up to BACKFILL_MAX_DAYS days per request.

Further reading​