How Kairos works, and how we roll it out with you

What it is

Kairos is a self-hosted operations platform for Kubernetes and OpenShift estates. It runs on your infrastructure, and its data lands in your PostgreSQL.

One product collects telemetry and inventory from every cluster, raises alerts and graded forecasts, answers questions about the estate with an assistant that cites what it measured, carries approved changes into the cluster, deploys code from Git — and, on OpenShift, provisions new clusters with generated Ansible.

It is built for estates that cannot hand their telemetry to somebody else's cloud: regulated, on-premises or fully disconnected.

How it works

Four parts, and data moves through them in one direction. Nothing reaches into your cluster from outside to collect from it or to change it.

1. Every nodeCollection agentA DaemonSet. Reads the kubelet, the node's log files, events and the API server's inventory, and receives traces over OTLP.
2. Each clusterGatewayPart of the in-cluster install. Acknowledges the agents in milliseconds and forwards on its own schedule, buffering to disk while the platform is unreachable.
3. Your host or clusterThe platformAPI, worker and PostgreSQL. The worker runs every background pass: alerts, forecasts, drift, retention and the AI review loop.
4. One addressTwo consolesThe customer console for your estate, and the operator console for licences and tenants — which sees the fleet in aggregate only.

The platform is one container image running in nine roles, so one tag pins every process to one build. Agents need exactly one address they can reach; people sign in at the same address. When a change is approved, the agent in your cluster claims it from a queue — the platform never connects inward to make it. A bastion host or a monitored VM, if you add one, is reached over SSH.

What it collects

Everything below is read with permissions you can inspect before you apply them. The console shows you the same list the agent's ClusterRole is rendered from.

Metrics

Node, pod and container resource use, read from each kubelet.

Logs

Read from the node's own log files, so applications need no change. Stored partitioned, with retention you set.

Events

Kubernetes events from the API server, kept beyond the hour the cluster itself holds them.

Inventory

More than fifty resource kinds — workloads, networking, storage, RBAC and operators. Each listing reconciles, so a deleted object disappears instead of lingering.

Traces

OTLP from your applications, received by a collector inside the cluster, plus the service mesh's own statistics.

Virtual machines

Hosts outside the cluster and the PostgreSQL databases on them, monitored over SSH with no agent installed.

Never collected: the contents of Secrets, ConfigMap data, and the manifest copies Kubernetes keeps in annotations — removed inside the cluster, before anything is sent.

What you can do with it

Alerts and incidents

Rules and conditions are evaluated continuously and correlated into incidents. A cluster whose agent has stopped reporting is shown as Unknown — never as its last good state, and never alerted on from readings taken before it went quiet.

Forecasts that are graded

Disk, memory and capacity run-outs are forecast from stored history, and every forecast is scored against what actually happened. With the optional forecast service deployed, a trend must also beat a flat line on data it was not fitted to.

An SRE assistant on every page

Ask in plain language. The assistant chooses tools, the platform runs them, and the answer is checked against the evidence before you see it — a citation it invented is dropped, and you can read the measurements it used.

Changes, through a queue you approve

A person or the AI proposes a change; a deny-by-default policy decides whether it may happen; you approve it; the agent in your cluster carries it out and the result is verified and recorded. Undo is itself an approved change.

Alerts where your team already is

Alerts and approval requests go to Slack, Microsoft Teams, Google Chat, email, PagerDuty, a signed webhook or Alertmanager. In Slack, Approve and Reject buttons can be turned on, and each click is checked against Slack's signature and the person's own access. Maintenance windows hold messages during planned work and announce anything still wrong when they end, and a weekly summary says what the product caught and fixed.

Incidents as question and answer

Each incident opens on what happened, why, and how to fix it, with the evidence folded underneath. Run a step in the built-in terminal and press Read the output: the model reads only your own session, says whether it shows the cause and, if not, which read to run next, and every line it quotes is checked against what was printed. Similar past incidents show what was changed then and whether it was verified to work.

Traffic forecast for every service

Every service the mesh has seen gets a forecast of its traffic for the days ahead, from its own history, with nothing to set up. Mark a service as a payment flow and salary days, month-end and tax deadlines are tested against that service's own past and added when they really move it.

Code and deploy

A built-in Git host and reconciler: commit manifests or Helm charts, review them, and sync them to a cluster through the same approval queue. Mirror branches to or from GitHub and GitLab, and let your own CI hand over a commit that passed its tests; the CI waits for the deploy's result and never approves its own change.

Provisioning OpenShift

Describe the cluster you want and, once the request is approved — by an operator, or by your plan's threshold for small ones — the platform generates and runs the Ansible on VMware vSphere. The playbooks you download are the ones that ran; playbooks a model wrote are approved twice.

Your existing tools, both ways

Takes in OTLP, Prometheus remote_write, Loki, Elasticsearch, Splunk HEC, Zipkin and Alertmanager; answers Grafana as a Prometheus, Loki, Jaeger or Tempo data source; and exports to the observability tools you already pay for.

Cost, compliance and hygiene

Rightsizing recommendations priced at your own rates, compliance controls, certificate expiry, backup checks, configuration drift, and analysis of an uploaded OpenShift must-gather archive.

AI, on your terms

Every AI feature is optional, and each one takes its own model.

