deploy/helm/charts/vexa
deploys the same control plane as the Compose stack, with the runtime pointed at the cluster:
RUNTIME_BACKEND=k8s makes every bot and every agent dispatch its own bare Pod
(restart: Never), so capacity is your cluster’s scheduler — not a bigger box.
What the chart deploys
| Component | Form |
|---|---|
| gateway · admin-api · meeting-api · agent-api · runtime | Deployments (RollingUpdate, maxUnavailable: 0) |
| terminal (web workbench) | Deployment + ingress |
| postgres | StatefulSet (or point values at your managed DB) |
| redis · minio | Deployments (+ minio init Job) |
| DB migrations | Job |
| pgbouncer | optional connection pooling |
| RBAC for the k8s spawn backend | Role/RoleBinding scoped to Pod create/watch/delete |
Install
values-staging.yaml and values-test.yaml show environment overlays. Chart tests
(helm lint + template tests) live under deploy/helm/tests/.
The runtime on Kubernetes
The runtime kernel owns oneruntime.v1 lifecycle (starting → running → stopping → stopped → destroyed) and delegates only the substrate question — how do I start, observe, and stop a
workload? — to the backend. On k8s, a workload is a bare Pod; the same dispatch, contracts,
and worker run identically to the Docker backend. See Execution.