Is KubeIntellect production-ready? Would you run it on your own production cluster?

[MSKazemi]

Evaluating this for a team of eight running production Kubernetes. The README is refreshingly honest about limitations, which makes me more inclined to trust it, not less — so I'd like the same honesty here.

Is this production-ready? Specifically:

• Would you run it against a production cluster yourself?
• What is the realistic failure mode I should be worried about?
• Is anyone actually running it in production today?

[MSKazemi]

Short version: use it as a diagnostic assistant on production, yes. Do not put it in the remediation path on production, and do not treat it as a dependency you page on. The distinction matters more than a yes/no.

What is genuinely solid

• The safety model is the most mature part, because it was the design premise rather than a feature added later. Every mutating action passes a server-side chokepoint requiring explicit human approval, RBAC applies underneath it, and Secrets/ServiceAccounts are unreadable by any role including superadmin. Details in #81.
• Autonomy is capped at A1 by default — it investigates and reports, never mutates. Auto-fix (A3) requires two deliberate configuration acts naming the exact playbook and namespace, and ships with an empty allowlist.
• The flight recorder is hash-chained and kq replay <session-id> exits non-zero on a broken chain — so "what did it actually do" is answerable after the fact, which is the thing you need when explaining an incident to someone else.
• It is peer-reviewed — Journal of Grid Computing, 2026. Note carefully what that means: the architecture and evaluation were reviewed. It is not an operational-maturity certificate.
• CI requires nine checks including both test suites on Python 3.12 and 3.13, types at zero errors, and a syntax-warning gate.

What should stop you

• One maintainer. This is the single most important fact on this page, and no amount of test coverage compensates for it. GOVERNANCE.md has a real succession policy — which exists precisely because the risk is real, not because it is solved.
• Young project, changing APIs. v1/–v4/ changed between generations. v4/ is the supported line; the older ones are frozen for paper reproducibility and must not be deployed.
• LLM answers can be wrong. The approval gate is the mitigation, not a fix. A confident, wrong root-cause analysis at 3am is a real failure mode and no gate prevents you from believing it.
• Cluster context leaves your network unless you point it at a self-hosted endpoint — and that path is not yet tested or supported (#17, discussion #83).
• No adopters listed yet. ADOPTERS.md is honestly empty rather than padded. Nobody has publicly said they run this in production, and you should weigh that.
• Queries cost tokens, and there is no published per-query cost figure — the evaluation harness never captured token counts (a misconfigured tracing key), so the cost columns in the paper are empty. That is a gap in our measurement, not a small number being hidden. Budget empirically on a non-production cluster first.

A staged adoption that matches the actual risk

1. Browser demo — kubeintellect.com/demo, read-only, shared cluster. Zero commitment.
2. readonly key against a staging cluster. Full diagnostic value; mutation is structurally impossible, not merely gated.
3. readonly against production. This is where most teams should stop for now, and it is genuinely useful there — the correlation across kubectl + Prometheus + Loki is the part that saves time.
4. operator in one non-production namespace, autonomy at A1, empty A3 allowlist. Read the digest for a few weeks.
5. Anything beyond that is ahead of where the project's operational track record is.

The honest summary

"Production-ready" usually means someone else has already been burned so you won't be. That has not happened here yet — which is exactly why ADOPTERS.md and #51 exist. Listed environments are the ones that get protected, tested, and kept backward-compatible.

If you evaluate it and decide against, saying why on #52 is more useful to this project than a star. "We'd run it if X" comes with the reason attached, which is the part roadmaps usually get wrong.