Design Partner programme: the first 100 teams get SreNix free. 100 places left.

See the offer and apply
Product

Detect. Diagnose. Remedy. Verify.

It fixes problems inside the rules you set, records every action, and runs on your own AI model.

How it works

Five steps, re-run every cycle. Closed-loop is the default, not a roadmap milestone.

01

Install

One Helm command, on any Kubernetes 1.27 or newer.

02

Detect

Checks for 21 kinds of Kubernetes problems, plus 10 kinds each for AWS, GCP and Azure.

03

Remediate

Five fixers, each with strict limits. Fixes suggested by AI need a person to approve them.

04

Report

Sends findings to Slack, Alertmanager, Jira and more. You can also read them with kubectl.

05

Verify

Checks again after every fix. No “it probably worked”. It confirms.

Try it offline

Run srenix diagnose --snapshot ./export/ on a saved copy of your cluster state. Nothing to install and no access needed. About 30 seconds.

Run it live

A Helm chart installs a watcher and scheduled checks. It reacts within seconds of a change.

Very small

A 13 MB image that runs without admin rights. It uses under 100m CPU and 100 MB memory, and accepts no inbound traffic.

01 · Detect

It reads your stack, not a copy of it

It runs 21 checks on Kubernetes and 10 groups of checks each on AWS, GCP and Azure. Then 21 analyzers look for drift, log errors and workload problems. This step only reads. It never changes anything.

One failed check does not raise an alert. Only a second failure in a row does. This cuts false alarms.

Diagram: probes → analyzers → findings
Screenshot: root-cause summary on a finding
02 · Diagnose

A hypothesis, checked against evidence

For every critical finding, SreNix looks deeper: DNS, web responses, certificates and recent events. Then it writes a one-line cause.

03 · Remedy

Bounded fixers, never an open shell

Each fixer does one kind of thing, in one place, up to a set limit. If a problem is not on your approved list, SreNix does not guess. It gives a person the full diagnosis and a fix to approve.

See the fix log

fix record · prod-eu-1VERIFIED
10:34:12DETECTCrashLoopBackOff · payments-api · OOMKilled 137
10:34:48CAUSEmemory limit 512Mi vs p99 working set 780Mi
10:35:02POLICYlimit-raise ≤ 2× · namespace payments · auto-approved
10:35:19FIXpatched limits 512Mi → 1Gi, rollout restarted
10:41:30VERIFY0 restarts, error rate 0.02%, 6 min observed
signed by workload identity · srenix-fixer@prod-eu-1
04 · Verify

“Resolved” is a measurement

SreNix runs the same check that found the problem and confirms it is gone. If not, it records the fix as failed. It never assumes a fix worked.

Guardrails & policy

You can read every guardrail

Read all of it before you install anything.

  • Predictable core: no AI model ever touches your cluster
  • More freedom only for fixes that keep working, with a safety switch
  • A signed record you can export with one command
  • No data leaves your network

Guardrail reference

# fixers/k8s-limit-raise.policy.yaml
scope:
  namespaces: [payments, checkout]
  resources: [deployment]
bounds:
  memory_multiplier_max: 2.0
  requires_verification: true
  rollback_on_regression: true
approval:
  in_envelope: auto
  out_of_envelope: signed_url
  signer_roles: [sre-oncall]
identity: oidc://srenix-fixer
Policy flywheel

Lessons are shared. Your data is not.

Each customer’s data stays with that customer. But when the same type of failure keeps appearing, it becomes a new built-in fix. Everyone gets it in the next release.

Diagram: flywheel
Your model, your tenant

Bring your own LLM

AI features are optional. Use OpenAI, Anthropic, or a model you host. AI-suggested fixes need a person’s approval. Automatic approval happens only when every safety check passes.

On-call should be quieter every week

Helm install in 5 minutes. No telemetry exfiltration. No per-investigation surprises.