Skip to main content
This walkthrough takes a fresh Kepler from sign-in to a small, reviewed change against a real cluster. Every step is safe to do against production: nothing writes until step 6, and even then you approve each command. If you have not installed Kepler yet, start with Installation. Shortcuts below use Cmd. On Windows and Linux, use Ctrl.
1

Sign in

Launch Kepler and click Sign in to Kepler. Your browser opens. Continue with Google, GitHub, or email, then return to the app. It picks up the session on its own.
Kepler sign-in screen. The left side reads Find calm in the chaos. The right side has a Sign in to Kepler button and a note that you can continue with Google, GitHub, or email.
Signing in is what unlocks the hosted Kepler models. Your conversations and memory never go to the sign-in service. To sign out later, use Settings > General > Account.
2

Answer three questions

Kepler asks what to call you, where you live in the stack, and what is under your watch. Pick from the chips or type your own. The answers seed your profile so Kepler talks to you like someone who runs Kubernetes, not someone who is asking what a pod is.
Kepler onboarding scene on a dark starfield. It reads Hi, I'm Kepler, What should I call you, with a name typed in. An orbit on the right shows the name at its centre.
The second onboarding question, Where do you live in the stack, with role chips including SRE, DevOps, Platform Eng and Backend. SRE is selected.
The third onboarding question, What's under your watch, with technology chips. Kubernetes, GCP and GitHub are selected, and the orbit on the right has filled in with those systems around your name.
If you quit partway through, Kepler resumes at the same question next launch.
3

Connect a model

You land on the home screen. It greets you by name, lists what Kepler noticed on your machine, and says Choose an AI to start. Pick one there. Later, the model pill on the composer reads Connect a model whenever nothing usable is set up; click it, or type /model.
The Kepler home screen after onboarding. It greets the operator by name and reports that memory is ready and that it noticed an SSH host, two clusters and gcloud. Below, the hosted Kepler model is offered alongside providers detected on the machine.
You have two choices:
  • Hosted Kepler models. Available right away with your sign-in, no key needed. Pick kepler-expert and go.
  • Your own key. Open Settings > Models > Providers and add a key for Anthropic, OpenAI, Google (Gemini API or Vertex AI), xAI, AWS Bedrock, or an OpenAI-compatible endpoint. Ollama shows up under Found on this machine if it is running.
The Kepler model picker open over the composer. Hosted Kepler models are listed first under your Kepler plan, then a provider group from your own plan, then Google Vertex AI under your API key. Below the list sit a Reasoning slider and a Max mode toggle for this session.
Keys you add stay on this machine, in your operating system’s keychain. Kepler never uploads them. Whichever model you pick, Kepler keeps using it until you change it. It does not fall back to a different model when one fails. It retries the same one or tells you.
4

Open a workspace

Press Cmd+O and pick a folder, or type /workspace add <path> in the composer. Your infra repo or a folder with your manifests is a good first workspace.Kepler can only read and edit files inside folders you have granted. It starts with your home folder as a default workspace. When a command reaches outside the granted folders, Kepler stops and asks, and you can allow it once, for this session, or add the folder to the workspace.You do not need to hand over kubeconfigs or cloud credentials. Kepler uses whatever kubectl, aws, gcloud, and ssh already have on your machine.
5

Ask a read-only question

New conversations start in Observe, the read-only posture. The chip on the composer shows it. Kepler will run reads (kubectl get, kubectl logs, describe, log greps) without asking, and will not run anything that writes.Type something you would ask a colleague:
What you will see, in order:
  1. The thinking orbit while Kepler works out what to check.
  2. Tool cards, one per command. Each shows the exact command and its output. Expand any of them to read the raw text yourself.
  3. A diagnosis with evidence. Kepler quotes the lines it is relying on (an OOMKilled event, a missing secret, a bad image tag) so you can check its reasoning against what actually ran.
  4. A suggested fix. In Observe this is a proposal, not an action. Nothing changes until you say so.
Kepler's reply in Observe to why checkout is crashlooping in prod. A row for each kubectl command it ran, a Not run row for a configmap patch it was not allowed to run, then a Finding that the ConfigMap provides DATABASE_URI while checkout needs DATABASE_URL, an Evidence list quoting the pod log, and a safe remediation.
Try a few more while you are here:
/plan makes Kepler investigate and then write a reviewable plan with steps, blast radius, and rollback, and stop there.
6

Make one small change in Assist

Press Shift+Tab to move the posture chip from Observe to Assist, or type /mode assist. Assist lets Kepler act, but it asks before every change.Ask for something small and reversible:
Kepler runs the reads it needs, then stops. An approval dock slides in above the composer showing the exact kubectl command it wants to run, and a preview where one is available. You have four choices:
  • Run: run this one command and continue. Cmd+Enter does the same.
  • This session: run it, and stop asking about kubectl label for the rest of this conversation. Cmd+Shift+Enter does the same.
  • Always: run it, and allow kubectl label from now on in every conversation. This one saves a permanent rule, so use it only for verbs you are happy for Kepler to run unattended.
  • Reject: stop. Type a note first if you want to steer what Kepler tries next.
The approval dock above the Kepler composer. It shows a pending kubectl label command, a server dry-run preview of its effect, and four buttons: Reject, Always, This session, and Run. The posture chip reads Assist.
Click Run. Kepler applies the label, verifies it with a read, and reports back.Approvals come in three lifetimes: this once, for the rest of the session, or from now on. Which ones the dock offers depends on what is pending. A command outside your workspace folders can be added to the workspace for good, and a command Kepler has never seen gets its own card with Trust as read-only, which saves a rule that applies everywhere. Rules live in Settings > Permissions. Delete, scale, restart, and rm -rf are never offered in any posture.

​
Essential shortcuts and commands

​
Where to go next

Postures

Observe, Assist, and Yolo in detail, and when to use each.

The workspace

Panels, center stage, and how you and Kepler share the terminal and browser.

Permissions

Per-tool switches, command rules, and the always-blocked list.

Commands

Every slash command, from /investigate to /handoff.