# kprompt — full documentation for AI assistants

> Open-source Kubernetes CLI: natural language → reviewable plans → approve before apply. Optional Observe agent (Helm) for always-on namespace alerts — Autopilot stays propose-only.

Canonical site: https://kprompt.ai
llms.txt index: https://kprompt.ai/llms.txt
GitHub: https://github.com/kprompt/kprompt
X: https://x.com/kpromptai
LinkedIn: https://www.linkedin.com/company/kprompt
Contact: hello@kprompt.ai
License: Apache-2.0
Version: v0.5.0
Docs last updated: 2026-07-26

## Positioning (honest)

- Same NL-CLI lane as kubectl-ai; different mutate contract (plan → safety → approve).
- Not a K8sGPT fleet scanner; not a Kagent multi-agent framework; not a hosted Lens clone.
- Optional in-cluster Observe agent (Helm): namespace watch → Incident → gated notify.
- Autopilot (ADR-0015) is propose-only by default — never silent apply.
- Long-term direction: AI SRE (investigate / why / timeline) still under approval — see roadmap.

## FAQ

### Does kprompt apply changes to my cluster automatically?

No. Every mutating intent compiles into a PlanResult that lists the resources, diffs, and risk level before anything runs. On a TTY you confirm with y/N; in scripts you pass --approve explicitly. Wipe-class prompts are hard-denied instead of planned, and Autopilot is propose-only by default (ADR-0015) — it never applies silently.

More: https://kprompt.ai/docs/safety

### How is kprompt different from kubectl-ai?

Both turn natural language into Kubernetes actions from the terminal. The difference is the mutate contract: kprompt always compiles intent into a reviewable plan with diffs and a risk verdict, runs a safety engine with hard denies, and emits CI-stable PlanResult JSON you can gate a pipeline on. It is an intent compiler with an approval boundary rather than a chat loop that executes.

More: https://kprompt.ai/blog/kprompt-vs-kubectl-ai

### Should I replace kubectl or K9s with kprompt?

No. kubectl remains the precise API client and scripting language; K9s remains the best live terminal UI for watching rollouts and hopping between Pods. kprompt sits beside them when the bottleneck is translating intent into a reviewable plan — not when you need exact flags or a resource browser.

More: https://kprompt.ai/blog/kubectl-alternatives

### Where do my kubeconfig and API keys live?

On your machine. kprompt reads your existing kubeconfig locally and uses your own LLM API keys from environment variables (BYOK). Cluster credentials are not uploaded to a control plane by default, and ~/.kprompt/config.yaml never stores API keys — only whether a key is set.

More: https://kprompt.ai/docs/providers

### Which LLM providers does kprompt support?

OpenAI, Anthropic, Gemini, Groq, and local models through Ollama, among others. You bring your own key, pick a provider and model with kprompt config set, and switch per command when you want a cheaper or stronger model for a given prompt.

More: https://kprompt.ai/docs/providers

### Can I use kprompt in CI/CD pipelines?

Yes, for plan generation and gating. kprompt emits a stable JSON PlanResult with intent, resources, diffs, and risk, so a pipeline can fail on high-risk plans or post the plan to a pull request before a human approves the apply step.

More: https://kprompt.ai/docs/ci

### What does the Observe agent actually do?

The optional Observe agent (installed with Helm) watches a namespace, turns anomalies into an Incident, and sends gated Slack or webhook notifications. It runs with namespace-scoped Role RBAC and does not mutate your cluster — it is an observer, not a self-healer.

More: https://kprompt.ai/docs/agent

### Is kprompt production ready?

It is labelled experimental on purpose. Plans can be wrong or incomplete outside the hard-deny rules, so read every plan before apply, start on kind or a sandbox cluster, and treat --approve with care. You remain responsible for changes applied with your kubeconfig credentials.

More: https://kprompt.ai/docs/roadmap

### Is kprompt free and open source?

Yes. The CLI is Apache-2.0 licensed on GitHub and stays free. There is an optional Team surface for organisations that already have access, but there is nothing to buy as a public signup product today.

More: https://kprompt.ai/docs/install

---

# Documentation

# Overview

URL: https://kprompt.ai/docs

kprompt is an experimental open-source CLI that turns natural language into a reviewable Kubernetes plan, then applies with approval.

## Experimental — use carefully

kprompt is early software. Plans can be wrong, incomplete, or unsafe outside the hard-deny rules. Always read the plan (and diffs) before apply. Prefer non-production or kind clusters while you learn the tool. Avoid --approve on unfamiliar prompts. You remain responsible for changes applied with your kubeconfig credentials.

Talk to your cluster from the terminal you already use. kprompt uses your kubeconfig and your LLM API keys (BYOK). Mutations always produce a plan; risk checks and hard denies run before apply.

## What it is

- Apache-2.0 CLI for day-2 Kubernetes ops
- Plan → safety → approve → apply loop
- Deploy, scale, rollback, named delete
- Deep read path: get/list, explain, logs, describe
- Helm, Argo Workflows, Prometheus, OpenTelemetry, Grafana
- Tekton, KEDA, Istio (read-first), Crossplane, Flux/Argo CD GitOps
- Optimize reports, service dependency graphs, multi-tool routes
- Local history, CI JSON PlanResult, Homebrew install, optional Team login
- Optional Observe agent (Helm) — namespace watch → Incident → gated Slack/webhook; no mutate

## What it is not (yet)

- Not production-hardened or stability-guaranteed
- Not Autopilot-by-default — optional agent is Observe; Autopilot MVP is propose-only (ADR-0015)
- Not a Kagent-class multi-agent framework or a K8sGPT fleet scanner
- Not a replacement for Helm, Argo, Prometheus, kubectl, or operator review
- Not a Lens/Headlamp replacement — optional local read-only inventory is kprompt-dash (localhost only)
- Not a hosted multi-cluster / fleet SaaS — multi-context is laptop kubeconfig fan-out only (no kubeconfig upload)
- Not a public Team signup product — CLI enrollment is opt-in for orgs that already have access
- Nothing to buy today; Free CLI stays free

Where we are headed (AI SRE investigate, trust loops, multi-cluster) is documented honestly on Roadmap & vision — shipped vs building vs exploring. Multi-context CLI docs: Multi-cluster. Observe agent install: Observe agent.

Source of truth for the binary: github.com/kprompt/kprompt. This site mirrors install, safety, providers, and CI docs for operators who land here first.

---

# Install

URL: https://kprompt.ai/docs/install

Install the kprompt CLI on macOS or Linux from the release script, Homebrew, or source — then verify with kprompt doctor.

Installing is easy; applying is not automatically safe. After install, start on a sandbox cluster and leave --approve off until you know how plans look.

