Deployment

Kopilot runs anywhere Python runs, but in-cluster deployment gives it in-cluster credentials and probes. The repository ships a Dockerfile, a Helm chart, and a single-file quickstart manifest.

Container image

The Dockerfile builds a slim Python 3.13 image with pinned, checksum-verified kubectl and helm binaries, running as a non-root user. Images are published by CI to GHCR as ghcr.io/kopilot-ai/kopilot. To build locally:

git clone https://github.com/kopilot-ai/kopilot
cd kopilot
docker build -t kopilot:dev .

Helm chart

The chart lives in the repository at helm/kubedevaiops. There is no hosted chart repository — install from the local path:

helm install kopilot ./helm/kubedevaiops \
  --namespace kubedevaiops --create-namespace \
  --set image.repository=ghcr.io/kopilot-ai/kopilot \
  --set image.tag=latest

The chart installs:

The three CRDs (AITask, AISkill, AIPolicy).
A Deployment (single replica), Service (ports 8080 and 9090), ServiceAccount, and a scoped ClusterRole/Binding.
A ConfigMap generated from chart values (LLM provider, safety settings, enabled skills, …) and a Secret for API keys.

Useful values: llm.provider, llm.model, ollama.baseUrl, safety.*, enabledSkills, and extraSkillDirs for mounting custom skills. See helm/kubedevaiops/values.yaml for the full list.

Quickstart manifest

For a fast look on a throwaway cluster (kind, minikube), a single manifest creates the namespace, config, a scoped ClusterRole, the Deployment, and a NodePort service on 30080. Apply the CRDs first, then the manifest:

kubectl apply -f helm/kubedevaiops/crds/
kubectl apply -f deploy/quickstart.yaml

The quickstart is for lab clusters. It exposes the API on a NodePort with no API_AUTH_TOKEN set — anyone who can reach port 30080 can drive the agent. Review the ClusterRole it creates before applying, and use the Helm chart (with an auth token) for anything beyond a first look.

RBAC notes

Kopilot executes kubectl and helm as subprocesses under the pod's service account, so the service account's RBAC is the real security boundary — the pattern-based approval gate is defense in depth on top of it, not a replacement for it. The chart's ClusterRole grants, roughly:

Read (get/list/watch) on core resources, RBAC objects, and metrics for diagnostics.
Write on apps and batch workloads, autoscaling, and networking resources.
Full control of the kubedevaiops.io CRDs and the coordination leases Kopf needs.

Trim anything your use case does not need. If you only want recommendations, a read-only role plus the CRD/lease rules is enough — the agent will still investigate and propose, and every mutation attempt will simply fail at the API server.

Probes and metrics

Liveness: GET /health; readiness: GET /readyz (both on port 8080).
Prometheus metrics on GET /metrics (bearer-protected when API_AUTH_TOKEN is set).

Run one replica

The approval queue, task history, and conversation memory are in-process. Run a single replica; a restart clears pending approvals and history. This is a known, documented limitation of the current release.