Adopt on an existing cluster
Brownfield playbook: attach kprompt to a working kubeconfig in ~15 minutes — detect, bind existing tools, read-first insight, optional MCP. Prefer configure over install.
Greenfield is easy (kind + demo). This page is the other path: you already have a cluster, Helm or Prometheus somewhere, GitOps, and RBAC you do not want to rewrite. Goal — first useful insight without installing a second monitoring stack.
Scorecard
| Signal | Good | Avoid |
|---|---|---|
| Time-to-first-insight | Useful read in ≤15 min | Spend the hour installing operators first |
| Cluster touch | No new operators | kube-prometheus-stack “just for the demo” |
| Tools | Bind URLs / PATH you already have | Treat missing as “must install via setup” |
| Mutations | Plan only; apply later on a TTY | --approve on the first unfamiliar prompt |
| IDE | Optional MCP read/plan | Expect auto-apply from the editor |
15-minute path
0–2 min — binary + context
curl -fsSL https://kprompt.ai/install | bash # or: brew install kprompt/tap/kprompt
kubectl config current-context # staging / sandbox first
kprompt versionUse a non-production context until the plan loop feels boring. Multi-context notes: Multi-cluster.
2–5 min — provider
# $0 local (recommended first)
ollama serve && ollama pull llama3.2
kprompt init --ollama
# or BYOK — your key, never stored in config.yaml
# kprompt init --provider openai && export KPROMPT_OPENAI_API_KEY=…
kprompt doctorInit only writes provider/model (and optional context). It does not create clusters or run setup installs.
5–8 min — detect, then bind
kprompt tools
# Prefer bind when backends already exist:
kprompt config set tools.prometheus.url http://prometheus.monitoring:9090
# kprompt config set tools.grafana.url http://grafana.monitoring:3000
# kprompt config set tools.otel.backend tempo
kprompt tools
kprompt doctorkprompt tools inventories Helm on PATH, Argo Workflow CRDs, Prom/Grafana/OTel URLs, GitOps controllers, and more. Missing is a hint — not a mandate to install. Use kprompt setup only when you truly lack a component and accept an approve-gated install plan. Full flag reference: Setup · Integrations.
8–12 min — first insight (read-only)
kprompt "list deployments" -n <your-ns>
kprompt "explain why <workload> is failing" -n <your-ns>
kprompt "why is my api slow?" -n <your-ns> # needs Prometheus URL
kprompt "optimize my cluster" # read-only report
kprompt "show service dependency graph"Reads run under your kubeconfig RBAC. Optimize and graph degrade honestly when Prom/OTel are absent — they do not invent metrics.
12–15 min — optional IDE + plan-only mutate
MCP (Cursor / Claude Desktop) — never applies
# ~/.cursor/mcp.json (or project .cursor/mcp.json)
{
"mcpServers": {
"kprompt": {
"command": "kprompt",
"args": ["mcp", "serve"]
}
}
}Mutation stays plan → human approve
kprompt "scale <workload> to 3" -n <your-ns>
# read the plan + risk; approve on TTY, or leave it
# Apply only after you trust the shape:
# kprompt "scale <workload> to 3" -n <your-ns> --approveMCP tools are read/plan-only. An assistant can call kprompt.plan; it cannot pass --approve over the protocol. Details: MCP · Safety.
Anti-patterns
- Installing kube-prometheus-stack before trying tools.prometheus.url against the Prom you already run
- Pointing the first session at production with --approve
- Treating setup --profile platform as the default brownfield path
- Expecting MCP or Autopilot to mutate without a human on the approve path
- Skipping doctor when tools look empty — often config URL, not a missing CRD
What this playbook is not
- Not a cluster provisioner (kind / EKS / GKE stay out of scope)
- Not a second GitOps or Helmfile installer
- Not a promise that every integration lights up green in 15 minutes — only that the path prefers bind + read-first
- Not production Autopilot — Observe agent and Autopilot stay propose/notify unless you explicitly opt into approve flows elsewhere
Next: deepen Integrations, wire MCP, or practice Safety on a sandbox mutate. Narrative version of this path: brownfield in 15 minutes.