## Recommended

```
curl -fsSL https://kprompt.ai/install | bash
```

Detects your OS and architecture, downloads the matching binary from the latest GitHub Release, and installs it into ~/.local/bin. No sudo is needed because it avoids root-owned paths like /usr/local/bin.

## Homebrew

```
brew install kprompt/tap/kprompt
```

Installs the official GitHub Release binary via the kprompt/homebrew-tap formula (macOS and Linux).

## Fallback (jsDelivr, pinned tag)

```
curl -fsSL https://cdn.jsdelivr.net/gh/kprompt/kprompt@v0.5.0/install/install.sh | bash
```

Use this when kprompt.ai is unreachable or when you want the installer itself pinned to a release tag rather than served from the site.

## Supported platforms

| OS | Architectures | How to install |
| --- | --- | --- |
| macOS | arm64 (Apple Silicon), amd64 | Install script or Homebrew |
| Linux | amd64, arm64 | Install script or Homebrew |
| Windows | amd64, arm64 | Build from source with Go |

The install script covers macOS and Linux and exits with a clear message on any other OS or architecture. Windows users build from source — the CLI itself is plain Go with no platform-specific cluster access.

## Installer options

| Variable | Default | Purpose |
| --- | --- | --- |
| KPROMPT_VERSION | latest release | Pin a specific tag, for example v0.5.0 |
| KPROMPT_INSTALL_DIR | ~/.local/bin | Install elsewhere; system paths usually need sudo bash |

(Pin a version, or install system-wide)
```
KPROMPT_VERSION=v0.5.0 curl -fsSL https://kprompt.ai/install | bash

# system-wide (root-owned target needs sudo)
KPROMPT_INSTALL_DIR=/usr/local/bin curl -fsSL https://kprompt.ai/install | sudo bash
```

## PATH

```
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
kprompt version
```

The installer warns when the target directory is missing from your PATH. Use ~/.bashrc instead of ~/.zshrc on shells that read it.

## Verify the install

```
kprompt version
kprompt doctor          # kubeconfig + LLM key + integrations + Team health
kprompt doctor --json   # same checks, machine-readable
```

kprompt doctor is the fastest way to confirm a working setup: it checks that a kubeconfig context resolves, that an LLM API key is present, which day-2 integrations were detected, and whether optional Team enrollment is healthy. It exits non-zero when a required check fails, so it also works as a CI preflight.

## Upgrade

```
# script installs: rerun it
curl -fsSL https://kprompt.ai/install | bash

# Homebrew
brew upgrade kprompt/tap/kprompt
```

## Uninstall

```
rm ~/.local/bin/kprompt        # or: brew uninstall kprompt
rm -rf ~/.kprompt              # config, history, cached policy/credentials
```

Removing ~/.kprompt clears local config, prompt history, and any cached Team policy or credentials. It never touched your kubeconfig, so cluster access is unaffected.

## Troubleshooting

| Symptom | Cause | Fix |
| --- | --- | --- |
| command not found: kprompt | Install directory is not on PATH | Add ~/.local/bin to PATH, then reload the shell |
| Cannot write to … (permission denied) | Target directory is root-owned | Keep the default ~/.local/bin, or rerun with sudo bash |
| No GitHub release found yet | Release lookup failed or was rate-limited | Set KPROMPT_VERSION, or go install ./cmd/kprompt |
| unsupported os / unsupported arch | Platform outside macOS and Linux on amd64/arm64 | Build from source with the Go toolchain |

## From source

```
git clone https://github.com/kprompt/kprompt.git
cd kprompt
go install ./cmd/kprompt
```

Or build into a local path without touching your Go bin directory:

```
go build -o bin/kprompt ./cmd/kprompt
./bin/kprompt version
```

Source builds need Go 1.23 or newer. Next: set a provider key, then walk the plan → approve loop on a sandbox cluster.

---

# Quickstart

URL: https://kprompt.ai/docs/quickstart

Kubeconfig, config file, API key, and your first prompts — carefully.

Start on a disposable cluster (kind, minikube, or a dedicated sandbox). Do not point an unreviewed --approve flow at production until you have practiced the plan → approve loop.

## 1. Cluster access

```
kubectl config current-context
kubectl get ns
```

## 2. Save defaults (no secrets)

```
kprompt config set provider gemini
kprompt config set model gemini-2.0-flash
kprompt config set namespace default
kprompt config
```

Config lives at ~/.kprompt/config.yaml. It never stores API keys — only whether a key is set or unset in the environment.

## 3. Export an API key

```
export KPROMPT_GEMINI_API_KEY="..."
# or OPENAI / ANTHROPIC / GROQ / … — see Providers
```

## 4. Prompt

```
kprompt "list deployments"
kprompt "scale api to 3"          # plan + y/N on a TTY
kprompt "scale api to 3" --approve --wait
kprompt "explain why api is crashing"
kprompt tools
```

## 5. Pick a terminal theme

```
kprompt --theme dracula "list deployments"
kprompt config set theme nord
# auto | dracula | nord | gruvbox | mono | none
```

Themes only color terminal output, respect NO_COLOR, and stay disabled when stdout is not a TTY. See Themes for environment overrides.

## 6. Try an installed integration

```
kprompt tools
kprompt "install redis"                         # Helm
kprompt "train a yolov11 model" --approve --wait # Argo Workflows
kprompt "why is my api slow?" -n production      # Prometheus
kprompt "optimize my cluster"                    # read-only report
kprompt "show service dependency graph"
kprompt "show gitops sync status"
```

Run kprompt tools first. Integrations use real CLIs/CRDs and configured endpoints; missing dependencies produce setup hints instead of fabricated output.

## 7. Optional Team enrollment

```
kprompt login --open
kprompt whoami
kprompt policy pull
kprompt policy
```

Free CLI behavior is unchanged until you enroll. Login is for orgs that already have Team access — not a public signup funnel.

## History

```
kprompt history
kprompt history rerun
kprompt history rerun 3 --approve
```

---

# Commands

URL: https://kprompt.ai/docs/commands

Supported intents, prompt examples, and useful flags in the shipped CLI.

## Supported intents