• Six providers: Ollama on your own hardware, Hugging Face, Anthropic, OpenAI, NVIDIA and Google.
• One model per feature — cluster design, playbook authoring, diagnosis, alerting, monitoring, root cause, runbooks and the SRE assistant — or none at all.
• Sending a feature's data to a hosted provider needs an explicit acknowledgement for that feature, and the database refuses the assignment without it.
• Every citation in the assistant's answer is checked against the tools it ran for your question, under your own permissions — it cannot show you what your role could not open yourself.

Security model

Each of these is something the system makes impossible, not something we intend.

Changes need no credential for your cluster

No kubeconfig, no service-account token, no network path inward to make a change. The agent inside your cluster asks for approved work and carries it out under its own ServiceAccount. The exceptions are ones you add: a bastion host or a monitored VM is reached over SSH with the key you give it.

Collection is read-only, and the platform refuses to start otherwise

A write verb in the collection catalogue stops the platform at start-up — the catalogue that renders the ClusterRole you apply. Write access is opt-in, one operation at a time, and appears in that ClusterRole only when you enable it. One read grant does more than read: get on nodes/proxy, used for kubelet metrics, also reaches the kubelet's exec endpoint on current Kubernetes versions, so treat the agent's token as sensitive.

Secrets are never listed

The Secrets page is derived from what references a secret, never from reading one. ConfigMap data and pasted manifests in annotations are dropped inside the cluster, before anything is sent.

Stored credentials are sealed

Hypervisor accounts, model keys and Git tokens are sealed with AES-256-GCM; reads return a hint and a fingerprint, never the secret. One deliberate exception: a backup destination's access key is written into the storage-location file you download to apply to your cluster.

Automatic destructive changes are impossible to store

Only low-risk changes may ever run without a person. For delete, exec and rollback the database itself refuses an automatic policy; for every other verb the policy code does. Risk is computed from the verb and scope, never taken from whatever proposed the change.

Every control, with the mechanism that enforces it

Installing it

Three topologies. Pick one before you start — they use different manifests, not the same steps in a different order.

What an install inside the cluster looks like

1. Apply the bundle's configuration, storage and secrets from a bastion with oc.
2. The install job creates the schema, the reference data and the first operator account.
3. Start the platform — API, worker, edge and both consoles — behind one address.
4. Sign in, create your tenant with the licence we issued, register the cluster and issue an agent key.
5. Deploy the gateway and the agent DaemonSet with that key.
6. Run the bundled verify script, then lock the install down.

What you need

• A cluster on one of the supported platforms, and a bastion with oc or kubectl.
• Rights to create namespaces and cluster-scoped objects, for the install only.
• Storage for PostgreSQL, in the cluster or on the host beside it.
• One address every agent pod can reach the platform at.
• For a local model, optionally, a machine with a GPU.

Nothing on the platform fetches from the internet: no CDN, no remote fonts, no call home, and Helm charts are rendered offline. Mirror the container images, and the repositories any catalogue add-on installs from, before you start.

Supported platforms

A licence names the platforms it covers, and each cluster declares one when it is registered.

• OpenShift
• Kubernetes
• Rancher / RKE2
• VMware Tanzu
• Mirantis Kubernetes Engine
• k3s
• MicroK8s
• kubeadm
• Minikube
• Kind

Monitoring, alerting, the assistant, changes and code deployment work on all ten. On OpenShift the console also reads Routes, Builds, security context constraints and cluster operators, and provisioning new clusters is OpenShift only.

How we work with you

From the first message to a cluster reporting, and what happens after.

1. Tell us about your estateUse the form at the foot of this page: how many clusters, which platforms, and whether they can reach the internet.
2. A call about what you runWe go through your clusters, which installation topology fits, and which AI providers you want to use — if any.
3. We issue your licenceA licence key naming the platforms it covers, with the install bundle and the guide for your topology. The bundle is dated and carries its own SHA-256 checksums.
4. You install itOn your infrastructure, under your own accounts, following the guide for your topology. Once the agent is deployed, the first inventory, metrics and events arrive within minutes.
5. You decide what it may changeIt starts read-only. Enable write operations one at a time, each behind your approval policy, when you are ready to.
6. Updates arrive as new bundlesOne image tag pins every process to one build, and the schema migrates before the new API starts.

Questions

Does any of our data leave our network?

Not unless you send it. Telemetry lands in your own PostgreSQL. Data goes out only when you set it up: a hosted AI provider assigned to a feature (an explicit acknowledgement for that feature), hosted fine-tuning, an export or alert channel to a tool of yours, or a Git repository you mirror to.

Can it change our cluster without us?

No. Collection is read-only. A change needs the operation enabled on the agent, your cluster's RBAC to permit it, a policy that allows it and — for anything above low risk, which is every change the agent can make — a person's approval. A command an administrator runs themselves in a container or a bastion shell is recorded, not approved.

Do we need a GPU or an AI subscription?

No. Every AI feature is optional and assigned separately. If you want a model, it can run on your own hardware through Ollama, or on a hosted provider you choose.

We already run Prometheus, Grafana and GitHub.

Keep them. Prometheus and others can write into it, Grafana can read from it with no plugin, and GitHub or GitLab branches can be mirrored either way.

What happens when the platform is down?

Agents keep collecting. With the in-cluster install, the gateway in each cluster buffers to disk and forwards when the platform is back, oldest first.

What if an agent stops reporting?

Its cluster shows as Unknown rather than its last good state, and no alert or forecast is raised from readings taken before it went quiet.