Your agent writes the change.
krnali checks whether production should accept it.
Read-only Kubernetes readiness for teams with no SRE. krnali runs inside your cluster, learns what normal looks like, and files what is going wrong with the evidence attached. Nothing leaves the boundary.
read-only · in-cluster · no data egress · installs in minutes
You ship faster than you can review.
Your cluster tells you what broke, after it broke.
An SRE hire is six months away and costs more than your infrastructure.
krnali is the layer in between. It watches the cluster you do not have time to watch.
Three products. One of them ships today.
We would rather tell you which is which than let you find out after you install.
krnali Ops
available nowkrnali Ops runs read-only inside your cluster. It detects the failures that actually page you: crashloops, image and config failures, HPA saturation, node pressure, rollout regressions. It samples memory and quota usage to learn your normal, then flags the limits and headroom you are about to run out of.
Every finding arrives with its evidence chain: the signals observed, how far they deviated, what the system concluded, how confident it is, and whether the fix is reversible. Findings deduplicate, track recurrence, and file into Jira.
- Reactive detection across five failure classes
- Memory and quota baselining, restart safe
- Deterministic prediction on limits and headroom
- Ordered evidence chain on every finding
- Reversibility classification and confidence scoring
- Recurrence tracking and deduplication
- Jira filing
- Cloud neutral Helm chart
krnali Build
in developmentOps tells you what your cluster is doing. Build tells you what your cluster is supposed to be. It discovers what you already run, qualifies it against your standards and your application's requirements, generates governed change plans, verifies what actually deployed, and maintains a living as-built of your environment.
Specified and designed. No code yet. Founding cohort members shape it.
krnali Reasoning
in developmentThe engine both products share. It turns evidence into an explanation without ever authoring a number, and it runs where your cluster runs. Bring your own model endpoint, or run a small model locally. Nothing about your infrastructure leaves your infrastructure to get an answer.
The deterministic half ships inside Ops today. The local inference half is being built.
One finding, exactly as krnali filed it
Captured from a live cluster. Not a mock, and not rewritten for the page.
Loading the finding…
Every number on this card is computed. The model never writes a figure, a threshold or a measurement. It writes the explanation.
How it works
- Install. One Helm chart. Read-only service account. krnali proves its own permissions on startup and shows you the denials.
- Observe. It watches workloads, events, resources and rollouts. It writes nothing to your cluster, ever.
- Learn. It samples usage to build a baseline of your normal, and survives restarts without losing it.
- File. Findings land where you already work, with the evidence attached and the reasoning traceable.
Boundaries
Read-only, and it proves it
krnali requests a read-only RBAC role and verifies its own permissions live at startup. pods/exec is denied. The portal writes nothing. nali verify-rbac prints the proof for your own audit.
In your boundary
krnali runs in your cluster. There is no krnali cloud in the data path. Bring your own model endpoint, or run a small model locally. Nothing about your infrastructure leaves your infrastructure.
Default deny
The portal ships with a default-deny NetworkPolicy, a request body cap, an SSRF fence and an auth gate. Guardrails ship with negative controls that fail the build if the guardrail stops working.
Most tools are confident about everything. krnali has a vocabulary for not knowing.
When a signal source is unavailable, krnali says the source is absent. When a probe fails, it says the probe failed. When the evidence does not support a conclusion, it says the evidence is insufficient and stops.
Confidence never becomes authority. krnali proposes. You decide.
Who it is for
Built for
- Teams of 2 to 30 engineers
- One to five clusters you manage yourself
- Shipping weekly or faster, often with a coding agent
- Nobody whose job title contains "reliability"
Not built for
- Multi hundred cluster fleets
- Teams who already run a platform organisation
- Anyone looking to replace their observability stack
Installing
Installation is one chart and a read-only service account. The free nali CLI runs a one-off cluster check with no signup and no retained history.
Both land with the founding cohort. There is no copyable command here yet because the chart and images are not published, and we would rather show you nothing than something that does not run.
Twenty teams. Then we open it up.
Founding cohort members get Complete free for a year, direct access to the people building it, and real influence over what Build becomes. In exchange we want your cluster's honest opinion and thirty minutes a fortnight.
Questions
Does krnali send my cluster data anywhere?
No. It runs in your cluster, and there is no krnali cloud in the data path.
What access does it need?
A read-only service account. It verifies and displays its own permissions at startup, and pods/exec is denied.
Do I need to supply a model?
Either bring your own endpoint, or run a small model locally in the cluster.
Which clouds does it work with?
The chart is cloud neutral. Any conformant Kubernetes cluster.
What is the difference between Ops and Build?
Ops watches what is running. Build governs what is about to change.
Where does the name come from?
The Karnali, one of four rivers flowing from Mount Kailash. Pronounced kar nah lee. The CLI is nali.