| Intent | Examples | Notes |
| --- | --- | --- |
| deploy | "deploy redis" | Deployment ± Service shortcuts |
| scale | "scale api to 10" | Deployment replicas |
| rollback | "rollback payment-api" | Rollout undo |
| delete | "delete deployment redis" | Named Pod/Deployment/Service only |
| get / list | "list deployments" | Read-only; built-ins + discoverable CRDs |
| explain | "explain why api is crashing" | Deployment → ReplicaSet → Pods → Events → Logs; may suggest patch |
| logs | "logs payment-api" | Tail |
| describe | "describe payment-api" | Compact describe |
| Helm install / upgrade | "install redis" | Template and dry-run preview before approval |
| workflow | "train a yolov11 model" | Argo Workflow generate/submit/status/--wait |
| performance | "why is my api slow?" | Read-only Prometheus-backed diagnosis |
| trace | "trace payment request" | Jaeger/Tempo span tree + bottlenecks |
| dashboard | "show payments dashboard" | Grafana search + panel summary |
| optimize | "optimize my cluster" | Read-only idle / rightsizing / HPA hints |
| graph | "show service dependency graph" | Service graph (+ optional OTel edges) |
| GitOps | "show gitops sync status" | Flux/Argo CD health; approved sync |
| Tekton | "run the build pipeline" | PipelineRun generate/submit/status |
| KEDA | "autoscale api with KEDA" | ScaledObject generate/submit/status |
| Istio | "show traffic for checkout" | VirtualService traffic summary (read-first) |
| Crossplane | "provision a postgres database" | Cloud claims; RiskHigh + strong approval |
| route | "why is api slow then scale api to 4" | Multi-tool chain; one aggregate approval |

## Prompt examples

```
# Kubernetes day-2
kprompt "list deployments"
kprompt "how many nodes are in the cluster"
kprompt "scale api to 3" -n staging
kprompt "rollback payment-api" --approve --wait
kprompt "explain why redis is crashing"

# Observability
kprompt "why is my api slow?" -n production
kprompt "trace payment request"
kprompt "show dashboard"

# North-star reports
kprompt "optimize my cluster"
kprompt "show service dependency graph"

# Ecosystem
kprompt "install redis" -n cache
kprompt "show gitops sync status"
kprompt "provision a postgres database"

# Multi-tool route (one plan, one approval for mutating chains)
kprompt "why is api slow then scale api to 4"
```

## Flags

| Flag | Description |
| --- | --- |
| --approve | Apply without interactive confirmation |
| --wait | After apply, wait for Deployment rollout or Workflow/PipelineRun terminal phase |
| --timeout | Timeout for --wait (default 5m) |
| --output / -o | text (default) or json (PlanResult) |
| --theme | auto, dracula, nord, gruvbox, mono, or none |
| --provider | LLM provider id |
| --model | Model id |
| --context | kubeconfig context |
| --contexts | comma-separated contexts for read fan-out / per-context mutate (aliases ok) |
| --approve-each-context | Apply a mutating plan to every --contexts entry (explicit; not implied by --approve) |
| -n / --namespace | Namespace (wins over prompt phrases) |
| --open | With login: open the browser for device approval |

## Subcommands

- kprompt config / config set … / config alias set|unset
- kprompt contexts / contexts --check / contexts --json
- kprompt history / history rerun [n]
- kprompt tools
- kprompt doctor
- kprompt dash — local read-only cluster UI (requires kprompt-dash on PATH; not a Lens replacement)
- kprompt login / login --open / logout / whoami
- kprompt policy / policy pull
- kprompt secrets pull
- kprompt version

## Context aliases

Map short names to kubeconfig contexts. Optional require_alias_match refuses mutating apply when kubectl’s current-context does not match the resolved target (wrong-cluster guard). Inventory: kprompt contexts. Read fan-out: --contexts or “across staging and prod” (get/list/explain/logs/describe/optimize). Multi-context mutate asks per context; plain --approve is refused — use interactive confirms or --approve-each-context. PlanResult includes cluster_context on the document and each action; fleet optimize adds fleetSummary.

```
kprompt config alias set prod gke_myproj_us-central1_prod
kprompt config alias set staging kind-staging
kprompt contexts
kprompt --contexts staging,prod "list deployments"
kprompt --contexts staging,prod "optimize my cluster"
kprompt "list pods across staging and prod"
kprompt --contexts staging,prod "scale api to 3"
kprompt --contexts staging,prod --approve-each-context "scale api to 3"
kprompt --context prod "list deployments"
kprompt config set require_alias_match true
```

For the local dash quickstart and security defaults, see the Local cluster dash docs. Full multi-context honesty (what is / is not): Multi-cluster.

---

# Local cluster dash

URL: https://kprompt.ai/docs/dash

kprompt-dash is a simple localhost, read-only cluster inventory — see the cluster, then hand off to kprompt for plan → approve → apply. Not a Lens or Headlamp replacement.

kprompt-dash is an optional OSS companion binary. It binds to 127.0.0.1 by default, uses your kubeconfig like kubectl, and stays read-only. Mutations remain in the CLI plan → approve loop.

## Install & run

```
go install github.com/kprompt/kprompt-dash/cmd/kprompt-dash@latest
kprompt dash
# or: kprompt-dash -open
```

Opens http://127.0.0.1:7474 with Cluster, Nodes, Deployments, ReplicaSets, and Pods — plus detail (events / short logs) and copyable kprompt prompt handoff.

## What it is not

- Not a hosted multi-tenant dashboard on app.kprompt.ai
- Not in-browser mutate / apply
- Not a full CRD / RBAC / Helm explorer
- Not Lens or Headlamp parity

## Security

- No HTTP authentication — anyone who can reach the port shares your kube privileges
- Default listen address is loopback only
- Non-loopback binds require an explicit -allow-remote flag

---

# Multi-cluster

URL: https://kprompt.ai/docs/multi-cluster

Laptop-local multi-context: aliases, read fan-out, per-context mutate safety, fleet optimize. Not a hosted Lens/fleet SaaS — kubeconfig never leaves your machine.

kprompt’s multi-cluster story is laptop-local: aliases and explicit fan-out over your kubeconfig contexts. Credentials stay on the device. The optional Team control plane may later store metadata only (display name, alias, which enrolled CLI can reach a cluster) — never kubeconfig upload.

## Inventory & aliases

```
kprompt contexts
kprompt contexts --check
kprompt config alias set prod gke_myproj_us-central1_prod
kprompt --context prod "list deployments"
kprompt config set require_alias_match true
```

## Read fan-out

Opt-in only — never “all contexts” by default. Supported: get/list, explain, logs, describe, optimize. JSON kind MultiContextResult includes per-context steps and cluster_context; optimize adds fleetSummary.

```
kprompt --contexts staging,prod "list deployments"
kprompt "list pods across staging and prod"
kprompt --contexts staging,prod "optimize my cluster"
```

## Mutate safety

- Interactive: confirm each context separately
- Plain --approve across multiple contexts is refused
- --approve-each-context is the explicit multi-apply escape hatch

```
kprompt --contexts staging,prod "scale api to 3"
kprompt --contexts staging,prod --approve-each-context "scale api to 3"
```

