Version: Latest (1.9.x dev)

Cloud Provider Deployment

Deploy DVARA on AWS (EKS or ECS), Google Cloud, Azure, or DigitalOcean with provider-specific configurations and best practices.

Most sections below target managed Kubernetes and build on the Kubernetes / Helm chart — read that first. The AWS (ECS) section is the exception: it covers a Fargate-based deployment that skips Kubernetes entirely.

From 1.8.2 the gateway has no database

Only DVARA Flightdeck connects to PostgreSQL, and only Flightdeck runs schema migrations. Each gateway:

enrols with Flightdeck on first start, using a shared enrolment secret, and gets a certificate for Flightdeck's internal channel on port 8443;
reads its configuration as a signed bundle from Flightdeck. A change saved in Flightdeck reaches a gateway in about 10 seconds at the default settings, with no restart;
writes audit, usage and cost records to a local spool on its own data volume and ships them to Flightdeck, which stores them (about 30 seconds at the defaults).

So every managed database below is for Flightdeck only. Give the gateway no SPRING_DATASOURCE_* settings: a gateway given SPRING_DATASOURCE_URL refuses to start, and a helm upgrade that sets one in llmGatewayServer.extraEnv is refused. DVARA_DB_MIGRATE, DVARA_DB_POOL_SIZE and DVARA_DB_SOCKET_TIMEOUT_SECONDS are no longer read on the gateway.

The Helm chart wires the rest for you. It generates the enrolment secret on install (secrets.enrolmentSharedSecret) and keeps it across upgrades, serves Flightdeck's internal channel through a <flightdeck>-internal Service, and gives each gateway pod a data volume. Two cases need you to act:

With secrets.existingSecret, that Secret must carry the key enrolment-shared-secret (at least 32 characters, for example openssl rand -base64 32).
When you render with helm template or Argo CD, set secrets.enrolmentSharedSecret explicitly. Those tools cannot read the existing value back and would make a new one on every render.

The gateway's data volume is an emptyDir by default. It survives a container restart but not the pod's deletion, so undelivered records are lost only if a pod dies without its shutdown flush. For production, set llmGatewayServer.persistence.enabled: true: each pod then gets its own volume at /var/lib/dvara, and the gateway runs as a StatefulSet.

AWS (EKS)

Prerequisites

eksctl or an existing EKS cluster (Kubernetes 1.28+)
AWS CLI configured with appropriate permissions
Helm 3.x installed

Create an EKS Cluster

eksctl create cluster \
  --name dvara \
  --region us-east-1 \
  --nodegroup-name standard \
  --node-type m6i.large \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 5 \
  --managed

Install the AWS Load Balancer Controller

Required for ALB-based Ingress:

# Install the controller (see AWS docs for full IAM setup)
helm repo add eks https://aws.github.io/eks-charts
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=dvara \
  --set serviceAccount.create=true

Store Secrets in AWS Secrets Manager

# Create the secret
aws secretsmanager create-secret \
  --name dvara/provider-credentials \
  --secret-string '{
    "openai-api-key": "sk-...",
    "anthropic-api-key": "sk-ant-...",
    "enterprise-license-key": "DVARA-..."
  }'

Use the External Secrets Operator to sync into Kubernetes:

# external-secret.yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: dvara-provider-keys
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: dvara-external
  data:
    - secretKey: openai-api-key
      remoteRef:
        key: dvara/provider-credentials
        property: openai-api-key
    - secretKey: anthropic-api-key
      remoteRef:
        key: dvara/provider-credentials
        property: anthropic-api-key
    - secretKey: enterprise-license-key
      remoteRef:
        key: dvara/provider-credentials
        property: enterprise-license-key

kubectl apply -f external-secret.yaml

Deploy with ALB Ingress + IRSA

# aws-values.yaml
llmGatewayServer:
  replicaCount: 3
  javaOpts: "-Xms512m -Xmx768m"

  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/dvara-gateway

  autoscaling:
    enabled: true
    minReplicas: 3
    maxReplicas: 10
    targetCPUUtilizationPercentage: 70

  pdb:
    enabled: true
    minAvailable: 2

  serviceMonitor:
    enabled: true
    additionalLabels:
      release: kube-prometheus-stack

  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app.kubernetes.io/component: gateway-server

flightdeck:
  enabled: true

secrets:
  create: false
  existingSecret: dvara-external

ingress:
  enabled: true
  className: alb
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:123456789012:certificate/abc-123
    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06
    alb.ingress.kubernetes.io/healthcheck-path: /actuator/health/readiness
  llmGatewayServer:
    hosts:
      - host: gateway.mycompany.com
        paths:
          - path: /
            pathType: Prefix
  flightdeck:
    hosts:
      - host: admin.mycompany.com
        paths:
          - path: /
            pathType: Prefix

helm install dvara charts/dvara/ --version 1.8.5 -f aws-values.yaml

AWS Bedrock with explicit credentials

DVARA 1.8 does not use IRSA or the AWS SDK default credential chain for Bedrock. Give the DVARA LLM Gateway an explicit access-key and secret-key pair whose IAM principal can invoke the Bedrock models on your routes.

# bedrock-values.yaml
secrets:
  bedrockEnabled: "true"
  providerKeys:
    awsAccessKeyId: <aws-access-key-id>
    awsSecretAccessKey: <aws-secret-access-key>

helm install dvara charts/dvara/ --version 1.8.5 -f bedrock-values.yaml

For production, put these values in an externally managed Kubernetes Secret and set secrets.create: false with secrets.existingSecret. The Secret keys are aws-access-key-id, aws-secret-access-key, and bedrock-enabled.

Database for Flightdeck

DVARA Flightdeck requires PostgreSQL. From 1.8.2 the gateway has no database, so only Flightdeck gets the connection settings. Rate limiting and API-key caching run in the gateway process — no external cache infrastructure is required.

RDS PostgreSQL:

aws rds create-db-instance \
  --db-instance-identifier dvara-db \
  --db-instance-class db.r6g.large \
  --engine postgres --engine-version 14 \
  --master-username dvara --master-user-password "${DB_PASSWORD}" \
  --allocated-storage 100 --storage-encrypted \
  --vpc-security-group-ids sg-... --db-subnet-group-name dvara-subnet

Helm values for the database (Flightdeck only):

flightdeck:
  extraEnv:
    - name: SPRING_DATASOURCE_URL
      value: "jdbc:postgresql://dvara-db.xxx.us-east-1.rds.amazonaws.com:5432/dvara"
    - name: SPRING_DATASOURCE_USERNAME
      value: "dvara"
    - name: SPRING_DATASOURCE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: dvara-db-credentials
          key: password

