KaireonAI is a Next-Best-Action decisioning platform deployed on Kubernetes via Helm. This guide covers three installation modes ranging from a quick local demo to a fully managed production stack on AWS.
1. Prerequisites
Cluster Requirements
- Dev/Demo: Any Kubernetes cluster (Docker Desktop, kind, minikube, or a remote cluster). Minimum 2 CPU / 4 GB RAM available.
- App-Only: An existing Kubernetes cluster with access to your managed database and cache.
- Full Stack: An AWS account with permissions to create VPC, EKS, RDS, ElastiCache, S3, IAM, and Route 53 resources.
Verify Prerequisites
The deploy script (scripts/deploy.sh, used in every mode below) runs preflight checks as its first step — it verifies that kubectl and helm are installed, confirms cluster connectivity, and creates the target namespace if it does not already exist. Pass --skip-preflight to bypass these checks.
2. Quick Start (Dev/Demo)
The dev mode deploys everything inside the cluster. Only PostgreSQL is required — Redis and other infrastructure are optional and can be configured later from the Settings > Integrations UI.
This script:
- Runs preflight checks and creates the
kaireon namespace.
- Generates the required secrets (
NEXTAUTH_SECRET, JWT_SIGNING_SECRET, CONNECTOR_ENCRYPTION_KEY) when they are not already set in the environment.
- Deploys an in-cluster PostgreSQL 16 StatefulSet, Redis, the KaireonAI API, and the Worker via
helm upgrade --install.
- Waits for the API pods, runs the database schema sync (
prisma db push) inside the pod, and performs a health check.
Note: The default chart deploys an in-cluster Redis StatefulSet alongside PostgreSQL — Redis backs the background worker queue and caching. Optional backends (Kafka/MSK, EventBridge, Kinesis, DynamoDB/ScyllaDB, OpenSearch) are off by default and are enabled through Helm values after installation.
Access the Application
Port-forward the API service to your local machine:
Open http://localhost:3000 in your browser.
Load Sample Data (Optional)
To load the sample retail dataset, sign in and open Settings > Sample Data in the UI, then click Load next to the Retail Rewards dataset.
Override the Namespace
3. App-Only Install
Use this mode when you already have a managed PostgreSQL database (e.g., Amazon RDS, Cloud SQL). KaireonAI installs only the application components into your existing cluster. Redis and other infrastructure are optional — configure them from Settings > Integrations after installation.
Step 1 — Create a Configuration File
Create a file named kaireon-config.yaml (or any name you prefer):
Step 2 — Create Kubernetes Secrets (If Using existingSecret)
Step 3 — Install
This deploys the API, Worker, PgBouncer, and (when enabled) Prometheus/Grafana into the target namespace. The script generates any unset secrets and runs the database schema sync. Pass sensitive values with --set rather than writing them into the config file — for example --set database.external.password=….
4. Full Stack Install
The full-stack mode provisions all AWS infrastructure with Terraform, then deploys the application with Helm.
Ensure the IAM principal has broad permissions (VPC, EKS, RDS, ElastiCache, S3, IAM, Route 53, CloudWatch). The AWS-managed administrator-access policy works for initial setup; scope down for production.
Edit variables.tf defaults or create a terraform.tfvars file:
Terraform creates:
- A VPC with public and private subnets across availability zones.
- An EKS cluster with a managed node group (t3.large, min 2 / max 6 nodes).
- An RDS PostgreSQL instance in private subnets.
- An ElastiCache Redis cluster in private subnets.
- An S3 bucket for backups.
- IAM roles with IRSA for pod-level AWS access.
- Route 53 records and an ACM certificate (if
domain is set).
- CloudWatch alarms and dashboards (if enabled).
Step 5 — Install the Application
Return to the repository root. Build an App-Only config file from the Terraform outputs (RDS endpoint, ElastiCache endpoint, and secret references) with database.mode: external, redis.mode: external, and secrets.provider: aws-secrets-manager, then deploy:
5. Post-Install Verification
Check Deployment Status
Expected output:
Health Check Endpoints
Access Grafana
Grafana ships with pre-configured dashboards for API latency, worker queue depth, database connections, and Redis memory.
Access Prometheus
Tail Logs
Install provenance bundle signing (cosign) — required for production
KaireonAI ships every /api/v1/decisions/:id/provenance response with a
detached cosign signature in the X-Provenance-Signature header.
Until you install a signing key the header reads unsigned and
downstream verifiers will reject the bundle. The fail-soft is
intentional (a missing key never breaks the response) but is not a
production posture — install before going live.
There are exactly two supported install paths. Pick whichever matches
your topology:
- Cloud (AWS Secrets Manager) — recommended for App Runner, ECS,
EKS, or any AWS-resident deployment. Operator runbook with the
exact commands lives at
tools/runbooks/cosign-key-rollout.md.
- Self-host (local key file) — for VM, on-prem, Docker Compose, or
single-host installs.
End-to-end install steps + verification commands are documented at
Provenance signing install guide.
Both paths set the same two env vars (COSIGN_KEY, COSIGN_PASSWORD)
on the runtime container — what differs is where those values live at
rest. The public verification key for KaireonAI’s hosted
playground.kaireonai.com instance is published at
kaireonai-docs/security/cosign.pub.
6. Configuration Reference
The Helm chart is configured through values.yaml or a custom config file passed via CONFIG=. Below is a complete reference of all options.
Global
API
Worker
Config
Database
Redis
Secrets
Ingress
PgBouncer
Observability
Monitoring (In-Cluster)
7. Upgrading
Rolling Upgrade
To upgrade KaireonAI to a new version:
This runs helm upgrade --reuse-values, which performs a rolling update with zero downtime. The API deployment uses a rolling-update strategy by default.
Upgrade with New Configuration
To change configuration during an upgrade, edit your config file and pass it:
Database Schema Sync
The deploy script applies schema changes automatically (prisma db push --skip-generate inside the API pod) on every run. To run the sync manually against a running deployment:
prisma db push is safe only on a fresh database. On a populated database it drops any table not modeled in schema.prisma — including runtime-created ds_* customer-schema tables and _flow_* pipeline staging tables — causing data loss. For schema evolution on an existing database, apply the numbered files in platform/prisma/manual-sql/ with psql instead.
Version Pinning
Pin the image tag in your config to control rollouts:
8. Uninstalling
Remove the Application (Keep Infrastructure)
This runs helm uninstall and removes all KaireonAI pods, services, and config maps. Persistent volumes (database, Redis) are retained by default.
Remove Application and Namespace
This removes the Helm release and deletes the entire namespace, including any persistent volume claims.
Destroy AWS Infrastructure (Full Stack Only)
After removing the application, destroy Terraform-managed resources:
Warning: This permanently deletes the VPC, EKS cluster, RDS database, ElastiCache cluster, and S3 bucket. Ensure you have backed up any data before proceeding.
Create a Backup Before Uninstalling
To restore later:
9. Troubleshooting FAQ
Pods stuck in Pending state
Symptom: kubectl get pods -n kaireon shows pods in Pending status.
Causes and fixes:
-
Insufficient cluster resources. Check node capacity:
Add more nodes or reduce resource requests in your config.
-
PVC not binding (dev mode). The cluster may lack a default StorageClass:
If empty, install a provisioner (e.g.,
hostpath-provisioner for local clusters) or set one as default:
-
Node selector or taint mismatch. Verify there are no taints preventing scheduling:
Database connection refused
Symptom: API pods crash with the ECONNREFUSED error code or connection refused errors in logs.
Fixes:
-
Internal mode: Confirm the PostgreSQL pod is running:
Check its logs:
-
External mode: Verify the host is reachable from inside the cluster:
-
Security groups (AWS). Ensure the RDS security group allows inbound on port 5432 from the EKS node security group. In full-stack mode, Terraform configures this automatically.
-
PgBouncer misconfiguration. If PgBouncer is enabled, verify it can reach the database:
Redis connection errors
Symptom: Workers fail to start or events are not published.
Fixes:
-
Internal mode: Confirm the Redis pod is running:
-
External mode: Test connectivity:
-
TLS mismatch. If your external Redis does not use TLS, set
redis.external.tls: false.
-
Authentication. Ensure the password in your K8s secret matches the Redis AUTH password:
Ingress not working / 404 errors
Symptom: The application is unreachable via the configured hostname.
Fixes:
-
Ingress controller not installed. Verify an ingress controller is running:
If missing, install one:
-
Ingress class mismatch. Ensure
ingress.className matches your controller:
-
DNS not pointing to the load balancer. Get the external IP:
Create a DNS A/CNAME record pointing your domain to that address.
-
TLS certificate not ready. Check cert-manager:
Helm install fails with “namespace not found”
Fix: Create the namespace first:
Or let the chart create it (the chart includes a namespace.yaml template that handles this).
Migrations fail during install
Symptom: Install completes but the app shows schema errors.
Fixes:
-
Run the schema sync manually:
-
Check the API pod logs (the schema sync runs there on startup):
-
Verify database connectivity and permissions. The migration user needs
CREATE TABLE, ALTER TABLE, and CREATE INDEX privileges.
Out-of-memory pod restarts
Symptom: Pods restart with the out-of-memory-kill termination reason.
Fix: Increase memory limits in your config:
Then upgrade:
AWS Secrets Manager errors (Full Stack mode)
Symptom: Pods fail with “AccessDeniedException” when fetching secrets.
Fixes:
-
Verify the IRSA role ARN is correct in your config:
-
Confirm the service account is annotated:
-
Check the IAM trust policy allows the OIDC provider for your cluster.
How to open a shell in the API pod
This drops you into /bin/sh inside the running API container, useful for debugging environment variables and network connectivity.
How to view all available Make targets