Every tool in operations was built for the infrastructure or for the organisation. Not one was built for the person holding the pager.
The operator is the last unserved user in engineering.
Walk a hospital ward at night. The monitor beside each bed serves the patient. The records system serves the hospital: billing, audits, compliance. The night nurse, the one person who holds the whole ward in her head, carries a folded sheet of paper in her pocket. On it: which patient pulls out their line, which pump beeps for no reason, which doctor answers a page after midnight. Nobody designed that sheet. She made it, and it goes home with her when the shift ends.
Operations has been running on the folded sheet for twenty years.
Who are the tools for?
Look at what an on-call engineer has open.
- Datadog and Grafana serve the infrastructure. They show what the systems are doing, priced by host and by metric.
- PagerDuty serves the organisation. Routing, escalation, response time reports for the quarterly review.
- Backstage serves the organisation. A catalog of what exists and who owns it.
- Confluence serves the organisation. A place to store what the company believed at the time somebody wrote it down.
- The incident platform serves the postmortem. A timeline for the meeting afterwards.
All of these are useful. None of them is hers. Each was bought by a company, for the company, and measured at the company level: alert volume, mean time to recovery, coverage. The operator's own workflow, the part between the alert and the fix, was never a line item, so it was never a product.
Why did this happen?
Procurement. Ops tooling is bought by the organisation, and the buyer wants visibility into the estate and an audit trail for compliance. The person on call sits inside that purchase as a cost, not a customer. Her workflow was invisible to the people writing the cheque.
Developers had a different history. The IDE was bought per seat, for one person, to make that one person faster. Then came Copilot, Cursor, Claude Code, Codex. An entire industry grew up serving the individual developer, because that was who was being sold to.
Take an engineer paged for a Redis cluster cascading under load. She has Datadog in one tab, Grafana in another, PagerDuty on her phone, a Confluence runbook that was true two years ago, and a terminal. Which node was flaky last quarter, and the JVM flag someone set on the consumer that makes this worse, live in her head and in a notes file nobody else reads. When the incident closes, the org gets a postmortem. She gets nothing. The next incident starts from her memory again.
What did operators do about it?
They borrowed. First the IDE, used as a comfortable terminal and a place to edit YAML. Then ChatGPT to explain a stack trace. Now Claude Code and Cursor to write Terraform and debug a Helm chart.
These are good tools, built for someone who lives in one repository, editing files that stay still while you look at them. The operator lives across forty repositories, three clusters, a cloud console, a browser full of dashboards, and a shell. She takes a tool shaped for someone else and bends it until it more or less fits.
So ask the question nobody in the tooling market has asked. Not "what does the estate need?" but "what would a tool built for the operator, and only the operator, have to be?"
What would a tool for the person look like?
Start from the person and derive.
- It lives on their machine. The kubeconfig, the cloud credentials, the shell history, the half-finished notes are already there. A tool for the person goes where the person is, not where the org's data lives.
- It carries their memory. Not the org's wiki. The things she learned on Tuesday, available next Tuesday, without a ticket to store them and without anyone else deciding what counts.
- It works across everything they touch. Terminal, browser, editor, every repo, every cluster. One estate, not one file.
- It knows how much to trust itself with. A developer's tool can be bold, because git will undo it. An operator's tool is one command away from taking production down. It has to know what it may do, and it must never decide that for itself.
A tool for the operator is personal, local, wide, and careful. Nothing on the market was all four.
How we built Kepler
We call Kepler the SRE IDE, and the word IDE is deliberate. An IDE is an environment built around one engineer's work. Kepler is that, for the engineer whose work is production. A desktop app on the operator's own machine. macOS, Linux, Windows. Not a cloud service.
The first decision was that it is personal and never multi-tenant. One operator, one machine. A SaaS with team seats would have been easier to sell. We chose not to, because the moment a tool reports to the org, it stops being the operator's. Nothing leaves the machine except through explicit curation.
The second was that memory is local and hers. A memory engine runs on the machine as its own process, built in Rust on SQLite. Every session feeds it: services, hosts, people, conventions, runbooks, what happened last time. There is a memory panel where she can read what the agent believes and correct it. There is also kepler.md, a notes file per workspace that she owns. The agent may append inside one delimited block and never rewrites anything she wrote around it.
The third was that it works where she works. A native terminal and a native browser that she and the agent share. An editor with a file tree. A kepler command in the shell that drives the same local agent.
The fourth is the fence. Posture is set per conversation: Observe, Assist, or Yolo. Beneath posture, per-tool permissions. Beneath those, a floor that no prompt or model output can cross. The agent never widens its own fence.
RubixKube, our enterprise platform, watches the infrastructure with nobody present. Kepler sits with the engineer. Those are the two ends of an incident.
Build for the person in the room
The folded sheet in the nurse's pocket is the most valuable document on the ward, and it is the only one nobody designed. The monitors and the records system would keep running without her. The ward would not.
Operations looks the same. Every dashboard and pager and catalog serves the estate. The person who holds it together has been serving herself with borrowed tools and a notes file. We built Kepler to be the first tool that is hers.
Kepler is in closed beta, opening in waves of about fifty operators. Join the waitlist at trykepler.rubixkube.ai.
Frequently Asked Questions (FAQ)
What is an SRE IDE?
An SRE IDE is a desktop environment built around one operator's work rather than around the infrastructure or the organisation. Where a developer's IDE gathers editor, terminal, and version control around one codebase, an SRE IDE gathers terminal, browser, editor, memory, and an AI agent around one engineer's estate: clusters, repos, dashboards, and runbooks. Kepler is our implementation of the idea.
Why is Kepler a desktop app instead of a cloud service?
Because the operator's credentials, shell history, kubeconfig, and notes already live on their machine, and a tool for the person should live there too. A local app needs no tenant, no sync, and no employer reading over its shoulder. Kepler's memory engine, model keys, and agent server all run locally, and nothing leaves the machine except through explicit curation by the operator.
How is Kepler different from Claude Code or Cursor for operations work?
Claude Code and Cursor are built for one repository and one session, which is what a developer needs. An operator works across many repositories, clusters, and dashboards, and needs knowledge that carries from one incident to the next. Kepler accumulates memory across sessions, shares a terminal and browser with the operator, and enforces its trust model in host code rather than in the prompt.
