2026-07-22 15:13 UTCIn-site rewrite4 min readUpdated: 2026-10-02 02:36 UTC

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

Summary

Srenix is an open-source Kubernetes self-healing tool packaged as a ~30MB Go binary. It automatically detects, diagnoses, and fixes cluster issues without relying on LLMs, using deterministic logic. It features 16 K8s probes, 14 read-only analyzers, 30 cloud probes (AWS/GCP/Azure), and 5 policy-bounded fixers that re-verify after execution. Supports offline snapshot mode and in-cluster live mode, GitOps-aware, and integrates with Slack, Alertmanager, and more. Designed to reduce on-call toil.

SourceHacker News AIAuthor: srenix-ai

Report an error

The correction channel is not available yet. You can copy the article reference below for later.

Correction instructions

Read article

Uh oh!

There was an error while loading. Please reload this page.

Notifications You must be signed in to change notification settings

Fork 0

Star 3

BranchesTags

Open more actions menu

Folders and files

NameName

Last commit message

Last commit date

Latest commit

History

224 Commits

.github

api/v1alpha1

bundle

catalog

charts/agentic-sre

cmd

demo

docs

examples

internal

pkg

runs

scripts

tools/promqllint

.dockerignore

.gitignore

.golangci.yml

.goreleaser.yaml

.mcp.json

CHANGELOG.md

CONTRIBUTING.md

Dockerfile

LICENSE

LICENSE-VERIFIED-LIBRARY.md

Makefile

README.md

RELEASING.md

ROADMAP.md

SECURITY.md

STATUS.md

bundle.Dockerfile

go.mod

go.sum

Repository files navigation

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.

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 16 K8s probes 30 cloud probes] --> B[🧠 Diagnose 14 analyzers root cause + hint] B --> C{Recognized & policy-allowed?} C -->|yes| D[🔧 Remediate 5 policy-bounded fixers GitOps-aware] C -->|no| E[📋 Precise remediation hint for a human] D --> F[✅ Re-verify probe again, prove the fix] F --> G[📣 Report Slack / Alertmanager / 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

Layer Coverage

K8s probes (16) Ceph, PostgreSQL (CNPG + Zalando), critical workloads, nodes, PVCs, external endpoints, node pressure, system DaemonSets, pending pods, CrashLoopBackOff, etcd, failed mounts, Kong, HPA, ArgoCD sync, Velero backups

Analyzers (14) Secret/key/ExternalSecret/image-pull/cert/TLS classes + drift: GitOps, workload-state, RBAC, config, capacity, security

Cloud probes (30) 10 each for AWS / GCP / Azure — RDS, EBS, EKS, IAM, ALB, ACM, KMS, S3, VPC and equivalents. Off by default, opt-in per provider, per-probe toggles

Fixers (5) Policy-bounded, GitOps-aware, re-verified. Opt-in for anything that mutates routing

Investigator On CRITICAL findings, a read-only Layer-2 deep-dive (DNS, HTTP, TLS, describe, events) attaches a one-line root cause to the alert

Sinks Slack (3-channel routing, per-severity repeat intervals), Alertmanager, OpenProject tickets via MCP, 6 Grafana dashboards

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

OSS vs Enterprise

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

Docs

Start here Deep dives

SRENIX_OVERVIEW.md — the two-pager FAILURE_MODES.md — full fix catalog

SETUP_GUIDE.md — install, Helm values, RBAC AI_TIERS.md — Layer-2 + T0–T3 spec

DEMO_GUIDE.md — storyboarded failure scenarios DASHBOARDS.md — 6 Grafana dashboards

AI_USAGE.md — why the hot path is LLM-free

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

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: [email protected] (SECURITY.md).

About

Self-healing layer for Kubernetes in a 30 MB binary — detect, fix, re-verify, report. Apache-2.0.

srenix.ai

Topics

kubernetes

golang

devops

mcp

incident-response

site-reliability-engineering

k8s

cloud-native

sre

observability

self-healing

auto-remediation

aiops

gitops

llm

Resources

Readme

License

Apache-2.0, Unknown licenses found

Apache-2.0

LICENSE

Unknown

LICENSE-VERIFIED-LIBRARY.md

Contributing

Security policy

Uh oh!

There was an error while loading. Please reload this page.

Activity

Custom properties

Stars

3 stars

Watchers

0 watching

Forks

0 forks

Report repository

Releases 138

agentic-sre-0.1.0-alpha.1

Latest

Jun 26, 2026

+ 137 releases

Packages 0

Uh oh!

There was an error while loading. Please reload this page.

Contributors

Uh oh!

There was an error while loading. Please reload this page.

Languages

Go 97.8%

Shell 1.2%

Other 1.0%

Key points and analysis

Article intelligence

EngineersAdvanced

Key points

Srenix is a ~30MB Go binary that provides self-healing Kubernetes capabilities, licensed under Apache-2.0
Includes 16 K8s probes, 14 analyzers, 30 cloud probes, and 5 policy-bounded fixers
Operates without LLMs, using deterministic detection and remediation for safety and predictability
Supports offline snapshots and live cluster operation, with re-verification and reporting to Slack, etc.

Highlights and analysis are generated automatically and may contain errors. Check the original source.

Article intelligence

Key points

More recent stories on this topic · Models