## What this is not

- Not uploading kubeconfigs to api.kprompt.ai or app.kprompt.ai
- Not a hosted live multi-cluster browser (Lens/Headlamp clone)
- Not silent --approve across every context
- Not an always-on in-cluster multi-cluster agent
- Not a replacement for kprompt-dash’s single-cluster localhost inventory

---

# Terminal themes

URL: https://kprompt.ai/docs/themes

Choose readable semantic colors for kprompt plans, risks, findings, and tables.

CLI themes style semantic output such as headings, success, warnings, denied risks, resource names, and muted details. They do not change planning or safety behavior.

## Built-in themes

| Theme | Use |
| --- | --- |
| auto | Compatible terminal colors; the default |
| dracula | Dracula true-color palette |
| nord | Nord true-color palette |
| gruvbox | Gruvbox true-color palette |
| mono | Bold and dim structure without color |
| none | Plain output with all ANSI styling disabled |

## Select a theme

```
# One command
kprompt --theme dracula "list deployments"

# Persist the default
kprompt config set theme nord

# Environment override when no flag/config value is set
export KPROMPT_THEME=gruvbox
```

## TTY and color behavior

- Color is enabled only for terminal output by default
- Any non-empty NO_COLOR disables ANSI styling
- KPROMPT_FORCE_COLOR=1 forces styling for ANSI-aware pipes or captures
- JSON output remains machine-readable; never force color into JSON consumers
- An unknown theme safely falls back to auto

---

# Integrations

URL: https://kprompt.ai/docs/integrations

Use Helm, Argo, Prometheus, OTel, Grafana, Tekton, KEDA, Istio, Crossplane, and GitOps through detected tools and real APIs.

kprompt orchestrates integrations; it does not replace them. Run kprompt tools to see what is installed or configured. Mutating operations still pass through plan, safety, and approval.

```
kprompt tools
```

## Generic Kubernetes reads

Get/list any discoverable built-in or CRD via discovery and the dynamic client. Cluster-scoped resources (Node) ignore namespace; Secrets use the same table path (type + key count). Authorization is your kubeconfig RBAC.

```
kprompt "how many nodes are in the cluster"
kprompt "list configmaps" -n default
kprompt "list widgets.example.com" -n demo
```

## Helm

Install and upgrade plans call the Helm CLI and surface template/dry-run previews. Helm must be available on PATH. Uninstall remains wipe-class and receives stricter safety treatment.

```
kprompt "install redis" -n cache
kprompt "upgrade prometheus chart" -n monitoring
```

## Argo Workflows

kprompt detects the Workflow CRD, generates a reviewable manifest, submits it with the Kubernetes dynamic client, and can report or wait for terminal status.

```
kprompt "train a yolov11 model"
kprompt "train a yolov11 model" --approve --wait
kprompt "get workflow train-yolov11"
```

## Prometheus

Performance explain is read-only. It uses bounded instant/range queries to inspect CPU, memory, p95 latency, replica, and HPA signals for a workload.

```
kprompt config set tools.prometheus.url http://prometheus.monitoring:9090
kprompt "why is my api slow?" -n production
```

## OpenTelemetry (Jaeger / Tempo)

Trace intents search the configured Jaeger or Tempo backend, print a span tree, and narrate bottleneck spans when present.

```
kprompt config set tools.otel.endpoint http://tempo.monitoring:3200
kprompt config set tools.otel.backend tempo
kprompt "trace payment request"
```

## Grafana

Dashboard intents search Grafana and summarize panel metadata (read-only). Configure URL and API token via tools.grafana.* or environment variables.

```
kprompt config set tools.grafana.url https://grafana.example
kprompt "show payments dashboard"
```

## Optimize & service graph

Optimize is a read-only cluster report (idle workloads, rightsizing, HPA hints). Optional follow-up scale/patch plans still require their own approval. Service graphs build from Kubernetes Services/Endpoints and can add OTel call edges when configured. Walkthrough: optimize my cluster.

```
kprompt "optimize my cluster"
kprompt "show service dependency graph"
kprompt "show service dependency graph for payments"
```

## Tekton · KEDA · Istio · Crossplane

Tekton PipelineRuns and KEDA ScaledObjects generate reviewable CRs before submit. Istio is read-first (VirtualService traffic/canary summary). Crossplane cloud claims are RiskHigh and need strong approval.

```
kprompt "run the build pipeline"
kprompt "autoscale api with KEDA to zero when idle"
kprompt "show traffic for checkout"
kprompt "provision a postgres database"
```

## GitOps (Flux / Argo CD)

Status and health are read-only. Sync / promote / rollback paths require approval and apply through the real Flux Kustomization or Argo CD Application APIs.

```
kprompt "show gitops sync status"
kprompt "sync the payments application" --approve
```

## Multi-tool routes

Chain steps across backends with then / and then. Mutating chains show one aggregate plan and ask for a single approval.

```
kprompt "why is api slow then scale api to 4"
kprompt "show gitops sync status then sync payments" --approve
```

---

# Observe agent

URL: https://kprompt.ai/docs/agent

Optional namespace-scoped Observe Mode agent (v0.5): Helm/Operator, Role RBAC, memory & patterns. Autopilot is propose-only (ADR-0015).

Shipped in kprompt v0.5. The laptop CLI stays a single binary with no required daemon. Separately, you can opt into an in-cluster Observe agent that watches one namespace, correlates Incidents, optionally calls an LLM, and notifies Slack or a webhook.

## Observe by default — Autopilot propose-only

- Observe Mode never applies, patches, or deletes workload objects
- Autopilot MVP (--autopilot-propose) emits PlanResult-shaped proposals + audit; Applied stays false
- Policy allowlist + ADR-0015 gates required before any future apply executor
- Recommendations may suggest a fix for a human to approve on the CLI

Full Autopilot contract: ADR-0015.

## vs K8sGPT and Kagent

| Tool | Job | kprompt Observe |
| --- | --- | --- |
| K8sGPT | On-demand / scheduled analyzer (scan → explain) | Always-on watch → correlated Incident → confidence-gated alert — not a fleet scanner |
| Kagent | In-cluster multi-agent framework | One kprompt-native Observe pipeline; not a general agent platform |
| kprompt CLI | Reactive plan → approve → apply | Agent is optional; CLI needs no daemon |

## RBAC (honest)

- Default: Role + RoleBinding in one namespace (get/list/watch) — not ClusterRole
- Secrets watch is off by default; when enabled, metadata only (never values)
- You own the ServiceAccount blast radius you deploy

## LLM cost

