Disclosure: I'm one of the builders of Keel (Infranexis), a commercial product. This is an engineering write-up of a design decision, not a sales post — read it with that bias in mind, and poke holes in the comments. There's a public, no-signup demo link at the bottom if you'd rather just click around.
Every log analytics vendor now has an AI assistant. Nearly all of them work the same way: your query — and often your log data — leaves your network, transits the vendor's cloud, hits a model API, and the answer comes back.
If you run infrastructure in a bank, a hospital, a defense contractor, or a government network, that architecture is a non-starter. It doesn't matter how good the assistant is; the data can't leave. The teams with the strictest compliance requirements — arguably the teams that need investigation help the most, because their on-call rotations are stretched thin — are exactly the ones locked out of the AI feature wave.
We built Keel on a different premise: the model comes to the data, not the other way around.
The constraint that shaped everything
Keel is a log analytics appliance — a self-contained VM image (OVA, VHDX, QCOW2) that runs entirely inside your network on vSphere, Hyper-V, or KVM/Proxmox — and the same QCOW2 image boots on OpenStack (Glance/Nova) and OpenShift Virtualization (KubeVirt), which is where a lot of sovereign and regulated private clouds actually live. It ingests via OpenTelemetry (OTLP gRPC 4317 / HTTP 4318), syslog (514), and Fluentd (24224). It has to work on a network with no internet route at all, because for a meaningful share of our customers that's not a preference — it's policy.
Air-gap seeps into every design decision, including ones that have nothing to do with AI. Licenses are signed with RS256 and verified offline against a published public key, so an isolated node can validate its entitlements without ever calling home. Updates ship as signed bundles the appliance verifies before applying. In connected mode the appliance's entire outbound surface is one narrow path to the license portal — and in air-gapped mode, zero.
That constraint rules out every convenient way to add AI features. No hosted model APIs, obviously. No "hybrid" mode where anonymized queries go out — anonymizing log data is a research problem, not a checkbox. And no baking fixed model weights into the appliance, because then customers are stuck with our choice forever.
What we settled on: Keel orchestrates, you own the inference. Under Settings → AI Configuration you point the appliance at whatever backend your security posture allows: an Ollama instance on your network for fully air-gapped operation, or — if your policies permit hosted models — your own Anthropic or OpenAI key, or any OpenAI-compatible endpoint (vLLM included). You can configure a primary and a secondary backend with a timeout, so if the primary is unreachable the appliance fails over automatically. When a better open-weights model ships next quarter, you swap the endpoint. No appliance update needed.
What the AI actually does
Three capabilities, all running against your chosen endpoint:
1. Natural-language search. You ask "failed logins from the VPN gateway in the last six hours" and Keel translates it into a structured query against the log store, shows you the query it generated, and runs it. The translation is the LLM's job; the execution belongs to the query engine — a column-oriented store (ClickHouse) with hot local disk and an optional S3-compatible cold tier that stays queryable. The model proposes, the engine disposes, and you can always see and edit what it proposed.
2. Automatic root cause analysis. When an alert arrives — from Alertmanager, PagerDuty, Datadog, or a webhook — Keel opens an incident and investigates before a human picks it up:
alert sources alert pipeline incident AI RCA notification channels
─────────────── ──► ────────────► ──► ───────── ──► ─────────── ──► ─────────────────────
Alertmanager / LLM + RAG + Slack / Teams / email /
Datadog / correlated PagerDuty / webhook
PagerDuty / logs
webhook
The RCA isn't a model free-associating over raw text. The investigation is grounded two ways: the logs correlated around the alert window, and a retrieval layer — a vector index (Qdrant) over the runbooks and documentation you've uploaded to the appliance's knowledge base. The model reasons over what your logs show and what your own docs say the system is supposed to do, and delivers a plain-English finding to Slack, Teams, PagerDuty, or email.
3. The Platform Assistant. A chat interface that answers questions about your own platform — and can use tools: search logs, check disk usage, look up incidents. Which brings us to the part we consider the most important design decision in the product.
What the AI deliberately can't do
The assistant is read-only by construction. It has no tools that change or delete anything — not configuration, not data, not pipelines. This isn't a policy filter asking the model to behave; the mutating tools simply don't exist in its toolbox.
This matters for a reason that goes beyond caution: prompt injection through your own logs. A log analytics AI reads whatever your infrastructure ingests — and an attacker can often control what gets logged (a User-Agent string, a crafted username, a request path). If a hostile string in a log line ever tricked the model, the blast radius must be a wrong answer, not a changed system. Capability-level read-only means the worst case is bad prose. Humans keep the pager and the keyboard.
The same philosophy applies to failure: if your LLM endpoint is down or you never configure one, Keel degrades to a complete, conventional log platform — ingest, pipelines, search, dashboards, alerting, incident tracking, all fully functional. AI is a layer, not a dependency.
The unglamorous parts
The hard engineering wasn't the prompts. It was making all of this operable by a team that does not want to become a log-platform team: one VM image containing the collectors, the application engine, ClickHouse, the configuration store, the vector index, TLS termination, and a failover manager — with a guided setup wizard in front and a 3-node HA cluster mode (floating VIP, replicated stores, automatic promotion of a healthy node) when you need it. The appliance discipline is the actual product. The model is a guest.
Why an appliance, in 2026?
Because the alternative for these teams is grim: keep paying per-GB SaaS prices for a platform their auditors are increasingly unhappy about, or run a self-managed ELK cluster that eats 10–20 engineer-hours a month and will never answer a question in English.
Flat pricing falls out of the architecture almost by accident: since the appliance runs on your hardware and your disk, we don't meter your gigabytes. The license is a flat annual fee banded by ingest volume ($6K/yr up to 5 GB/day, $14.8K up to 50 GB/day), every feature at every tier, and retention is bounded by the storage you attach — which your compliance team will appreciate more than we can.
Try it / tear it apart
If you'd rather click around than take my word for it, there's a public live demo —
no signup, opens in your browser:
demo-box.keel.infranexis.com .
Architecture docs, the security overview, and honest comparisons against Splunk and self-managed ELK — including the parts where they're still ahead of us — are at keel.infranexis.com.
If you run logs in a network where the data can't leave, I'd genuinely like your critique in the comments — especially from folks who've had to solve this the hard way.
Top comments (0)