Branded answers
How Srenix works: the whole loop, in plain words.
Srenix is an autonomous AI SRE that runs inside your Kubernetes cluster. This page is the loop, step by step — what goes in, what it checks, what it is allowed to change, and what evidence it leaves behind.
-
01
Install
One Helm chart. It runs in your cluster, in your network. You point it at any OpenAI-compatible model endpoint you choose — including an in-cluster vLLM or Azure OpenAI. Nothing is sent to a vendor SaaS. Runs on Kubernetes 1.27+ on EKS, GKE, AKS, k3s, RKE2 and OpenShift.
-
02
Detect
Srenix watches for problems through 21 Kubernetes probes, plus 10 probes each for AWS, GCP and Azure. It is triggered three ways: resource events in the cluster, Prometheus alerts via Alertmanager, and HMAC webhooks. Typical incidents: expired certificates, crash loops, bad deploys, missing secrets, stuck jobs, full disks.
-
03
Diagnose
21 analyzers (drift, logs, workload, diagnostics) turn the signals into a cause, not just an alarm. Findings are also Kubernetes resources — you can see them with
kubectl get driftreports. -
04
Fix, inside your rules
- Five policy-bounded fixers by default. A fix can only do what its policy allows.
- An AI-proposed fix needs a human click on a signed, single-use link before it runs — unless every gate passes at confidence of at least 0.95 and you switched auto-merge on. Auto-merge is off by default. In plain words: the human click is the rule, and the automatic route only exists if you turn it on and every check passes with high confidence.
- Seven checks run in a fixed order before any change is made.
-
05
Report
Findings and actions reach the tools the team already works in: Slack, Alertmanager and OpenProject, with Jira and ServiceNow on Enterprise.
-
06
Verify
After every fix, Srenix re-diagnoses. Did the problem actually go away? A fix that is later reverted counts as a failure — the loop keeps watching instead of declaring victory. What the re-check looks at is on the verify page.
The record
What it leaves behind.
Every step — detection, diagnosis, proposal, approval, change, verification — is written to a signed, hash-chained audit trail. Customers can review the source of the safety envelope. Enterprise lists SBOM and signed images, an air-gapped installer, and a SOC 2-friendly audit bundle export (a feature, not a certification). The full audit trail, in more detail, is on the audit trail page.
First step
Try the first step without installing anything.
srenix diagnose --snapshot <dir> diagnoses a read-only snapshot — no install, no RBAC, no changes to your cluster. It is the honest way to see how the reasoning works on your own data.
srenix diagnose --snapshot /path/to/your/snapshotThe full snapshot guide, with what the output means, is on the snapshot guide.
The stage
Where Srenix is honest about being early.
- Beta, pilots in progress.
- No certifications.
- No named customers until each one agrees in writing.
- The patent is pending, not granted.
Does my data leave the cluster?
No. Srenix runs in your network; no telemetry leaves your cluster. You choose the model endpoint, including fully in-cluster.
Can Srenix change my production cluster without asking?
By default, no. AI-proposed fixes need a human click on a signed, single-use link. Automatic merging exists but is off by default and only fires when every gate passes at confidence ≥ 0.95.
Which models does it use?
Any OpenAI-compatible endpoint you choose — cloud or in-cluster vLLM or Azure OpenAI.
What happens if a fix is wrong?
Seven checks run before any change, in a fixed order, and Srenix re-diagnoses after it. A fix that is later reverted counts as a failure, so the loop keeps watching.
Run the loop on your own cluster.
Free now for early adopters: be a Design Partner and shape the product with the team that runs it. Or take the loop on your own data first — no install.
Or start from a read-only snapshot — no install, no RBAC: srenix diagnose --snapshot <dir>.