- No LLM call on every raw API event — batch by open Incident
- Severity + confidence gate before Slack/webhook (defaults: medium / 0.7)
- Use --heuristic for demos; mount provider keys via Secret only

## Namespace memory

- Optional --memory discovers Redis/Kafka/Postgres-style deps from Services/Deployments
- Stores facts locally (~/.config/kprompt/memory) or in-cluster ConfigMap — never uploaded to api.kprompt.ai by default
- Relevant facts inject into AgentContext for the analyzer
- Optional --patterns learns signatures and boosts confidence on “seen before” (never mutates)
- Optional --autopilot-propose emits allowlisted AutopilotProposal (propose-only; ADR-0015)

## Operator (optional)

kprompt agent operator reconciles KpromptAgent CRs into Observe agent Deployments (ServiceAccount + Role + RoleBinding + Deployment). Helm chart: charts/kprompt-operator. Prefer the manual kprompt-agent chart when you do not want a ClusterRole for the operator SA. Autopilot propose is a CLI flag on the agent binary — not silent mutate.

## Helm install

(Secret + chart (image tag = release))
```
kubectl -n payments create secret generic kprompt-agent \
  --from-literal=OPENAI_API_KEY="$OPENAI_API_KEY"
helm upgrade --install kprompt-agent ./charts/kprompt-agent \
  -n payments --create-namespace \
  --set image.tag=0.5.0
```

Laptop smoke: kprompt agent run -n payments --analyze --fetch-logs --health --heuristic. Add --memory, --patterns, or --autopilot-propose as needed. Full flags in the repo agent doc.

## Demo cluster

Need a payments namespace that actually misbehaves? kprompt-examples spins up kind with seven failure scenarios (crashloop, image pull, OOM, stalled rollout, unbound PVC, failing CronJob, missing dependency). Each README states what the agent should conclude — so a demo has a right answer.

(kind + crashloop, then Observe agent (heuristic = offline))
```
git clone https://github.com/kprompt/kprompt-examples.git
cd kprompt-examples
make up
make break SCENARIO=01-crashloop
make verify
kprompt agent run -n payments --analyze --health --heuristic
```

---

# Roadmap & vision

URL: https://kprompt.ai/docs/roadmap

Where kprompt is headed: AI SRE investigation, trust loops, multi-cluster, and what stays out of scope. Honest shipped vs exploring.

## Positioning

kprompt is an intent compiler today: natural language → reviewable PlanResult → approve → apply. The long-term bet is AI SRE — thinking about the cluster (investigate, why, timeline, blast radius, verify) while keeping the same approval contract. Not a free-form chat REPL, not a silent analyzer daemon, not a hosted fleet scanner. Read Building AI SRE in Public, Intent compiler, not chat, Kubernetes AI tools compared, and Beyond AI kubectl for public positioning.

## Shipped now

- Plan → safety → approve → apply (deploy, scale, rollback, named delete)
- Deep explain, logs, describe, discovery-backed get/list
- Helm, Argo Workflows, Prometheus, OTel, Grafana, multi-tool routes
- Tekton, KEDA, Istio (read-first), Crossplane, Flux/Argo CD GitOps
- Optimize-cluster report (idle / rightsizing / HPA) and service dependency graph
- Context aliases, doctor, Homebrew, optional Team login / policy / audit
- Local read-only inventory via kprompt dash (localhost)
- Optional Observe agent (Helm): namespace watch → Incident → gated Slack/webhook — no silent Autopilot mutate
- Optional Operator: KpromptAgent CR → Observe agent Deployment
- Autopilot propose-only MVP (--autopilot-propose) under ADR-0015

Full integration detail lives on Integrations — not duplicated here. Observe agent install and honesty notes: Observe agent.

## Building next — trust & AI SRE

These deepen “think about the cluster” without leaving the plan/approve loop. Treat as in progress — not a public ship date.

- Blast-radius preview on mutating plans (who/what is affected)
- Post-apply verify — confirm the goal after --wait, not only “applied”
- investigate — multi-hop RCA (ingress → Service → Endpoints → Pods → events → logs → mesh/DNS)
- why — causal state trees (e.g. Pending → affinity → no GPU nodes)
- timeline — incident chronology from events, rollouts, HPA (+ optional metrics)
- audit / cleanup / drift — hygiene scans and GitOps drift reports with optional approved remediations
- GitOps PR mode — open/update a PR instead of live mutate when Flux/Argo CD is in play

## Exploring later

- Proactive local watch (opt-in laptop): signal → “latency up; investigate?” — never auto-mutate
- Local remember / session digests (facts stay on your machine by default)
- Multi-cluster: contexts inventory, read fan-out, explicit per-cluster mutate safety; org registry metadata without uploading kubeconfig
- Team web polish on app.kprompt.ai (policy, audit, Insights) — CLI stays free; nothing to buy today
- Workflow recipe packs (harden production, Ingress → Gateway API) as curated plan chains
- Autopilot policyAuto apply executor (ADR-0015) — MVP today is propose-only

## What we will not do

- Silent apply across clusters from one --approve
- Upload kubeconfig / cluster credentials to the control plane
- Replace Lens/Headlamp as a hosted live cluster browser
- Compete on free-form agent chat with kubectl-ai
- Claim K8sGPT analyzer parity as a fleet scanner
- Ship Autopilot mutate without a new ADR + PlanResult + policy gates
- Pretend Observe agent is Kagent feature parity

## Shape priorities

Star issues and PRs on GitHub. The CLI stays Apache-2.0 and experimental — review every plan before apply. Start with Quickstart when you are ready to try it.

---

# Team enrollment

URL: https://kprompt.ai/docs/team

Optional CLI login for org policy sync and audit push. Free CLI stays free; enrollment does not change behavior until you enroll.

Team enrollment is opt-in. Until you run kprompt login, the CLI behaves as Free: local safety only, no control-plane calls. There is no public buy/signup CTA on this site — enrollment is for orgs that already have Team access.

## Login

```
kprompt login            # device code → approve at app.kprompt.ai/connect
kprompt login --open     # also open the browser
kprompt whoami           # org + member
kprompt logout           # revoke token + clear credentials/policy
```

The kp_… token is stored only in ~/.kprompt/credentials.yaml (mode 0600), never in config.yaml. Override the API with KPROMPT_API_URL / KPROMPT_API_TOKEN when needed.

## Org policy

Pull caches org policy locally. Cached policy only tightens local hard-denies (namespace allow/deny, max risk, deny intents, require approve) — it never relaxes them.

```
kprompt policy pull      # fetch org policy → ~/.kprompt/policy.yaml
kprompt policy           # show cached policy
```

## Audit push

When enrolled, each plan best-effort pushes an audit event (planned / denied / applied) to the control plane. Failures print a warning and never fail the local command. Disable with KPROMPT_DISABLE_AUDIT=1.

