Srenix – self-healing Kubernetes in a 30MB binary (Apache-2.0)

Your cluster breaks at 3 AM. Srenix finds the fault, applies a policy-bounded fix, re-verifies, and posts one report to Slack — no dashboard, no pager, no 30 MB of YAML archaeology.

One ~30 MB Go binary on a distroless base. 16 Kubernetes probes · 14 read-only analyzers · 30 cloud probes (AWS / GCP / Azure) · 5 auto-fixers — every fix policy-bounded, GitOps-aware, and re-verified after it runs. Apache-2.0.

git clone https://github.com/srenix-ai/agentic-sre.git
cd agentic-sre
go run ./cmd/srenix diagnose --snapshot examples/sample-cluster
• Ceph Storage:     🟢 HEALTHY    1 cluster(s): rook-ceph@rook-ceph OK (11.5% used)
• Cluster Nodes:    🟢 HEALTHY    All 4 nodes ready
• PostgreSQL:       🟢 HEALTHY    1 CNPG cluster(s): main@data (3/3 ready, primary=main-1)
• Storage Claims:   🟢 HEALTHY    All 3 PVCs bound

Diagnostics (3):
  🔎 Secret `billing/billing-svc-secrets` missing key `STRIPE_API_KEY` (referenced by
     Deployment/billing-svc in ns billing). Owning ExternalSecret: `billing/billing-svc-secrets`
     — add data/template entry exposing `STRIPE_API_KEY`, or remove the env reference if unused.
  🔎 ExternalSecret `billing/billing-svc-secrets` not Ready: error processing spec.data[0]
     (key: shared/billing/config), err: cannot find secret data for key: "stripe_api_key".
  🔎 ExternalSecret `billing/old-payment-gateway` not Ready: error processing spec.data[0]
     (key: shared/legacy/payments), err: vault path not found.

That's the headline: a precise diagnosis — which Secret, which key, which Deployment, which Vault path — from a read-only snapshot, on your laptop.

Then run it against your own cluster:

srenix snapshot capture --out ./my-cluster   # read-only; never modifies state
srenix diagnose --snapshot ./my-cluster      # diagnose offline
srenix diagnose --live                       # or straight against the live cluster
php
flowchart LR
    A[🔍 Detect<br/>16 K8s probes<br/>30 cloud probes] --> B[🧠 Diagnose<br/>14 analyzers<br/>root cause + hint]
    B --> C{Recognized &<br/>policy-allowed?}
    C -->|yes| D[🔧 Remediate<br/>5 policy-bounded fixers<br/>GitOps-aware]
    C -->|no| E[📋 Precise remediation<br/>hint for a human]
    D --> F[✅ Re-verify<br/>probe again,<br/>prove the fix]
    F --> G[📣 Report<br/>Slack / Alertmanager /<br/>OpenProject ticket]
    E --> G

Two ways to run it:

Zero-trust offline mode— point it at a capturedkubectl get … -o json

snapshot. No install, no RBAC, no write permissions.In-cluster live mode— Helm-installed CronJob with two narrowly-scoped ClusterRoles (read-only + tightly-bounded write); posts to Slack on a schedule. Optional operator (AgenticSRE

CRD) manages the whole deployment.

helm repo add srenix https://srenix-ai.github.io/agentic-sre
helm repo update
helm install srenix srenix/agentic-sre \
  --namespace agentic-sre --create-namespace \
  --set slackWebhookSecretName=srenix-slack-webhook

Most "auto-remediation" tools ask you to trust an LLM with kubectl. Srenix doesn't:

The hot path is LLM-free and deterministic. Detection, diagnosis, and fixing are pure Go — same input, same output, every time.Fixers only touch a closed catalog of known-safe patterns(stale Error pods, stuck Jobs on renamed Secret keys, stale-revision RS pods, terminal CertificateRequests, TLS secret mismatch).Never auto-applied: edits to Secrets, ConfigMaps, or generic CRDs.GitOps-aware: fixers skip anything managed by Argo/Flux/Helm rather than fight a reconcile loop; d/suspended workloads are respected.Every fix is re-verified by re-running the probe, and reported either way.Narrow RBAC by construction: two ClusterRoles you can read in one sitting; the container is distroless (nonroot

, no shell, no package manager).

Full catalog — every probe, analyzer, and fixer with symptom, root cause, and why the fix is safe: ** docs/FAILURE_MODES.md**.

Current version and the full shipped/planned matrix: ** STATUS.md** · What's next:

ROADMAP.mdEverything above is Apache-2.0 and works standalone — probes, analyzers, fixers, cloud probes, deterministic investigator, Helm chart, operator.

Srenix Enterprise (commercial binary) adds the AI layer on the same safety contract: an LLM-backed Investigator, T0 narration → T1 fix proposals → T2 multi-step planning → T3 dual-approval break-glass runbooks — every action policy-bounded, Ed25519-signed, hash-chain audited — plus a curated Verified Signature Library regression-tested monthly. Details: docs/SRENIX_OVERVIEW.md · Contact: srenix.ai/contact or info@srenix.ai.

FAILURE_MODES.md— full fix catalogSETUP_GUIDE.md— install, Helm values, RBACAI_TIERS.md— Layer-2 + T0–T3 specDEMO_GUIDE.md— storyboarded failure scenariosDASHBOARDS.md— 6 Grafana dashboardsAI_USAGE.md— why the hot path is LLM-freeSrenix came out of the same on-call loop I kept living: a 3 AM page, twenty minutes of kubectl

archaeology, and a root cause that was almost always mundane — a stale Secret key, a stuck ExternalSecret, a cert that didn't renew. I wanted something that did that triage for me deterministically — with a fix catalog narrow enough that I'd actually trust it to run unattended — and posted one honest report instead of paging a human. That's Srenix. If it catches something for you, I'd genuinely like to hear about it in Discussions.

— Salil, maintainer

Questions, war stories, and "it flagged something weird" reports: ** GitHub Discussions**. Bugs and feature requests:

Issues. If Srenix saved you a page, a ⭐ helps other on-call engineers find it.

Apache License 2.0 for the engine and default signature library. The Verified Signature Library ships separately under a commercial license. To report a vulnerability: ** security@srenix.ai** (

SECURITY.md).