Srenix — self-healing for Kubernetes

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. Source-available and free for non-commercial use. Patent pending.

Try it in 30 seconds (no cluster, no install, no RBAC)

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

How it works

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 captured kubectl 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

Why it's safe to let it fix things

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; paused/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.

What's in the box

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

Community vs Enterprise

Everything above is source-available, free for non-commercial use, and works standalone — probes, analyzers, fixers, cloud probes, deterministic investigator, Helm chart, operator. Running it against clusters that serve your business is commercial use and needs a paid licence.

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 [email protected].

Docs

Why I built this

Srenix 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

Community

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.

License & security

Srenix is source-available, not open source. The engine and default signature library are licensed under PolyForm Noncommercial 1.0.0 — free to read, modify and run for any non-commercial purpose; commercial use requires a paid licence ([email protected]). The Verified Signature Library ships separately under a commercial license.

Srenix is patent pending — see NOTICE.

To report a vulnerability: [email protected] (SECURITY.md).

Which versions are Apache-2.0?

Srenix changed licence in August 2026. The boundary is exact:

That covers every v1.x tag through v1.26.3, the v0.1.0-alpha.1 re-baseline, and all nine v0.2.0-alpha.* tags.

If you already have an Apache-2.0 version, you keep it. A copyright licence, once granted to a recipient, is not revocable by the licensor changing terms later. Those releases remain Apache-2.0 for everyone who received them — including the patent grant in Apache-2.0 §3 — and they remain fetchable from the Go module proxy, which mirrors public modules permanently:

# still works, still Apache-2.0, indefinitely
GOPROXY=proxy.golang.org go mod download github.com/srenix-ai/[email protected]

Nothing in the relicence attempts to revoke that, and nobody needs to uninstall anything.

What the new licence does cover is everything from the next release onward: new probes, analyzers, fixers, cloud coverage, and every fix and improvement after v0.2.0-alpha.9. If you want those, and you're using Srenix commercially, you need a paid licence — contact [email protected].

Note that the patent-pending status (see NOTICE) attaches to the architecture, not to a particular copy of the source. Holding an Apache-2.0 copy is not, by itself, a defence to a patent claim over reimplementing the covered design in a competing product — though Apache-2.0 §3 does grant its recipients a patent licence for the versions they received.