## What stays local

- Kubeconfig, cluster traffic, and LLM keys stay on your machine
- Audit payloads omit manifests and secrets
- History remains local (~/.kprompt/history.jsonl)
- You can logout anytime and return to Free CLI behavior

---

# Safety

URL: https://kprompt.ai/docs/safety

How kprompt gates cluster mutations: prompt-level hard denies, plan risk levels, explicit approval, and tighten-only org policy.

Safety features reduce risk; they do not make kprompt safe for unattended production use. The product is experimental. Always review the plan. Skip --approve until you understand the proposed actions.

Every mutating plan is risk-evaluated before apply. On a TTY, kprompt asks y/N unless you pass --approve. Read-only intents (get, list, explain, investigate, why, timeline, impact, logs, describe, performance, trace, dashboard, optimize, graph, Istio traffic, GitOps status) do not require approval.

## Where the checks run

The pipeline is prompt → intent → plan → safety → approval → executor → Kubernetes. Safety runs at two distinct points, which is why some prompts never reach the model at all.

| Stage | What it checks | Effect |
| --- | --- | --- |
| Prompt check | Destructive natural-language patterns | Denied before any LLM call — no token spend |
| Plan evaluation | Actions, resource kinds, names, integration rules | Assigns risk or denies the plan outright |
| Org policy overlay | Cached Team policy, when enrolled | May only tighten the local verdict |
| Approval | TTY confirmation or explicit --approve | Last gate before the executor runs |

## Hard denies

Some prompts are refused by pattern before the model is called: wiping or destroying the cluster, deleting everything or all namespaces, and deleting a namespace by name. These are cheap, deterministic refusals rather than a judgement call left to the LLM.

(Refused before any LLM spend)
```
$ kprompt "delete everything in the cluster"
🚨 Intent: destructive cluster operation
🛡️ Safe execution: denied
😅 Your cluster lives another day
```

A second layer denies unsafe plans even when the wording looked harmless. Deletes must name a single resource, and only three kinds are deletable at all.

| Plan-level rule | Why |
| --- | --- |
| Delete must target Pod, Deployment, or Service | Any other kind is refused rather than guessed at |
| Delete must name one resource | Names like *, all, everything, or --all are refused as unscoped |
| Delete without a resource kind is refused | An ambiguous target is never resolved for you |
| Namespace deletion is always refused | Blast radius is too large for a compiled plan |

(Example plan-level deny)
```
kprompt "delete all pods in production"
# Risk: denied — name a single resource
```

## Risk levels

Plans surface one of four verdicts. Denied plans never apply. Medium and high plans still need explicit approval — risk is information for your review, not permission to skip it.

| Risk | Typical intents | Approval |
| --- | --- | --- |
| low | Reads, explain, investigate, optimize reports, service graphs, GitOps status | None required |
| medium | Scale, deploy, install, upgrade, rollback, patch, workflows, Tekton, KEDA, GitOps sync | TTY y/N or --approve |
| high | Named deletes, Crossplane cloud claims, unrecognised intents | Explicit approval; Crossplane needs strong approval |
| denied | Hard-deny prompts and unsafe plans | Never applies |

Integration-specific rules layer on top for Helm, Argo Workflows, Tekton, KEDA, Istio, Crossplane, and GitOps, so a risky chart install or a cloud claim is not treated as a generic mutation. Multi-tool mutating routes produce one aggregate plan and a single approval rather than a chain of prompts.

## Diffs and blast radius

When a live object already exists, plans include a before→after diff so you review the actual change rather than only the intent summary. That is the difference between approving "scale api to 10" as a sentence and approving it as a concrete replica change on a named Deployment.

## Multiple clusters

Fan-out is deliberately asymmetric: reads and optimize rollups can span contexts freely, while mutations cannot be approved for many clusters by accident. --approve never implies cross-context apply; you confirm each context or pass --approve-each-context explicitly. Setting require_alias_match true refuses a mutation unless your kubectl current-context matches the alias you targeted.

## Org policy (when enrolled)

A cached Team policy can only tighten local rules — it never loosens a local hard deny. Pull it with kprompt policy pull and inspect it with kprompt policy.

| Policy field | Effect |
| --- | --- |
| max_risk | Denies any plan whose risk exceeds low, medium, or high |
| deny_intents | Denies named intents outright |
| allow_namespaces | Restricts plans to an allowlist of namespaces |
| deny_namespaces | Denies plans targeting listed namespaces |
| require_approve | Forces approval for medium risk and above |

When enrolled, each plan also best-effort pushes a planned, denied, or applied audit event to the control plane. Disable it with KPROMPT_DISABLE_AUDIT=1.

## What safety does not do

- It does not verify that a plan is correct — only that it is not obviously destructive
- It does not replace kubeconfig RBAC; kprompt can only do what your credentials allow
- It does not redact Secret values from reads you are already authorised to perform
- It does not make --approve in CI equivalent to human review
- It does not cover generic mutation of arbitrary resource kinds, which stays out of scope

Treat the safety engine as a floor, not a ceiling. The honest limits, including what Autopilot will and will not do, are documented on the roadmap.

---

# Providers

URL: https://kprompt.ai/docs/providers

Bring your own LLM key: OpenAI, Anthropic, Gemini, Groq, Mistral, DeepSeek, OpenRouter, Together, local Ollama, or any OpenAI-compatible gateway.

kprompt is BYOK (bring your own key). You pick the provider and model, and the request goes from your machine to that provider — there is no kprompt-hosted inference proxy in the middle. Select with --provider or ~/.kprompt/config.yaml (provider, model, optional base_url). API keys are environment variables only and are never written to the config file.

## Supported providers

| Provider | --provider | Env key(s) | Default model |
| --- | --- | --- | --- |
| OpenAI | openai | KPROMPT_OPENAI_API_KEY / OPENAI_API_KEY | gpt-4o-mini |
| Anthropic | anthropic | KPROMPT_ANTHROPIC_API_KEY / ANTHROPIC_API_KEY | claude-sonnet-4-20250514 |
| Google Gemini | gemini | KPROMPT_GEMINI_API_KEY / GEMINI_API_KEY / GOOGLE_API_KEY | gemini-2.0-flash |
| Groq | groq | KPROMPT_GROQ_API_KEY / GROQ_API_KEY | llama-3.3-70b-versatile |
| Mistral | mistral | KPROMPT_MISTRAL_API_KEY / MISTRAL_API_KEY | mistral-small-latest |
| DeepSeek | deepseek | KPROMPT_DEEPSEEK_API_KEY / DEEPSEEK_API_KEY | deepseek-chat |
| OpenRouter | openrouter | KPROMPT_OPENROUTER_API_KEY / OPENROUTER_API_KEY | openai/gpt-4o-mini |
| Together | together | KPROMPT_TOGETHER_API_KEY / TOGETHER_API_KEY | Llama 3.1 8B Turbo |
| Ollama (local) | ollama | none required | llama3.2 |
| OpenAI-compatible | openai-compatible | KPROMPT_OPENAI_API_KEY | requires base_url |

