Quickstart
⚠️ Not yet a stranger-facing quickstart. The container images are in a private registry until the owner makes them public, so the
helm installbelow cannot pull for anyone outside the project. This page is written and kept accurate so that flipping image visibility is the only remaining step — not so that it can be followed today.
What you need
Keryx investigates a cluster you already run. It does not ship one.
- A Kubernetes cluster with Prometheus and Loki reachable in-cluster.
- Alertmanager, so there is something to trigger an investigation.
- An LLM provider key — Keryx is bring-your-own-key and the key never leaves your cluster. A local model works and means zero egress.
- Optionally Flux, which is what deploy correlation reads.
This is the realistic path: point Keryx at your own observability stack. A self-contained demo cluster needs the whole LGTM stack alongside it and is a much larger ask; it is deferred rather than pretended.
Install
helm install keryx oci://ghcr.io/keryx-hq/charts/keryx \
--namespace keryx --create-namespace \
--set model.provider=bedrock \
--set-string rbac.namespaces="{monitoring,flux-system,your-app-ns}" \
--set existingSecret=keryx-model-key
The chart's own resource requests total 400m CPU / 768Mi — Keryx itself is small. The heavy part of any demo is the observability stack, which you already have.
Point Alertmanager at it
receivers:
- name: keryx
webhook_configs:
- url: http://keryx.keryx.svc:8080/webhooks/alertmanager
send_resolved: false
Check it
keryx doctor
doctor is the first response to every support issue: it checks API
reachability, whether migrations are current, whether each MCP server
answers, that the RBAC verbs really do resolve as read-only, and that the
model provider key is valid.
Then break something on purpose and watch the thread.
The gate we hold ourselves to
helm install to first investigation in under 15 minutes. That is a
launch gate, not a marketing claim, and it is not met for a stranger until
the images are public.