Deploy on plain Kubernetes

The kirimana deploy --cloud=azure path provisions a whole environment — AKS, managed Postgres, KeyVault, DNS, TLS — with one command. This page is for the other case: you already run a Kubernetes cluster and you want Kirimana on it, using the chart directly. The application layer is cloud-neutral, so the same Helm chart installs on any conformant cluster; only the surrounding infrastructure differs.

What the managed path does that this one doesn’t

kirimana deploy is an orchestrator. It runs Terraform to create the cluster and its dependencies, wires workload identity, seeds secrets, and then Helm-installs the chart. On a bring-your-own cluster you own the layers underneath the chart, and Kirimana owns only the chart:

Concern	Managed AKS path	Plain Kubernetes
Cluster	Created by Terraform	You bring it
Postgres	Azure DB for PostgreSQL, provisioned + CMK	You bring a reachable Postgres
Secrets	KeyVault + workload identity binding	You wire a secret store / K8s Secrets
Ingress + TLS	Public IP, DNS delegation, cert-manager	You bring ingress + certificates
Install	Helm, invoked by the orchestrator	Helm, invoked by you

The trade is control for convenience. You get to fit Kirimana into an existing platform — your ingress class, your Postgres, your secret manager — at the cost of assembling those pieces yourself.

Prerequisites

• Kubernetes 1.28 or newer, conformant. The chart uses no provider-specific CRDs; a stock cluster is enough.
• A reachable PostgreSQL for the automation database (14.x, 15.x, or 16.x are supported). Managed or in-cluster both work — the chart only needs a connection string.
• Helm 3 and kubectl configured against the target cluster.
• An ingress controller and a way to terminate TLS (cert-manager, or certificates you supply).
• Your data-platform credentials — for Databricks, a Service Principal token with Unity Catalog and workspace permissions on the catalog you’ll target.
• GitHub App credentials if you want Kirimana to open PRs on your DW project repo (App ID + private key). Optional for a read-first install; required for the GitOps write-back loop.

Install

Create a namespace and install the chart into it:

kubectl create namespace kirimana

helm install kirimana ./charts/kiriapp \
  --namespace kirimana \
  --values my-values.yaml

The multi-replica components (web, web-bff) carry a PodDisruptionBudget (minAvailable: 1), so an in-flight node drain can never evict the last healthy pod. The database migration runs as a bounded Job — its migration.activeDeadlineSeconds fails a hung migration rather than stalling the release. Keep any --timeout you pass on upgrades greater than or equal to that deadline so Helm waits for the Job’s own bound.

Values

A minimal my-values.yaml wires the three things the chart can’t infer: the database, how it reaches your data platform, and how users sign in.

postgres:
  # A connection to your Postgres. In-cluster or managed both work.
  host: postgres.data.svc.cluster.local
  database: kirimana
  # Prefer a secret reference over an inline value.
  passwordSecret:
    name: kirimana-postgres
    key: password

ingress:
  enabled: true
  className: nginx
  host: kirimana.example.com
  tls:
    enabled: true
    secretName: kirimana-tls

auth:
  # OIDC issuer + client for your IdP (Azure AD / Okta / etc.).
  issuer: https://login.example.com/oidc
  clientId: kirimana-web

github:
  # Optional — enables the PR write-back loop.
  appId: "123456"
  privateKeySecret:
    name: kirimana-github-app
    key: private-key.pem

Your DW project’s own kiri.yml — not the chart — describes the data platform target. On Databricks:

adapter: databricks
default_target: prod
targets:
  prod:
    adapter: databricks
    host: https://adb-xxxx.azuredatabricks.net
    warehouse_id: w-abc123
    catalog: acme_prod
    schema: bronze
    token: ${vault:databricks/prod:token}

Store the Databricks Service Principal token in whatever secret store your ${vault:...} resolver is bound to, never inline in the committed YAML.

Health checks

The chart ships readiness and liveness probes on each component; a successful helm install waits for them. Confirm the rollout landed:

kubectl get pods -n kirimana
kubectl rollout status deployment/kiriapp-web -n kirimana
kubectl rollout status deployment/kiriapp-web-bff -n kirimana

Then check the application’s own end-to-end wiring — cluster identity, secret resolution, and data-platform reachability — from inside a pod or from your CLI against the same target:

kirimana doctor

kirimana doctor runs the same three checks the managed path runs after deploy: the secret store holds the data-platform token at the expected path, the workload can resolve it, and the data platform accepts it. For Databricks specifically:

kiri databricks health --target prod

Once doctor is green and the ingress resolves, open your host over HTTPS and sign in with your IdP. Users who see “Access denied” need an RBAC role granted (viewer, approver, or platform-admin); that is an authorization step, not an install failure.

Upgrading

Upgrades follow the same atomic path as the managed deployment. Capture a restorable snapshot first, then upgrade with rollback-on-failure:

kiri upgrade snapshot --out ./.kiri-snapshots

helm upgrade kirimana ./charts/kiriapp \
  --namespace kirimana \
  --values my-values.yaml \
  --atomic --timeout=15m

--atomic rolls the whole release — including the migration Job — back to the prior good revision if any pod fails readiness or the migration exhausts its deadline. If you need to reverse a completed upgrade, kiri upgrade rollback --snapshot ./.kiri-snapshots --namespace kirimana reverses the Helm release and restores Postgres from the snapshot. Run kiri upgrade --check before any minor bump to see the kiri.yml and values-schema changes the new release expects.

Where next

• CLI quickstart — bootstrap a DW project and apply your first contract against the target you just wired.
• Write your first data contract — the ODCS contract shape everything above serves.