Groq, Mistral, DeepSeek, OpenRouter, and Together all speak the OpenAI-compatible API. Ollama runs locally at http://127.0.0.1:11434/v1 and needs no key at all, which makes it the zero-spend option for trying kprompt or running it in CI.

## How keys are resolved

- The KPROMPT_-prefixed variable is checked first, then the vendor default such as OPENAI_API_KEY
- Environment variables always win over keys pulled from a Team org with kprompt secrets pull
- ~/.kprompt/config.yaml stores provider, model, namespace, and base_url — never a key
- kprompt doctor reports whether a usable key was found without printing its value

## Examples

```
export KPROMPT_OPENAI_API_KEY=sk-...
kprompt "list deployments"

export KPROMPT_ANTHROPIC_API_KEY=sk-ant-...
kprompt --provider anthropic "explain why api is crashing"

export KPROMPT_GEMINI_API_KEY=...
kprompt --provider gemini --model gemini-2.0-flash "deploy redis"

kprompt --provider ollama --model llama3.2 "list pods"
```

## Azure OpenAI and custom gateways

Anything that exposes an OpenAI-compatible endpoint works through the openai-compatible provider plus a base URL. That covers Azure OpenAI, an internal LLM gateway, or a proxy that adds logging and rate limits.

```
export KPROMPT_OPENAI_API_KEY=...
export KPROMPT_OPENAI_BASE_URL=https://YOUR_RESOURCE.openai.azure.com/openai/v1
kprompt --provider openai-compatible --model gpt-4o "list services"
```

## Config file

(~/.kprompt/config.yaml)
```
provider: gemini
model: gemini-2.0-flash
# base_url: https://api.groq.com/openai/v1   # optional override
namespace: default
```

(Or set the same values from the CLI)
```
kprompt config set provider gemini
kprompt config set model gemini-2.0-flash
kprompt config
```

## Choosing a model

- Fast and cheap models handle routine intents like list, scale, and logs well
- Reserve a stronger model for explain, investigate, and why prompts that reason across events and logs
- Local Ollama models avoid all spend but produce weaker plans on ambiguous prompts
- Switch per command with --provider and --model without changing your saved defaults

Model choice affects plan quality, never the approval boundary: a weaker model may produce a worse plan, but it still cannot bypass the safety engine or apply without approval.

---

# CI / JSON

URL: https://kprompt.ai/docs/ci

Stable PlanResult output for pipeline gates.

JSON output helps you gate risky plans in CI. It does not remove the need for human judgment — kprompt remains experimental, and auto-approve in pipelines can still apply a bad plan if your checks are too loose.

Pass --output json or -o json to emit a single PlanResult document on stdout. Human confirmations and wait status go to stderr in JSON mode. Field-by-field walkthrough: PlanResult JSON deep dive.

```
kprompt "scale api to 10" -n prod --output json
```

## Schema

| Field | Notes |
| --- | --- |
| apiVersion | always kprompt.io/v1 |
| kind | always PlanResult |
| schemaVersion | "1" — bump only on breaking changes |
| plan.intent | scale, deploy, workflow, performance, get, route, … |
| plan.actions | ops without YAML manifests |
| risk.level | low / medium / high / denied |
| risk.denied | hard deny |
| applied | whether a mutation ran |
| cluster_context | kubeconfig context for this plan (also on actions[]) |
| blastRadius | optional mutate review aid: namespaces, labels/owners, related HPA/Service/NetworkPolicy (T-069) |
| verify | optional post-apply: ok / pending / failed / skipped (T-070) |
| requiresApproval | true when a mutating plan needs approve |
| result | optional get/explain/logs/describe/workflow/performance payload |

Manifests and API keys are never included.

## Gate example

```
#!/usr/bin/env bash
set -euo pipefail
json="$(kprompt "scale api to 10" -n prod -o json)"
echo "$json" | jq -e '.risk.denied == false' >/dev/null
echo "$json" | jq -e '.plan.intent == "scale"' >/dev/null
kprompt "scale api to 10" -n prod --approve --wait
```

## jq helpers

```
# Fail if any delete is planned
echo "$json" | jq -e '[.plan.actions[].op] | index("delete") | not'

# High-risk gate
echo "$json" | jq -e '.risk.level != "high"'
```

---

# High-signal articles (summaries)

## Break a kind cluster on purpose, then watch the Observe agent

URL: https://kprompt.ai/blog/observe-agent-kind-demo
Published: 2026-07-26

One command from kprompt-examples: kind up, seven failure scenarios, verify they actually broke, then run the Observe agent offline in heuristic mode.

## kprompt v0.5: optional Observe agent, still no silent Autopilot

URL: https://kprompt.ai/blog/kprompt-v0-5-observe-agent
Published: 2026-07-25

v0.5 ships the namespace-scoped Observe agent — watch → Incident → gated Slack/webhook — plus Operator, memory, patterns, and Autopilot propose-only under ADR-0015. The laptop CLI stays plan → approve → apply.

## Building AI SRE in Public

URL: https://kprompt.ai/blog/building-ai-sre-in-public
Published: 2026-07-23

A long-form series on building an AI SRE under an approval boundary — intent compiler, PlanResult, safety, multi-context, investigation, and why we refuse unsupervised auto-remediation. Episode index and honesty rules.

## Building AI SRE in Public #1: Why AI SRE

URL: https://kprompt.ai/blog/building-ai-sre-01-why
Published: 2026-07-23

AI kubectl is not enough. Production needs investigate, why, blast radius, and verify — still behind an approval boundary. Why the AI SRE category exists, what failed in classic AIOps, and what we ship first.

## Building AI SRE in Public #2: Intent Compiler

URL: https://kprompt.ai/blog/building-ai-sre-02-intent-compiler
Published: 2026-07-23

Kubernetes deserves a compiler, not a chatbot. How kprompt turns natural language into Intent → Actions → PlanResult, why Go owns planning and safety, and why the IR must stay reviewable for AI SRE.

## Building AI SRE in Public #3: PlanResult

URL: https://kprompt.ai/blog/building-ai-sre-03-planresult
Published: 2026-07-23