Multi-Region on AWS

Primary region (us-east-1):

# primary-values.yaml
llmGatewayServer:
  replicaCount: 3
  region:
    id: us-east-1
    name: US East
  autoscaling:
    enabled: true
    minReplicas: 3
    maxReplicas: 10

flightdeck:
  enabled: true

secrets:
  providerKeys:
    openai: sk-...
  # The secret every gateway enrols with. Set it explicitly here, because the
  # secondary region's release must carry the same value.
  enrolmentSharedSecret: "<openssl rand -base64 32>"
  enterpriseLicenseKey: "DVARA-..."

Secondary region (eu-west-1) — a gateway-only release that gets its configuration from the primary region's Flightdeck:

# secondary-eu-values.yaml
llmGatewayServer:
  replicaCount: 2
  region:
    id: eu-west-1
    name: EU West
  autoscaling:
    enabled: true
    minReplicas: 2
    maxReplicas: 10

# From 1.8.2 the gateway has no database. It enrols with the primary region's
# Flightdeck and reads its configuration as a signed bundle from there, so this
# region needs a network path to Flightdeck's internal port (8443), not to
# PostgreSQL.
dataPlane:
  controlPlane:
    baseUrl: "https://dvara-flightdeck-internal.us-east-1.internal.mycompany.com:8443"

flightdeck:
  enabled: false

secrets:
  providerKeys:
    openai: sk-...
  enrolmentSharedSecret: "<the same value as the primary region>"

The host name in baseUrl must be one of the names in Flightdeck's internal certificate. Set them on the primary Flightdeck with DVARA_INTERNAL_ENROLMENT_SERVER_NAMES (through flightdeck.extraEnv).

# Deploy primary in us-east-1
kubectl config use-context us-east-1
helm install dvara charts/dvara/ --version 1.8.5 -f primary-values.yaml

# Deploy secondary in eu-west-1
kubectl config use-context eu-west-1
helm install dvara-eu charts/dvara/ --version 1.8.5 -f secondary-eu-values.yaml

AWS (ECS)

AWS ECS on Fargate is a lower-operational-overhead alternative to EKS. If you don't want to run a Kubernetes control plane, ECS runs the same DVARA container images (ghcr.io/dvarahq/dvara-*) as serverless tasks behind an Application Load Balancer.

From 1.8.2 only DVARA Flightdeck connects to RDS PostgreSQL. The gateway has no database: it enrols with Flightdeck, reads its configuration as a signed bundle from Flightdeck's internal port (8443), and keeps a local spool of audit, usage and cost records that it ships to Flightdeck. That spool is state. A gateway task flushes it when ECS stops the task, so give the task enough stop time (below).

Prerequisites

AWS CLI configured with an account that can create ECS clusters, task definitions, Secrets Manager secrets, and ALBs
An existing VPC with at least two private subnets (for Fargate tasks) and two public subnets (for the ALB)
A running RDS PostgreSQL instance reachable from the VPC's private subnets (see Database Requirements)
At least one provider API key

Store secrets in AWS Secrets Manager

DVARA has first-class AWS Secrets Manager support, so you can either reference secrets directly at task-definition time (recommended — injected as env vars by ECS) or let DVARA fetch them at runtime via the vault integration.

aws secretsmanager create-secret \
  --name dvara/license \
  --secret-string "DVARA-...your-license-key"

aws secretsmanager create-secret \
  --name dvara/openai \
  --secret-string "sk-..."

aws secretsmanager create-secret \
  --name dvara/db \
  --secret-string '{"username":"dvara","password":"..."}'

# The secret every gateway enrols with Flightdeck by. At least 32 characters.
aws secretsmanager create-secret \
  --name dvara/enrolment \
  --secret-string "$(openssl rand -base64 32)"

dvara/db goes to the Flightdeck task only. dvara/enrolment goes to both tasks.

Task execution role

