Back home

How it works

How ifa works.

A read-only pipeline that reads what your cluster already exposes and reports which of 19 rules fired, with evidence — or reports nothing measured.

Current status

The vLLM and Triton adapters are both validated against live CPU-backed deployments, and the full Kubernetes path is validated end to end in CI against a real cluster. The next milestone is GPU-backed validation for either runtime — currently unvalidated.

The pipeline

1

Discover

An informer-based Kubernetes watcher finds inference workloads by runtime label and reads model identity from an annotation.

2

Scrape

In-cluster Service networking reaches each workload's Prometheus endpoint over a plain GET — no request-path insertion.

3

Parse

Runtime-specific adapters parse the exposition format for vLLM, Triton, or DCGM Exporter into typed metrics.

4

Store

Parsed telemetry is written to TimescaleDB, or an in-memory store when no database is configured.

5

Evaluate

19 rules across 7 families are evaluated on a sustain window against shipped-default thresholds, with suppression between related rules.

6

Serve

Findings are served over a REST API and the ifa CLI, each with the metric, observed value, threshold, and comparison attached.

Stack facts

Runtimes supported
vLLM, Triton, DCGM Exporter
Rule families
7 (19 rules total)
Cluster tested
kind, Kubernetes 1.31
vLLM version validated
0.28.0, CPU backend
Triton version validated
25.12, CPU backend

Action model

ifa never mutates your cluster. It holds only the read verbs listed on the security page. Findings are surfaced through the API and CLI; a human decides what, if anything, to change.

Repository structure

Control plane
Kubernetes watcher (informer-based)
vLLM adapter
Triton adapter
DCGM adapter
Rule engine (19 rules, 7 families)
TimescaleDB store
In-memory fallback store
ifa CLI
Helm chart
NetworkPolicy template
Docker packaging
Air-gapped packaging scripts

Air-gapped operation

There is no "air-gapped mode" flag. Air-gapped operation is a property of the deployment — no egress, mirrored images, a NetworkPolicy — not a runtime setting. A configuration field that claimed to enforce it while enforcing nothing would be security theatre.

ifa makes no outbound connections of its own: no licence check, no usage telemetry, no update check, no crash reporting. The only things that need to cross the boundary are the container image and the Helm chart. scripts/package-offline.sh mirrors both for transfer, and docs/DEPLOYMENT.md documents the full procedure.

Want to evaluate it on your stack?

The alpha is solo-built and read-only. I'm onboarding a small number of teams running real vLLM or Triton workloads.

Read the design-partner page