All posts
Muhtalip Dede profile photoMuhtalip Dede · Founder of kprompt2 min read

Brownfield kprompt in 15 minutes — adopt without rebuilding the stack

Starting from zero with kind is easy. The real challenge is attaching kprompt to a cluster you already run: bind existing Prometheus, read-first insight, optional MCP — install last.

Greenfield demos sell themselves. Spin kind, run the Observe walkthrough, watch CrashLoop become a story. That path matters — it is not how most teams meet a new ops tool.

Most clusters already have Helm on someone's laptop, a Prometheus somewhere, GitOps controllers, and RBAC nobody wants to reopen for a vendor agent. The challenge is not “can we install kprompt?” It is: how fast can we get a useful insight without installing a second monitoring stack?

We wrote the durable steps as Adopt on an existing cluster. This post is the argument and the anti-patterns. The docs page is the checklist you keep open.

The thesis

kprompt is a natural-language interface over tools you already trust — not a replacement for Helm, Argo, Prometheus, or kubectl. Brownfield adoption should maximize bind and read, and treat install as an exception you approve on purpose.

  • Detect what is already there (kprompt tools / doctor)
  • Configure URLs and PATH — do not silently provision operators
  • First value is a read: explain, why slow, optimize report, dependency graph
  • Mutations stay plan → safety → approve; MCP never applies

Fifteen minutes, scored

MinuteMoveWhy
0–2Install CLI + confirm kubecontextNo new cluster; staging/sandbox first
2–5kprompt init (Ollama or BYOK) + doctorNL needs a provider; keys stay out of config.yaml
5–8kprompt tools → config set Prom/Grafana/OTel URLsBind beats install when backends exist
8–12Read prompts: explain / why slow / optimize / graphRisk = 0; RBAC is yours
12–15Optional MCP + one plan-only mutateIDE reach without apply authority

Bind, don’t bootstrap

kprompt tools
kprompt config set tools.prometheus.url http://prometheus.monitoring:9090
kprompt doctor

kprompt "explain why checkout is failing" -n payments
kprompt "why is my api slow?" -n payments
kprompt "optimize my cluster"

When tools reports Prometheus missing, the brownfield instinct is “point at the URL we already scrape,” not “helm install kube-prometheus-stack so the demo looks green.” Setup exists for true gaps — dry-run by default, approve-gated apply — and it is the wrong default for a working platform.

MCP is reach, not a second control plane

If your team lives in Cursor or Claude Desktop, kprompt mcp serve is the fastest way to put investigate / why / plan next to the chat. The assistant can compile a mutate into PlanResult JSON. It cannot approve. That split is the product: editor convenience without dissolving the human gate.

Anti-patterns we keep seeing

  • Treating setup --profile platform as day-0 on a cluster that already has monitoring
  • First session on production with --approve
  • Expecting the IDE agent to apply because “MCP means tools can write”
  • Skipping doctor when the inventory looks empty — often a missing URL, not a missing CRD
  • Measuring success as “every integration green” instead of “one honest insight”

What we are not claiming

  • Not that every cluster lights every tool in 15 minutes
  • Not that kprompt replaces your GitOps or Helmfile installer
  • Not silent Autopilot or auto-heal on brownfield day one
  • Not a hosted multi-cluster SaaS — laptop kubeconfig + your RBAC

Experimental CLI, same as always. Prefer non-production contexts. Read every plan. The win condition for this challenge is simple: useful insight, zero unnecessary installs, safety contract intact.

Related posts