PlanResult is the IR of AI SRE: one typed document for humans and CI. Why JSON, what applied means vs verify, how blastRadius attaches, what never gets stored, and how investigate/why must extend the same artifact.

## Building AI SRE in Public #4: Safety Engine

URL: https://kprompt.ai/blog/building-ai-sre-04-safety
Published: 2026-07-23

Policy is code, not LLM vibes. How kprompt’s safety engine hard-denies wipe-class intents, scores risk, forces approval, and why fail-closed is the load-bearing wall of AI SRE.

## kprompt vs kubectl-ai: same NL CLI lane, different mutate contract

URL: https://kprompt.ai/blog/kprompt-vs-kubectl-ai
Published: 2026-07-23

Both turn English into Kubernetes actions on your laptop. kubectl-ai optimizes for kubectl fluency and agentic chat; kprompt compiles intent into a gated PlanResult — plan, safety, approve — then apply. Decision guide for operators choosing an AI Kubernetes CLI.

## kprompt is an intent compiler, not a Kubernetes chat REPL

URL: https://kprompt.ai/blog/intent-compiler-not-chat
Published: 2026-07-18

Why we compile natural language into a gated PlanResult instead of racing kubectl-ai on agentic chat — same NL CLI lane, different contract: typed plans, hard denies, CI JSON, multi-tool day-2 under one approval loop.

## Beyond AI kubectl: why kprompt is aiming at AI SRE

URL: https://kprompt.ai/blog/ai-sre-not-ai-kubectl
Published: 2026-07-23

Natural language → plan → approve is the wedge. The differentiator is thinking about the cluster — investigate, why, timeline, blast radius, verify — still under the same approval contract. Honest shipped vs building vs exploring.

## Kubernetes AI tools: K8sGPT, kubectl-ai, Kagent, and plan-before-apply CLIs

URL: https://kprompt.ai/blog/kubernetes-ai-tools-comparison
Published: 2026-07-18

Map of Kubernetes AI / k8s AI tools by job: K8sGPT (and Kubegpt-style searches) for diagnosis, kubectl-ai and kprompt for NL CLIs, Kagent for in-cluster agents — honest mutation contracts included.

## optimize my cluster: idle workloads, rightsizing, and HPA hints — without auto-apply

URL: https://kprompt.ai/blog/optimize-my-cluster
Published: 2026-07-23

How kprompt’s shipped optimize report works: inventory, Prometheus-backed idle and rightsizing findings, HPA hints, JSON output, and optional follow-up scale/patch plans that still require their own approval. What it is not.

## PlanResult JSON deep dive: fields, risk, jq recipes, and what is never stored

URL: https://kprompt.ai/blog/planresult-json-deep-dive
Published: 2026-07-23

Schema-focused companion to CI plan gates: apiVersion, plan.actions, risk.denied, result payloads, RouteResult / MultiContextResult, history vs CI artifacts, and hard rules on manifests and API keys.

## Kubernetes in CI/CD: gating cluster changes with plan JSON before apply

URL: https://kprompt.ai/blog/kubernetes-ci-cd-plan-gates
Published: 2026-07-16

How to use kprompt PlanResult JSON in CI/CD pipelines to review Kubernetes scale, deploy, and rollback plans before apply — with jq gates, GitHub Actions patterns, and production safety rules.

## Kubernetes OOMKilled: how to detect memory kills, raise limits, and avoid guesswork

URL: https://kprompt.ai/blog/kubernetes-oomkilled
Published: 2026-07-18

A practical guide to OOMKilled in Kubernetes — exit 137, Last State, memory requests vs limits, kubectl checks, and how kprompt explain can suggest a reviewable memory patch.

## Kubernetes CrashLoopBackOff: how to read it, find the cause, and fix it

URL: https://kprompt.ai/blog/kubernetes-crashloopbackoff
Published: 2026-07-26

CrashLoopBackOff is a symptom, not a cause. How the restart backoff works, what exit codes tell you, the kubectl ladder for finding the real failure, and how to apply a bounded fix you actually reviewed.

## kubectl cheat sheet with natural-language equivalents (kprompt)

URL: https://kprompt.ai/blog/kubectl-cheat-sheet-natural-language
Published: 2026-07-18

A practical kubectl cheat sheet paired with natural-language prompts — get, list, describe, logs, scale, rollback, delete, explain, Helm, and JSON CI — for operators who know the API and want faster day-2 typing.

## Real Kubernetes error prompts: crash loops, OOM, ImagePull, denies, and slow APIs

URL: https://kprompt.ai/blog/kubernetes-error-prompt-playbook
Published: 2026-07-18

A playbook of real incident prompts for Kubernetes — what to type when pods crash, images fail to pull, memory kills, wipe-class mistakes, RBAC denials, and latency spikes — with kprompt examples that stay plan-before-apply.

## How to troubleshoot Kubernetes: deployments, pods, and crash loops from the terminal

URL: https://kprompt.ai/blog/kubernetes-troubleshooting-guide
Published: 2026-07-16

A practical guide to Kubernetes troubleshooting — CrashLoopBackOff, deployments not ready, image pull errors, and rollbacks — using kubectl workflows and natural-language explains with kprompt.

## Kubectl alternatives in 2026: K9s, Kubernetes dashboards, and AI CLIs compared

URL: https://kprompt.ai/blog/kubectl-alternatives
Published: 2026-07-16

Compare kubectl alternatives: K9s terminal UI, Headlamp and Lens dashboards, and natural-language Kubernetes CLIs. Which interface fits navigation, visual management, troubleshooting, and plan-before-apply operations.

## kubectl vs K9s: when to use each (and why you keep both)

URL: https://kprompt.ai/blog/kubectl-vs-k9s
Published: 2026-07-26

A head-to-head for operators: kubectl is the precise API client and scripting language, K9s is a live terminal UI over the same API. Which one to reach for during an incident, in CI, and while learning Kubernetes.

## Kubernetes safety with AI: plan, approve, hard denies, and production discipline

URL: https://kprompt.ai/blog/kubernetes-safety-plan-approve
Published: 2026-07-16

Why natural-language Kubernetes tools need plan-before-apply, risk scoring, and hard denies — with real kprompt examples for scale, rollback, and blocked wipe prompts.

## Choosing an LLM for Kubernetes: BYOK providers, privacy, and what to run in prod

URL: https://kprompt.ai/blog/kubernetes-llm-providers-byok
Published: 2026-07-16

Compare Gemini, OpenAI, Anthropic, Groq, and Ollama for Kubernetes CLI workflows with kprompt — BYOK keys, air-gapped setups, model speed vs explain quality, and security rules for operators.

## Optional Team app

https://app.kprompt.ai — early; CLI stays free; nothing to buy as a public signup product today.