by olemeyer
Self-hosted AI SRE for Kubernetes — zero-instrumentation eBPF observability plus a copilot that fixes issues through guardrailed, self-verifying actions. BYO-LLM, air-gapped capable.
# Add to your Claude Code skills
git clone https://github.com/olemeyer/rocketplaneIOGuides for using ai agents skills like rocketplaneIO.
rocketplaneIO is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by olemeyer. Self-hosted AI SRE for Kubernetes — zero-instrumentation eBPF observability plus a copilot that fixes issues through guardrailed, self-verifying actions. BYO-LLM, air-gapped capable. It has 122 GitHub stars.
rocketplaneIO's catalog security scan is still queued. You can run an instant dependency and prompt-injection check now with the "Scan for vulnerabilities" button above.
Clone the repository with "git clone https://github.com/olemeyer/rocketplaneIO" and add it to your Claude Code skills directory (see the Installation section above).
rocketplaneIO is primarily written in TypeScript. It is open-source under olemeyer on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh rocketplaneIO against similar tools.
No comments yet. Be the first to share your thoughts!
Unlocks once the catalog security scan passes (runs nightly).
The deep catalog scan for this skill is still queued. Run an instant dependency check now instead.
Quick start · Is it safe? · Under the hood
Alpha. The full loop works end-to-end today, developed against minikube. APIs and schemas still change without notice — don't point it at production yet.
The Copilot investigates on its own: eBPF traces, logs, PromQL metrics, the live service map and
the full Kubernetes inventory (Services, Ingress, ConfigMaps, policies — everything). But it
can only change the cluster through ~30 named, reversible action pipelines. No shell, no
kubectl, no YAML it could hallucinate.
Every action is risk-graded — and you set the approval rule per level:
| Level | Examples | Default approval |
|---|---|---|
| ◎ read-only | debug bundle, rollout history, drain preview | runs automatically |
| ↺ reversible | scale up, restart, set image, config edits | one click |
| ◇ disruptive | evict pod, rollout undo, cleanup | one click |
| △ destructive | drain, scale-to-0, NoExecute taint | type the target's name to arm |
Risk is parameter-aware (scale replicas=3 is reversible; replicas=0 is destructive), scope is
enforced server-side (a namespace-scoped session cannot touch nodes or other namespaces), and
every level can be set to auto, click, confirm or off.
The model proposes. Deterministic pipelines execute, verify at pod level, and roll back. The LLM never touches the cluster directly.
Bring any Anthropic- or OpenAI-compatible model — including a fully local, air-gapped one. Your telemetry never leaves your infrastructure either way.
One outbound-only agent plus an eBPF DaemonSet (OTel eBPF Instrumentation, née Grafana Beyla). HTTP/gRPC spans with cross-service context propagation — including compiled Go binaries — plus SQL, Redis and Kafka client spans. No SDKs, no sidecars, no code changes.
Actions aren't fire-and-forget kubectl calls. Each one is a pipeline —
trigger → observe → verify — that only reports success when the cluster actually converged:
old pods gone, new pods Ready, stable. Cancel, timeout or a failed verify triggers automatic
rollback from a snapshot taken before the mutation.
The whole platform runs from published images (ghcr.io). You need Docker and a Kubernetes cluster to point it at (minikube is fine).
1 — run the platform
curl -O https://raw.githubusercontent.com/olemeyer/rocketplaneIO/main/deploy/compose/docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/olemeyer/rocketplaneIO/main/deploy/compose/.env.example
# set RP_SESSION_SECRET in .env (e.g. `openssl rand -hex 32`); defaults are fine for a local trial
docker compose --env-file .env -f docker-compose.prod.yml up -d
The UI comes up on http://localhost:4173, the control plane on :8090.
2 — connect your cluster
Open the UI, create the owner account, hit Connect cluster — it hands you one copy-paste
command that installs the agent and the Beyla DaemonSet (a rendered kubectl apply, or Helm).
When the service map draws your namespaces and spans appear under Traces, you're live — without
touching a line of your code.
Local minikube note: your cluster reaches the control plane at
http://host.minikube.internal:8090, notlocalhost— setRP_AGENT_CONTROLPLANE_URLto that in.envbefore connecting.
3 — turn on the Copilot
Open it from the top bar and connect any Anthropic- or OpenAI-compatible provider (including a local one). The key stays on your instance; requests go straight from your control plane to the provider you chose.
Images are tagged edge (tracks main) today; tagged releases and a platform Helm chart are the next milestone. Want a demo workload? A Python + Redis shop behind nginx — the one in every screenshot here — ships in deploy/dev/ (kubectl apply -f deploy/dev/shop-realistic.yaml -f deploy/dev/frontdoor.yaml).
The section every platform team reads first:
deploy/install.yaml): observe is
read-only; act holds exactly the write verbs the action catalog needs. Delete the act block
(or set rbac.actions=false in Helm) for a strictly observe-only agent. No wildcards, no
cluster-admin.secrets rule
and the agent degrades gracefully.<img alt="Log stream with