The ECS task execution role needs permission to pull from GHCR (via a secret holding a GHCR personal access token), read the secrets you just created, and write to CloudWatch Logs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "kms:Decrypt"
      ],
      "Resource": [
        "arn:aws:secretsmanager:us-east-1:<account>:secret:dvara/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

Task definition

Register one task definition with both gateway-server and gateway-ui as containers in the same task (simple), or split them across two task definitions to scale independently (recommended for production). This example shows the split:

{
  "family": "dvara-gateway",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "1024",
  "memory": "2048",
  "executionRoleArn": "arn:aws:iam::<account>:role/dvara-ecs-task-exec",
  "taskRoleArn": "arn:aws:iam::<account>:role/dvara-ecs-task",
  "containerDefinitions": [
    {
      "name": "gateway-server",
      "image": "ghcr.io/dvarahq/dvara-gateway:1.8.5",
      "essential": true,
      "stopTimeout": 65,
      "portMappings": [
        { "containerPort": 8080, "protocol": "tcp" }
      ],
      "secrets": [
        { "name": "OPENAI_API_KEY", "valueFrom": "arn:aws:secretsmanager:us-east-1:<account>:secret:dvara/openai" },
        { "name": "DVARA_DATA_PLANE_CONTROL_PLANE_ENROLMENT_SHARED_SECRET", "valueFrom": "arn:aws:secretsmanager:us-east-1:<account>:secret:dvara/enrolment" }
      ],
      "environment": [
        { "name": "DVARA_DATA_PLANE_CONTROL_PLANE_BASE_URL", "value": "https://flightdeck.dvara.local:8443" },
        { "name": "DVARA_DATA_PLANE_CONTROL_PLANE_ENROLMENT_DIRECTORY", "value": "/var/lib/dvara/enrolment" },
        { "name": "DVARA_DATA_PLANE_CONTROL_PLANE_SNAPSHOT_PATH", "value": "/var/lib/dvara/bundle-snapshot.json" },
        { "name": "DVARA_LLM_GATEWAY_LOCAL_STORE_PATH", "value": "/var/lib/dvara/spool.db" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/dvara/gateway-server",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      },
      "healthCheck": {
        "command": ["CMD", "curl", "-sf", "http://localhost:8080/actuator/health"],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 60
      }
    }
  ]
}

aws ecs register-task-definition --cli-input-json file://dvara-gateway-taskdef.json

aws ecs create-service \
  --cluster dvara \
  --service-name dvara-gateway \
  --task-definition dvara-gateway \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-aaa,subnet-bbb],securityGroups=[sg-dvara],assignPublicIp=DISABLED}" \
  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:...:targetgroup/dvara-gateway/xxx,containerName=gateway-server,containerPort=8080"

The gateway task has no database settings. From 1.8.2 a gateway given SPRING_DATASOURCE_URL refuses to start. It also refuses to start without DVARA_DATA_PLANE_CONTROL_PLANE_BASE_URL (Flightdeck) or DVARA_LLM_GATEWAY_LOCAL_STORE_PATH (the spool).

The spool, the bundle snapshot and the enrolment files live under /var/lib/dvara, on the task's own storage. stopTimeout: 65 gives the gateway time to finish in-flight calls and then flush its spool (up to 20 seconds) when ECS stops the task. A task that is killed without that flush loses the records it had not yet shipped. Do not point several tasks at one shared directory (for example one EFS path): each gateway needs its own spool. A task that starts on empty storage enrols again with the shared secret.

Create a similar task definition and service for dvara-flightdeck (port 8090, image ghcr.io/dvarahq/dvara-flightdeck:1.8.5). Flightdeck is the only task that gets the database settings. It needs:

SPRING_DATASOURCE_URL, and SPRING_DATASOURCE_USERNAME and SPRING_DATASOURCE_PASSWORD from dvara/db;
DVARA_INTERNAL_ENROLMENT_ENABLED=true, DVARA_INTERNAL_ENROLMENT_SERVER_NAMES=flightdeck.dvara.local (the name gateways use to reach it), and DVARA_INTERNAL_ENROLMENT_SHARED_SECRET from dvara/enrolment;
DVARA_FLIGHTDECK_GATEWAY_URL pointing at the dvara-gateway ALB target group or the ALB's internal URL;
DVARA_AUDIT_HMAC_SECRET, the same value the gateway tasks get;
DVARA_ENCRYPTION_MASTER_PASSWORD, the same value the gateway tasks get, so Flightdeck can store BYOK provider credentials;
optionally DVARA_PII_TOKEN_ENCRYPTION_MASTER_PASSWORD, which Flightdeck seals each workspace's PII token key with. Only Flightdeck needs it. Without it, pii.action=TOKENIZE is unavailable and each workspace's pii.degraded-action applies;
port 8443 open to the gateway tasks' security group, and the service registered in Cloud Map as flightdeck.dvara.local.

Start Flightdeck first. A gateway enrols with it when it starts, and ECS restarts a gateway task that gave up waiting.

The Gateway task needs no licence secret. From 1.8.2 the licence is stored in Flightdeck and reaches every Gateway pod in the configuration bundle. Paste it on Flightdeck's License page, or give the Flightdeck task DVARA_LICENSE_KEY from dvara/license, which Flightdeck copies into its store once, when none is stored.

Application Load Balancer

Create an ALB with two target groups — one for gateway-server (port 8080) and one for gateway-ui (port 8090). Route /v1/* to the gateway target group and everything else to the DVARA Flightdeck target group, or use two separate ALBs / listener rules.

Health check paths on the ALB target groups:

dvara-gateway target group: GET /actuator/health (port 8080) — anonymous, no Bearer needed
dvara-admin target group: GET /actuator/health/readiness (port 8090)

Clustering on Fargate

DVARA LLM Gateway instances share rate-limit counters and API key lookups across the fleet. On Fargate, the tasks need to discover each other. Fargate doesn't support multicast, so configure TCP-IP discovery via AWS ECS service discovery (Cloud Map):

Create a Cloud Map namespace (e.g., dvara.local) attached to your VPC.
Register the dvara-gateway service with Cloud Map — this gives every task an A record at gateway-server.dvara.local.
Point the cluster's TCP-IP discovery member list at gateway-server.dvara.local so new tasks find their siblings via DNS resolution. The exact env-var name is documented in Configuration → Rate Limiting; set it on every gateway-server task.

See Configuration → Rate Limiting for the full property list.

Auto scaling

Use ECS service auto scaling with target tracking on ECSServiceAverageCPUUtilization or a custom CloudWatch metric (e.g., gateway_requests_total rate scraped from Prometheus via the AWS Distro for OpenTelemetry collector).

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/dvara/dvara-gateway \
  --min-capacity 3 \
  --max-capacity 20

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/dvara/dvara-gateway \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration file://cpu-tracking.json

Observability

Logs — DVARA emits structured JSON by default. Point the awslogs log driver at CloudWatch Logs, then ship to your SIEM via subscription filters (Kinesis Firehose → S3 / OpenSearch / Splunk).
Metrics — use AWS Distro for OpenTelemetry (ADOT) as a sidecar container to scrape /actuator/prometheus on each task and forward to Amazon Managed Prometheus or CloudWatch. The scrape requires Authorization: Bearer $DVARA_ACTUATOR_METRICS_API_KEY — mount the metrics key as a file (for example via Secrets Manager) and configure the ADOT receiver's bearer_token_file. The metrics secret is intentionally distinct from DVARA_ACTUATOR_API_KEY so a leaked scrape token can't unlock the rich gateway status surface.
Tracing — set OTEL_EXPORTER_OTLP_ENDPOINT to the ADOT sidecar (http://localhost:4318/v1/traces) to ship traces to AWS X-Ray.

When to choose ECS over EKS

	ECS (Fargate)	EKS
Cluster ops	None (serverless)	Control plane + node groups
Helm / kubectl	No	Yes
Right for	Small-to-medium deployments, teams without Kubernetes expertise	Large fleets, teams already running Kubernetes
DVARA features	All	All
Cost model	Pay per task	Pay per node + control plane

ECS is the simpler path if you're new to AWS or don't already have Kubernetes in production. EKS wins once you need advanced networking (Istio, Linkerd), custom autoscaling, or already have a fleet of charts to reuse.

Google Cloud (GKE)

Run DVARA on GKE with Cloud SQL (managed PostgreSQL for Flightdeck, private IP), Workload Identity for secrets, and a GCE Ingress fronted by a Google-managed TLS certificate. This builds on the Kubernetes / Helm chart — read that first.

Scripted recipe

A complete, runnable version of everything below — gcloud provisioning + helm install + verification in one script — lives in kubernetes/gke/ in dvara-examples. This page is the explained walkthrough; the recipe is the copy-paste path.

Prerequisites

gcloud CLI authenticated against a billing-enabled project
kubectl and Helm 3.8+
A DVARA licence envelope (DVARA-…) only when you need Enterprise Production posture; see Licensing

Create a VPC-native GKE cluster

Workload Identity (--workload-pool) and VPC-native networking (--enable-ip-alias) are both required — the first lets pods authenticate to Google APIs without static keys; the second lets the cluster reach Cloud SQL over a private IP.

PROJECT_ID=my-project
gcloud container clusters create dvara \
  --region us-central1 \
  --num-nodes 1 \
  --release-channel regular \
  --enable-ip-alias \
  --workload-pool="${PROJECT_ID}.svc.id.goog"

gcloud container clusters get-credentials dvara --region us-central1
kubectl create namespace dvara

Cloud SQL (private IP)

Cloud SQL is Flightdeck's database. From 1.8.2 the gateway has no database: it reads route and policy changes as a signed bundle from Flightdeck, about 10 seconds after you save them at the default settings, with no restart.

# One-time: private services access so Cloud SQL gets a private IP
gcloud compute addresses create google-managed-services-default \
  --global --purpose=VPC_PEERING --prefix-length=16 --network=default
gcloud services vpc-peerings connect \
  --service=servicenetworking.googleapis.com \
  --ranges=google-managed-services-default --network=default

# Private-IP-only Postgres 16 instance
# --edition=ENTERPRISE is required: new Cloud SQL instances default to
# ENTERPRISE_PLUS, which rejects db-custom-* tiers (it wants db-perf-optimized-*).
gcloud sql instances create dvara-pg \
  --database-version=POSTGRES_16 --tier=db-custom-1-3840 --edition=ENTERPRISE \
  --region=us-central1 \
  --network="projects/${PROJECT_ID}/global/networks/default" \
  --no-assign-ip
gcloud sql databases create dvara --instance=dvara-pg
gcloud sql users create dvara --instance=dvara-pg --password="${DB_PASSWORD}"

# Capture the private IP for the JDBC URL below
gcloud sql instances describe dvara-pg \
  --format='value(ipAddresses.filter("type=PRIVATE").extract("ipAddress").flatten())'

Why private IP, not the Cloud SQL Auth Proxy

The Auth Proxy normally runs as a per-pod sidecar, and the DVARA chart has no extraContainers knob to inject one. Private IP needs no sidecar — Flightdeck connects with a plain JDBC URL.

Workload Identity for secrets

Make Google Secret Manager the source of truth and sync into Kubernetes with the External Secrets Operator, authenticated by the pods' Workload-Identity-bound service account — no secret ever rides a helm --set command line.

DVARA needs six operational secrets (each openssl rand -base64 32 except the license):

Secret (k8s key)	Purpose
`enterprise-license-key`	Optional signed `DVARA-…` envelope. Flightdeck copies it into its licence store once, when none is stored; Gateway pods do not read it. You can paste the licence on Flightdeck's License page instead.
`gateway-encryption-master-password`	AES-256-GCM key for `ENCRYPTED`-mode provider credentials — loss is unrecoverable, escrow offline
`gateway-server-api-key`	Operator bearer for `/actuator/gateway-status` and Enterprise `/actuator/license`
`gateway-metrics-api-key`	Bearer for `/actuator/prometheus` — must differ from the above
`audit-hmac-secret`	HMAC-SHA256 key signing the audit chain
`enrolment-shared-secret`	The secret gateways enrol with Flightdeck by (from 1.8.2). At least 32 characters. With `secrets.existingSecret` the chart does not generate it, so this Secret must carry it

# Push to Secret Manager
for s in license-key encryption-master-password actuator-api-key \
         actuator-metrics-api-key audit-hmac-secret enrolment-shared-secret; do
  gcloud secrets create "dvara-${s}" --replication-policy=automatic
done
# (add a version to each with `gcloud secrets versions add … --data-file=-`)

# GCP service account + Workload Identity binding to the chart's two KSAs
gcloud iam service-accounts create dvara-gke
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:dvara-gke@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"
for ksa in dvara-gateway-server dvara-flightdeck; do
  gcloud iam service-accounts add-iam-policy-binding \
    "dvara-gke@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:${PROJECT_ID}.svc.id.goog[dvara/${ksa}]"
done

# external-secret.yaml — syncs Secret Manager → the k8s Secret the chart consumes
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: dvara-platform
  namespace: dvara
spec:
  refreshInterval: 1h
  secretStoreRef: { name: gcp-secret-manager, kind: ClusterSecretStore }
  target: { name: dvara-platform }
  data:
    - { secretKey: enterprise-license-key,             remoteRef: { key: dvara-license-key } }
    - { secretKey: gateway-encryption-master-password, remoteRef: { key: dvara-encryption-master-password } }
    - { secretKey: gateway-server-api-key,             remoteRef: { key: dvara-actuator-api-key } }
    - { secretKey: gateway-metrics-api-key,            remoteRef: { key: dvara-actuator-metrics-api-key } }
    - { secretKey: audit-hmac-secret,                  remoteRef: { key: dvara-audit-hmac-secret } }
    - { secretKey: enrolment-shared-secret,            remoteRef: { key: dvara-enrolment-shared-secret } }

Provider keys aren't here

DVARA uses the BYOK model — workspace provider keys live AES-encrypted in Flightdeck's database and are added via the Flightdeck after install, not as env vars. The chart's provider-key references are all optional: true, so the synced Secret only needs the six platform keys above.

Deploy with GCE Ingress + managed TLS

# gke-values.yaml
llmGatewayServer:
  replicaCount: 2
  javaOpts: "-Xms256m -Xmx768m"
  serviceAccount:
    create: true
    name: dvara-gateway-server          # pinned → matches the WI binding above
    annotations:
      iam.gke.io/gcp-service-account: dvara-gke@my-project.iam.gserviceaccount.com
  # No database settings: from 1.8.2 the gateway has none. Give each pod its
  # own volume for the spool, the bundle snapshot and the enrolment files.
  persistence: { enabled: true }
  pdb: { enabled: true, minAvailable: 1 }

flightdeck:
  enabled: true
  serviceAccount:
    create: true
    name: dvara-flightdeck
    annotations:
      iam.gke.io/gcp-service-account: dvara-gke@my-project.iam.gserviceaccount.com
  extraEnv:
    - { name: SPRING_DATASOURCE_URL, value: "jdbc:postgresql://CLOUDSQL_PRIVATE_IP:5432/dvara?sslmode=require" }
    - { name: SPRING_DATASOURCE_USERNAME, value: "dvara" }
    - name: SPRING_DATASOURCE_PASSWORD
      valueFrom: { secretKeyRef: { name: dvara-db, key: password } }

secrets:
  create: false
  existingSecret: dvara-platform        # synced by External Secrets above

# GCE Ingress: explicit hosts + empty tls so NO spec.tls renders — Google
# managed certs are driven by the annotation + the ManagedCertificate CRD.
ingress:
  enabled: true
  className: gce
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "dvara-ip"
    networking.gke.io/managed-certificates: "dvara-cert"
    kubernetes.io/ingress.allow-http: "false"
  llmGatewayServer:
    hosts: [{ host: api.mycompany.com, paths: [{ path: /, pathType: Prefix }] }]
    tls: []
  flightdeck:
    hosts: [{ host: flightdeck.mycompany.com, paths: [{ path: /, pathType: Prefix }] }]
    tls: []

# managed-certificate.yaml
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata: { name: dvara-cert, namespace: dvara }
spec:
  domains: [api.mycompany.com, flightdeck.mycompany.com]

# Reserve the static IP the Ingress annotation references
gcloud compute addresses create dvara-ip --global

kubectl -n dvara create secret generic dvara-db --from-literal=password="${DB_PASSWORD}"
kubectl -n dvara apply -f external-secret.yaml
kubectl -n dvara apply -f managed-certificate.yaml

helm install dvara oci://ghcr.io/dvarahq/charts/dvara \
  --version 1.8.5 \
  --namespace dvara \
  --values gke-values.yaml \
  --set llmGatewayServer.image.tag=1.8.5 \
  --set flightdeck.image.tag=1.8.5 \
  --wait

Pin the image tag — never :latest

The chart version and image tags above are pinned to 1.8.5, a published release on GHCR. Pin a real, published tag so the deploy is reproducible and rollbacks are clean — :latest is a moving pointer and can change under you. When a newer release is published, bump these to that version. Don't pin a tag that hasn't shipped yet, or pods fail with ImagePullBackOff.

After DNS A-records for both hosts point at the static IP, the Google-managed certificate provisions in 15–60 minutes (kubectl -n dvara describe managedcertificate dvara-cert → status Active). The Ingress serves HTTP 503 until then.

Verify (including config hot-reload)

kubectl -n dvara get pods                                    # all Ready
kubectl -n dvara port-forward svc/dvara-flightdeck 8090:8090 &
open http://localhost:8090/                                  # walk /setup → workspace + API key

The chart-specific acceptance check is config hot-reload: create or edit a route in the Flightdeck, fire a request through the gateway, and confirm the new routing takes effect without restarting any pod. Allow about 10 seconds: Flightdeck republishes the signed bundle and each gateway fetches it. That proves the gateway enrolled with Flightdeck and is receiving its configuration.

Gemini / Vertex AI (optional)

The same Workload-Identity service account can grant Vertex AI access without an API key:

gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:dvara-gke@my-project.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

Or pass a Gemini API key as a BYOK credential in the Flightdeck.

Azure (AKS)

Prerequisites

Azure CLI configured
An existing AKS cluster or permissions to create one
Helm 3.x installed

Create an AKS Cluster

az group create --name dvara-rg --location eastus

az aks create \
  --resource-group dvara-rg \
  --name dvara \
  --node-count 3 \
  --node-vm-size Standard_D4s_v3 \
  --enable-cluster-autoscaler \
  --min-count 2 \
  --max-count 6 \
  --enable-managed-identity \
  --enable-workload-identity \
  --enable-oidc-issuer

az aks get-credentials --resource-group dvara-rg --name dvara

Store Secrets in Azure Key Vault

# Create key vault
az keyvault create --name dvara-vault --resource-group dvara-rg --location eastus

# Store secrets
az keyvault secret set --vault-name dvara-vault --name openai-api-key --value "sk-..."
az keyvault secret set --vault-name dvara-vault --name anthropic-api-key --value "sk-ant-..."
az keyvault secret set --vault-name dvara-vault --name enterprise-license-key --value "DVARA-..."

Use the Azure Key Vault Provider for Secrets Store CSI Driver:

# secret-provider-class.yaml
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: dvara-keyvault
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"
    userAssignedIdentityID: "<managed-identity-client-id>"
    keyvaultName: dvara-vault
    tenantId: "<azure-tenant-id>"
    objects: |
      array:
        - |
          objectName: openai-api-key
          objectType: secret
        - |
          objectName: anthropic-api-key
          objectType: secret
        - |
          objectName: enterprise-license-key
          objectType: secret
  secretObjects:
    - secretName: dvara-external
      type: Opaque
      data:
        - objectName: openai-api-key
          key: openai-api-key
        - objectName: anthropic-api-key
          key: anthropic-api-key
        - objectName: enterprise-license-key
          key: enterprise-license-key

kubectl apply -f secret-provider-class.yaml

Deploy with NGINX Ingress Controller

# Install NGINX Ingress Controller
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz

# azure-values.yaml
llmGatewayServer:
  replicaCount: 3
  javaOpts: "-Xms512m -Xmx768m"

  autoscaling:
    enabled: true
    minReplicas: 3
    maxReplicas: 10

  pdb:
    enabled: true
    minAvailable: 2

  serviceMonitor:
    enabled: true

  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app.kubernetes.io/component: gateway-server

flightdeck:
  enabled: true

secrets:
  create: false
  existingSecret: dvara-external

ingress:
  enabled: true
  className: nginx
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
  llmGatewayServer:
    hosts:
      - host: gateway.mycompany.com
        paths:
          - path: /
            pathType: Prefix
    tls:
      - secretName: gateway-tls
        hosts:
          - gateway.mycompany.com
  flightdeck:
    hosts:
      - host: admin.mycompany.com
        paths:
          - path: /
            pathType: Prefix
    tls:
      - secretName: admin-tls
        hosts:
          - admin.mycompany.com

helm install dvara charts/dvara/ --version 1.8.5 -f azure-values.yaml

Database for Flightdeck

DVARA Flightdeck requires PostgreSQL. From 1.8.2 the gateway has no database. Rate limiting and API-key caching run in the gateway process — no external cache infrastructure is required.

Azure Database for PostgreSQL:

az postgres flexible-server create \
  --resource-group dvara-rg --name dvara-db \
  --version 14 --sku-name Standard_D2s_v3 --storage-size 128 \
  --admin-user dvara --admin-password "${DB_PASSWORD}" \
  --tier GeneralPurpose --high-availability ZoneRedundant

Helm values: use the same SPRING_DATASOURCE_* environment variables shown in the AWS section, under flightdeck.extraEnv only, substituting the Azure Database for PostgreSQL endpoint.

Azure OpenAI Service

To use Azure OpenAI instead of the public OpenAI API, configure the Azure OpenAI provider:

# azure-openai-values.yaml
llmGatewayServer:
  extraEnv:
    - name: AZURE_OPENAI_API_KEY
      value: "<azure-openai-api-key>"
    - name: AZURE_OPENAI_BASE_URL
      value: "https://my-resource.openai.azure.com/openai"

DigitalOcean (DOKS — Managed Kubernetes)

Run DVARA on DigitalOcean Kubernetes (DOKS) with DO Managed PostgreSQL for Flightdeck and Traefik v3 ingress with built-in Let's Encrypt. This builds on the Kubernetes / Helm chart. For the no-Kubernetes path, see DigitalOcean (App Platform) below.

Scripted recipe

A runnable version — doctl provisioning + Traefik + helm install + verification in one script — lives in kubernetes/doks/ in dvara-examples. This page is the explained walkthrough.

Prerequisites

doctl authenticated (doctl auth init), plus kubectl and Helm 3.8+
A domain for Let's Encrypt. Add a DVARA licence envelope (DVARA-…) when you need Enterprise Production posture; Development posture boots without one and serves every feature, including MCP and A2A, within 3 workspaces and 100,000 governed calls a month.

Create a DOKS cluster + Managed PostgreSQL

doctl kubernetes cluster create dvara \
  --region nyc1 \
  --node-pool "name=default;size=s-2vcpu-4gb;count=2" --wait
doctl kubernetes cluster kubeconfig save dvara
CLUSTER_ID=$(doctl kubernetes cluster get dvara --format ID --no-header)

doctl databases create dvara-pg --engine pg --version 16 \
  --region nyc1 --size db-s-1vcpu-2gb --num-nodes 1 --wait
DB_ID=$(doctl databases list --format ID,Name --no-header | awk '$2=="dvara-pg"{print $1}')

# Lock the DB to the cluster, then create the app database + user
doctl databases firewalls append "$DB_ID" --rule "k8s:${CLUSTER_ID}"
doctl databases db create   "$DB_ID" dvara
doctl databases user create "$DB_ID" dvara

# Private connection details (port 25060, sslmode=require)
doctl databases connection "$DB_ID" --private --format Host --no-header
doctl databases user get "$DB_ID" dvara --format Password --no-header

Only Flightdeck uses this database

From 1.8.2 the gateway has no database. Flightdeck publishes routes and policies to the gateways as a signed bundle, so only Flightdeck needs the connection details above.

Secrets

DigitalOcean has no Workload-Identity / Secret-Manager equivalent, so the six platform secrets are a plain Kubernetes Secret (or point secrets.existingSecret at one synced by your own Vault / Doppler). Each is openssl rand -base64 32 except the license; the two actuator Bearers must differ.

kubectl create namespace dvara
kubectl -n dvara create secret generic dvara-db \
  --from-literal=password="$DB_PASSWORD"
kubectl -n dvara create secret generic dvara-platform \
  --from-literal=enterprise-license-key="$DVARA_LICENSE_KEY" \
  --from-literal=gateway-encryption-master-password="$(openssl rand -base64 32)" \
  --from-literal=gateway-server-api-key="$(openssl rand -base64 32)" \
  --from-literal=gateway-metrics-api-key="$(openssl rand -base64 32)" \
  --from-literal=audit-hmac-secret="$(openssl rand -base64 32)" \
  --from-literal=enrolment-shared-secret="$(openssl rand -base64 32)"

enrolment-shared-secret is the secret gateways enrol with Flightdeck by (from 1.8.2). With secrets.existingSecret the chart does not generate it, so this Secret must carry it.

Provider keys aren't here — DVARA uses BYOK (workspace keys live AES-encrypted in Flightdeck's database, added via the Flightdeck after install). The chart's provider-key references are optional: true, so this Secret only needs the six platform keys.

Ingress — Traefik v3 (not ingress-nginx)

ingress-nginx reached end of life in March 2026, so this path uses Traefik v3, which has a built-in ACME client (no separate cert-manager):

helm repo add traefik https://traefik.github.io/charts && helm repo update
helm upgrade --install traefik traefik/traefik \
  --namespace traefik --create-namespace \
  --set "certificatesResolvers.letsencrypt.acme.email=ops@example.com" \
  --set "certificatesResolvers.letsencrypt.acme.storage=/data/acme.json" \
  --set "certificatesResolvers.letsencrypt.acme.tlsChallenge=true" \
  --set "persistence.enabled=true" --wait

(Traefik Helm value paths are version-sensitive — confirm with helm show values traefik/traefik.)

Deploy

# doks-values.yaml
llmGatewayServer:
  replicaCount: 2
  serviceAccount: { create: true }   # no cloud identity needed on DO
  # No database settings: from 1.8.2 the gateway has none. Give each pod its
  # own volume for the spool, the bundle snapshot and the enrolment files.
  persistence: { enabled: true }
  pdb: { enabled: true, minAvailable: 1 }

flightdeck:
  enabled: true
  extraEnv:
    - { name: SPRING_DATASOURCE_URL, value: "jdbc:postgresql://DB_PRIVATE_HOST:25060/dvara?sslmode=require" }
    - { name: SPRING_DATASOURCE_USERNAME, value: "dvara" }
    - name: SPRING_DATASOURCE_PASSWORD
      valueFrom: { secretKeyRef: { name: dvara-db, key: password } }

secrets:
  create: false
  existingSecret: dvara-platform

# Traefik issues Let's Encrypt certs for the baseDomain-derived hosts
# (api.<domain> + flightdeck.<domain>).
ingress:
  enabled: true
  className: traefik
  annotations:
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls.certresolver: letsencrypt
  baseDomain: dvara.example.com

helm install dvara oci://ghcr.io/dvarahq/charts/dvara \
  --version 1.8.5 --namespace dvara \
  --values doks-values.yaml \
  --set llmGatewayServer.image.tag=1.8.5 \
  --set flightdeck.image.tag=1.8.5 --wait

Pin the image tag — never :latest

The chart version and image tags are pinned to 1.8.5, a published release on GHCR. Pin a real, published tag so deploys are reproducible and rollbacks clean. When a newer release is published, bump to that version — don't pin a tag that hasn't shipped, or pods fail with ImagePullBackOff.

Point api.dvara.example.com and flightdeck.dvara.example.com at the DO Load Balancer IP (kubectl -n traefik get svc traefik); Traefik issues the certs within a few minutes of DNS resolving.

Verify (including config hot-reload)

kubectl -n dvara get pods                                    # all Ready
kubectl -n dvara port-forward svc/dvara-flightdeck 8090:8090 &
open http://localhost:8090/                                  # /setup → workspace + API key

DigitalOcean (App Platform)

Prerequisites

doctl CLI configured
A DigitalOcean account

One-Click Deploy

Click the deploy button or use the CLI:

doctl apps create --spec .do/app.yaml

From 1.8.2 the gateway cannot run on its own: it needs a DVARA Flightdeck to enrol with and get its configuration from. Use the multi-service spec below. Set your provider API keys in the App Platform dashboard under Settings → Environment Variables.

Custom App Spec

For a multi-service deployment with the DVARA Flightdeck:

# .do/app.yaml
spec:
  name: dvara
  region: nyc
  services:
    - name: gateway-server
      image:
        registry_type: GHCR
        registry: dvarahq
        repository: dvara-gateway
        tag: 1.8.5
      http_port: 8080
      instance_count: 1
      instance_size_slug: professional-xs
      health_check:
        http_path: /actuator/health
        initial_delay_seconds: 30
        period_seconds: 15
      envs:
        - key: JAVA_OPTS
          scope: RUN_TIME
          value: "-Xmx768m"
        - key: OPENAI_API_KEY
          scope: RUN_TIME
          type: SECRET
        - key: ANTHROPIC_API_KEY
          scope: RUN_TIME
          type: SECRET
        # No database: the gateway enrols with Flightdeck and reads its
        # configuration from it (from 1.8.2).
        - key: DVARA_DATA_PLANE_CONTROL_PLANE_BASE_URL
          scope: RUN_TIME
          value: "https://flight-deck:8443"
        - key: DVARA_DATA_PLANE_CONTROL_PLANE_ENROLMENT_SHARED_SECRET
          scope: RUN_TIME
          type: SECRET
        - key: DVARA_DATA_PLANE_CONTROL_PLANE_ENROLMENT_DIRECTORY
          scope: RUN_TIME
          value: /var/lib/dvara/enrolment
        - key: DVARA_DATA_PLANE_CONTROL_PLANE_SNAPSHOT_PATH
          scope: RUN_TIME
          value: /var/lib/dvara/bundle-snapshot.json
        - key: DVARA_LLM_GATEWAY_LOCAL_STORE_PATH
          scope: RUN_TIME
          value: /var/lib/dvara/spool.db

    - name: flight-deck
      image:
        registry_type: GHCR
        registry: dvarahq
        repository: dvara-flightdeck
        tag: 1.8.5
      http_port: 8090
      internal_ports: [8443]
      instance_count: 1
      instance_size_slug: basic-s
      health_check:
        http_path: /actuator/health/liveness
        initial_delay_seconds: 30
      envs:
        - key: DVARA_FLIGHTDECK_GATEWAY_URL
          scope: RUN_TIME
          value: "${gateway-server.PRIVATE_URL}"
        - key: DVARA_INTERNAL_ENROLMENT_ENABLED
          scope: RUN_TIME
          value: "true"
        - key: DVARA_INTERNAL_ENROLMENT_SERVER_NAMES
          scope: RUN_TIME
          value: flight-deck
        # The same value as the gateway's enrolment secret, at least 32 characters.
        - key: DVARA_INTERNAL_ENROLMENT_SHARED_SECRET
          scope: RUN_TIME
          type: SECRET

The gateway's spool is not durable on App Platform

App Platform gives a service no volume that survives a redeploy. The gateway keeps its spool of undelivered audit, usage and cost records under /var/lib/dvara on the instance's own disk. A normal stop flushes the spool to Flightdeck first, but an instance that dies without that flush loses what it had not yet shipped. For production, run on DOKS with llmGatewayServer.persistence.enabled: true.

Database for Flightdeck

DVARA Flightdeck requires PostgreSQL. From 1.8.2 the gateway has no database. Rate limiting and API-key caching run in the gateway process — no external cache infrastructure is required.

Managed PostgreSQL:

doctl databases create dvara-db \
  --engine pg --version 14 \
  --size db-s-2vcpu-4gb \
  --region nyc1 --num-nodes 2

Add the database connection details to the flight-deck service only, as environment variables in the App Platform dashboard or as components in the app spec:

envs:
  - key: SPRING_DATASOURCE_URL
    scope: RUN_TIME
    value: "${dvara-db.DATABASE_URL}"

Scaling

App Platform supports horizontal scaling via the dashboard or CLI:

# Scale to 3 instances
doctl apps update <app-id> --spec <updated-spec-with-instance_count-3>

For production, use professional-xs or larger instance sizes which provide dedicated CPU resources.

Monitoring Stack

All cloud providers can use the same monitoring setup. Install the kube-prometheus-stack for Prometheus + Grafana:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set grafana.adminPassword=admin

Enable ServiceMonitor in DVARA:

llmGatewayServer:
  serviceMonitor:
    enabled: true
    interval: 15s
    additionalLabels:
      release: monitoring

# The MCP and A2A planes run inside the gateway, so the job above scrapes all
# three planes — there is no second workload to add a ServiceMonitor for.

Import the included Grafana dashboard from grafana/dashboards/ for pre-built panels covering request rates, latencies, token usage, provider health, cost metrics, and agent session stats.

Key Prometheus Metrics to Alert On

# Example alerting rules
groups:
  - name: dvara
    rules:
      - alert: HighErrorRate
        expr: rate(gateway_requests_total{status=~"5.."}[5m]) / rate(gateway_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
      - alert: HighLatency
        expr: gateway_latency_seconds{quantile="0.95"} > 5
        for: 5m
        labels:
          severity: warning
      - alert: BudgetCapBreached
        expr: increase(gateway_budget_blocked_total[1h]) > 0
        labels:
          severity: warning

Enterprise Features on Cloud

Vault Integration

DVARA supports HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault as credential backends for LLM provider keys. This is separate from Kubernetes secret management — it provides runtime credential resolution for the gateway itself.

HashiCorp Vault (any cloud):

llmGatewayServer:
  extraEnv:
    - name: DVARA_VAULT_BACKEND
      value: hashicorp
    - name: VAULT_ADDR
      value: "https://vault.internal:8200"
    - name: VAULT_AUTH_METHOD
      value: approle
    - name: VAULT_ROLE_ID
      valueFrom:
        secretKeyRef:
          name: vault-credentials
          key: role-id
    - name: VAULT_SECRET_ID
      valueFrom:
        secretKeyRef:
          name: vault-credentials
          key: secret-id

AWS Secrets Manager:

llmGatewayServer:
  extraEnv:
    - name: DVARA_VAULT_BACKEND
      value: aws-secrets-manager
    - name: AWS_VAULT_REGION
      value: us-east-1
    - name: AWS_SECRET_NAME
      value: dvara/provider-credentials
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/dvara-secrets

Azure Key Vault:

llmGatewayServer:
  extraEnv:
    - name: DVARA_VAULT_BACKEND
      value: azure-key-vault
    - name: AZURE_VAULT_URL
      value: "https://dvara-vault.vault.azure.net"
    - name: AZURE_CLIENT_ID
      value: "<managed-identity-client-id>"

OIDC / SSO Setup

Enable OIDC-based authentication for DVARA Flightdeck. These settings belong on Flightdeck, not the gateway:

flightdeck:
  extraEnv:
    - name: DVARA_FLIGHTDECK_SECURITY_ENABLED
      value: "true"
    - name: DVARA_FLIGHTDECK_SECURITY_OIDC_ISSUER_URI
      value: "https://login.microsoftonline.com/<workspace-id>/v2.0"  # Azure AD
      # value: "https://accounts.google.com"                        # Google
      # value: "https://cognito-idp.us-east-1.amazonaws.com/<pool>" # AWS Cognito
    - name: DVARA_FLIGHTDECK_SECURITY_OIDC_AUDIENCE
      value: "dvara-gateway"
    - name: DVARA_FLIGHTDECK_SECURITY_OIDC_ROLE_CLAIM
      value: "roles"  # or "realm_access.roles" for Keycloak

Database Requirements

PostgreSQL is required by DVARA Flightdeck. From 1.8.2 the gateway has no database: it reads its configuration as a signed bundle from Flightdeck and ships its audit, usage and cost records to Flightdeck, which stores them. A gateway given SPRING_DATASOURCE_URL refuses to start. Rate limiting and the distributed cache for API-key lookups both run in the gateway process — no external cache infrastructure is needed.

Dependency	Minimum Version	Purpose
PostgreSQL	14+	Required by Flightdeck. Audit events, policies, cost records, token usage, workspaces, API keys, routes, etc.

Flightdeck runs the database migrations, and is the only process that does. They run automatically on first startup, so no manual schema setup is required. Subsequent upgrades apply incremental migrations without data loss.

Connection pool defaults: Flightdeck and bulk-load jobs default to ten connections. Increase pool sizes only after measuring database saturation and leave enough headroom for every Flightdeck replica. DVARA_DB_POOL_SIZE, DVARA_DB_MIGRATE and DVARA_DB_SOCKET_TIMEOUT_SECONDS are no longer read on the gateway.

Quick Reference: Cloud-Specific Values

Setting	AWS	GCP	Azure	DigitalOcean
Ingress class	`alb`	`gce`	`nginx`	App Platform (built-in)
TLS termination	ACM certificate ARN annotation	GKE ManagedCertificate	cert-manager + Let's Encrypt	Automatic (App Platform)
Service account identity	IRSA (`eks.amazonaws.com/role-arn`)	Workload Identity (`iam.gke.io/gcp-service-account`)	Managed Identity	N/A
Secret management	Secrets Manager + External Secrets	Secret Manager + External Secrets	Key Vault + CSI Driver	App Platform env vars (encrypted)
Node type (recommended)	`m6i.large` (2 vCPU, 8 GB)	`e2-standard-4` (4 vCPU, 16 GB)	`Standard_D4s_v3` (4 vCPU, 16 GB)	`professional-xs` (1 vCPU, 1 GB dedicated)
Autoscaler	Cluster Autoscaler or Karpenter	GKE Autopilot or Cluster Autoscaler	AKS Cluster Autoscaler	Manual instance count
Managed PostgreSQL (required, Flightdeck only)	RDS for PostgreSQL	Cloud SQL for PostgreSQL	Azure Database for PostgreSQL	DigitalOcean Managed Databases

Production Checklist

Before going to production on any cloud provider:

AWS (EKS)​

Prerequisites​

Create an EKS Cluster​

Install the AWS Load Balancer Controller​

Store Secrets in AWS Secrets Manager​

Deploy with ALB Ingress + IRSA​

AWS Bedrock with explicit credentials​

Database for Flightdeck​

Multi-Region on AWS​

AWS (ECS)​

Prerequisites​

Store secrets in AWS Secrets Manager​

Task execution role​

Task definition​

Application Load Balancer​

Clustering on Fargate​

Auto scaling​

Observability​

When to choose ECS over EKS​

Google Cloud (GKE)​

Prerequisites​

Create a VPC-native GKE cluster​

Cloud SQL (private IP)​

Workload Identity for secrets​

Deploy with GCE Ingress + managed TLS​

Verify (including config hot-reload)​

Gemini / Vertex AI (optional)​

Azure (AKS)​

Prerequisites​

Create an AKS Cluster​

Store Secrets in Azure Key Vault​

Deploy with NGINX Ingress Controller​

Database for Flightdeck​

Azure OpenAI Service​

DigitalOcean (DOKS — Managed Kubernetes)​

Prerequisites​

Create a DOKS cluster + Managed PostgreSQL​

Secrets​

Ingress — Traefik v3 (not ingress-nginx)​

Deploy​

Verify (including config hot-reload)​

DigitalOcean (App Platform)​

Prerequisites​

One-Click Deploy​

Custom App Spec​

Database for Flightdeck​

Scaling​

Monitoring Stack​

Key Prometheus Metrics to Alert On​

Enterprise Features on Cloud​

Vault Integration​

OIDC / SSO Setup​

Database Requirements​

Quick Reference: Cloud-Specific Values​

Production Checklist​

AWS (EKS)

Prerequisites

Create an EKS Cluster

Install the AWS Load Balancer Controller

Store Secrets in AWS Secrets Manager

Deploy with ALB Ingress + IRSA

AWS Bedrock with explicit credentials

Database for Flightdeck

Multi-Region on AWS

AWS (ECS)

Prerequisites

Store secrets in AWS Secrets Manager

Task execution role

Task definition

Application Load Balancer

Clustering on Fargate

Auto scaling

Observability

When to choose ECS over EKS

Google Cloud (GKE)

Prerequisites

Create a VPC-native GKE cluster

Cloud SQL (private IP)

Workload Identity for secrets

Deploy with GCE Ingress + managed TLS

Verify (including config hot-reload)

Gemini / Vertex AI (optional)

Azure (AKS)

Prerequisites

Create an AKS Cluster

Store Secrets in Azure Key Vault

Deploy with NGINX Ingress Controller

Database for Flightdeck

Azure OpenAI Service

DigitalOcean (DOKS — Managed Kubernetes)

Prerequisites

Create a DOKS cluster + Managed PostgreSQL

Secrets

Ingress — Traefik v3 (not ingress-nginx)

Deploy

Verify (including config hot-reload)

DigitalOcean (App Platform)

Prerequisites

One-Click Deploy

Custom App Spec

Database for Flightdeck

Scaling

Monitoring Stack

Key Prometheus Metrics to Alert On

Enterprise Features on Cloud

Vault Integration

OIDC / SSO Setup

Database Requirements

Quick Reference: Cloud-Specific Values

Production Checklist