[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-92312":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":14,"stars7d":14,"stars30d":15,"stars90d":14,"forks30d":14,"starsTrendScore":14,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":14,"starSnapshotCount":14,"syncStatus":12,"lastSyncTime":25,"discoverSource":26},92312,"rocketplaneIO","olemeyer\u002FrocketplaneIO","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.",null,"TypeScript",131,2,122,0,10,42.43,"Apache License 2.0",false,"main",true,[],"2026-07-22 04:02:05","\u003Cdiv align=\"center\">\n\n\u003Cpicture>\n  \u003Csource media=\"(prefers-color-scheme: dark)\" srcset=\".github\u002Fassets\u002Fbanner-dark.png\">\n  \u003Csource media=\"(prefers-color-scheme: light)\" srcset=\".github\u002Fassets\u002Fbanner-light.png\">\n  \u003Cimg alt=\"rocketplaneIO\" src=\".github\u002Fassets\u002Fbanner-dark.png\" width=\"100%\">\n\u003C\u002Fpicture>\n\n\u003Ch2>An AI SRE for your Kubernetes cluster —\u003Cbr>that can actually fix things, safely.\u003C\u002Fh2>\n\n\u003Cp>\u003Cb>Self-hosted · Apache-2.0 · bring your own LLM · air-gapped capable\u003C\u002Fb>\u003C\u002Fp>\n\n![Status](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-alpha-e5484d)\n[![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-Apache--2.0-blue)](LICENSE)\n![Go](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fgo-1.25+-00ADD8)\n\n[**Quick start**](#quick-start) · [**Is it safe?**](#is-it-safe) · [**Under the hood**](#under-the-hood)\n\n\u003C\u002Fdiv>\n\n\u003Cbr>\n\n\u003Cimg alt=\"The Copilot investigating a latency spike: evidence-based root cause, then a scale action waiting for one-click approval\" src=\".github\u002Fassets\u002Fshot-copilot.png\" width=\"100%\">\n\u003Cdiv align=\"center\">\u003Csub>You ask \u003Ci>“why is checkout slow?”\u003C\u002Fi>. The Copilot reads the service map and the logs itself,\nnames the root cause with evidence, and proposes \u003Cb>one\u003C\u002Fb> fix — which runs only after you approve it,\nas a pipeline that verifies itself or rolls back.\u003C\u002Fsub>\u003C\u002Fdiv>\n\n\u003Cbr>\n\n> **Alpha.** The full loop works end-to-end today, developed against minikube. APIs and schemas\n> still change without notice — don't point it at production yet.\n\n## Three things you don't get anywhere else\n\n### 1 · An AI SRE with a safety catalog — not an AI with kubectl\n\nThe Copilot investigates on its own: eBPF traces, logs, PromQL metrics, the live service map and\nthe **full Kubernetes inventory** (Services, Ingress, ConfigMaps, policies — everything). But it\ncan only change the cluster through **~30 named, reversible action pipelines**. No shell, no\n`kubectl`, no YAML it could hallucinate.\n\nEvery action is risk-graded — and *you* set the approval rule per level:\n\n| Level | Examples | Default approval |\n|---|---|---|\n| ◎ read-only | debug bundle, rollout history, drain preview | runs automatically |\n| ↺ reversible | scale up, restart, set image, config edits | one click |\n| ◇ disruptive | evict pod, rollout undo, cleanup | one click |\n| △ destructive | drain, **scale-to-0**, NoExecute taint | **type the target's name to arm** |\n\nRisk is parameter-aware (`scale replicas=3` is reversible; `replicas=0` is destructive), scope is\nenforced server-side (a namespace-scoped session cannot touch nodes or other namespaces), and\nevery level can be set to `auto`, `click`, `confirm` or `off`.\n\n**The model proposes. Deterministic pipelines execute, verify at pod level, and roll back.**\nThe LLM never touches the cluster directly.\n\nBring any Anthropic- or OpenAI-compatible model — including a fully local, air-gapped one. Your\ntelemetry never leaves your infrastructure either way.\n\n### 2 · Traces for services you never instrumented\n\nOne outbound-only agent plus an eBPF DaemonSet\n([OTel eBPF Instrumentation](https:\u002F\u002Fgithub.com\u002Fgrafana\u002Fbeyla), née Grafana Beyla). HTTP\u002FgRPC\nspans **with cross-service context propagation — including compiled Go binaries** — plus SQL,\nRedis and Kafka client spans. No SDKs, no sidecars, no code changes.\n\n\u003Cimg alt=\"A real 500 investigated: the failure cascades across three services, correlated error logs on the right\" src=\".github\u002Fassets\u002Fshot-trace.png\" width=\"100%\">\n\u003Cdiv align=\"center\">\u003Csub>A real 500 on \u003Ccode>GET \u002Fcheckout\u003C\u002Fcode>: the failure cascades frontdoor → checkout → catalog,\nthe exact ERROR log lines are correlated on the right. \u003Cb>No SDK in any of these services.\u003C\u002Fb>\nAn ERROR log line is two clicks away from this view. PromQL runs on the real Prometheus engine, embedded, on ClickHouse.\u003C\u002Fsub>\u003C\u002Fdiv>\n\n### 3 · Every change proves itself — or undoes itself\n\nActions aren't fire-and-forget `kubectl` calls. Each one is a pipeline —\n**trigger → observe → verify** — that only reports success when the cluster actually converged:\nold pods gone, new pods Ready, stable. Cancel, timeout or a failed verify triggers automatic\nrollback from a snapshot taken *before* the mutation.\n\n\u003Cimg alt=\"The Runs audit trail: every execution as an expandable row with its full pipeline, and a one-click revert\" src=\".github\u002Fassets\u002Fshot-runs.png\" width=\"100%\">\n\u003Cdiv align=\"center\">\u003Csub>\u003Cb>Runs\u003C\u002Fb> — the audit trail. Who ran what, the full step timeline, and\n\u003Cb>↺ revert\u003C\u002Fb>: one click re-applies the exact state captured before the change. Cancel always\nterminates — a reaper finalizes anything a dead agent leaves behind, and force-cancel never waits.\u003C\u002Fsub>\u003C\u002Fdiv>\n\n## Quick start\n\nThe whole platform runs from published images ([ghcr.io](https:\u002F\u002Fgithub.com\u002Folemeyer?tab=packages&repo_name=rocketplaneIO)).\nYou need Docker and a Kubernetes cluster to point it at (minikube is fine).\n\n**1 — run the platform**\n\n```bash\ncurl -O https:\u002F\u002Fraw.githubusercontent.com\u002Folemeyer\u002FrocketplaneIO\u002Fmain\u002Fdeploy\u002Fcompose\u002Fdocker-compose.prod.yml\ncurl -o .env https:\u002F\u002Fraw.githubusercontent.com\u002Folemeyer\u002FrocketplaneIO\u002Fmain\u002Fdeploy\u002Fcompose\u002F.env.example\n# set RP_SESSION_SECRET in .env (e.g. `openssl rand -hex 32`); defaults are fine for a local trial\n\ndocker compose --env-file .env -f docker-compose.prod.yml up -d\n```\n\nThe UI comes up on **http:\u002F\u002Flocalhost:4173**, the control plane on `:8090`.\n\n**2 — connect your cluster**\n\nOpen the UI, create the owner account, hit **Connect cluster** — it hands you one copy-paste\ncommand that installs the agent and the Beyla DaemonSet (a rendered `kubectl apply`, or Helm).\nWhen the service map draws your namespaces and spans appear under Traces, you're live — without\ntouching a line of your code.\n\n> Local minikube note: your cluster reaches the control plane at `http:\u002F\u002Fhost.minikube.internal:8090`,\n> not `localhost` — set `RP_AGENT_CONTROLPLANE_URL` to that in `.env` before connecting.\n\n**3 — turn on the Copilot**\n\nOpen it from the top bar and connect any Anthropic- or OpenAI-compatible provider (including a\nlocal one). The key stays on your instance; requests go straight from your control plane to the\nprovider you chose.\n\n\u003Csub>Images are tagged \u003Ccode>edge\u003C\u002Fcode> (tracks \u003Ccode>main\u003C\u002Fcode>) today; tagged releases and a\nplatform Helm chart are the next milestone. Want a demo workload? A Python + Redis shop behind\nnginx — the one in every screenshot here — ships in\n\u003Ca href=\"deploy\u002Fdev\u002F\">deploy\u002Fdev\u002F\u003C\u002Fa> (\u003Ccode>kubectl apply -f deploy\u002Fdev\u002Fshop-realistic.yaml -f deploy\u002Fdev\u002Ffrontdoor.yaml\u003C\u002Fcode>).\u003C\u002Fsub>\n\n## Is it safe?\n\nThe section every platform team reads first:\n\n- **Outbound-only.** The agent dials out over HTTPS; nothing connects into your cluster, nothing\n  listens. Actions are *claimed* by the agent — never pushed in.\n- **Enumerated RBAC, two blocks** ([`deploy\u002Finstall.yaml`](deploy\u002Finstall.yaml)): *observe* is\n  read-only; *act* holds exactly the write verbs the action catalog needs. Delete the act block\n  (or set `rbac.actions=false` in Helm) for a strictly observe-only agent. No wildcards, no\n  cluster-admin.\n- **Secrets:** the inventory shows names, types and key counts — never values. That restraint is\n  enforced in agent code; if you'd rather enforce it with RBAC too, delete the one `secrets` rule\n  and the agent degrades gracefully.\n- **The LLM is caged.** It reads through the same authenticated APIs you use, and mutates only\n  via the whitelisted, validated, risk-gated action catalog. Every proposal, approval and result\n  lands in the audit trail.\n- **eBPF:** Beyla runs as a privileged DaemonSet (kernel ≥ 5.8 with BTF). The capture layer is\n  upstream OpenTelemetry tooling — rocketplaneIO is the investigation-and-action loop on top.\n- **Footprint** (measured on single-node minikube under continuous synthetic load — indicative,\n  not a production benchmark): the rocketplaneIO **agent** is one lightweight pod at **~2m CPU\n  and ~10Mi memory**, cluster-wide. **Beyla** is the real cost and scales with request volume —\n  **~0.02 core idle, spiking to ~0.25 core under load, ~280Mi memory per node** (bounded; its\n  default limit is 512Mi). One agent for the cluster, one Beyla per node.\n\n## What else is in the box\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Live service map · alerts with auto-remediation · PromQL on ClickHouse · full K8s inventory · Starlark workflows · more screens\u003C\u002Fb>\u003C\u002Fsummary>\n\u003Cbr>\n\n\u003Cimg alt=\"Live service map with automatic technology detection\" src=\".github\u002Fassets\u002Fshot-servicemap.png\" width=\"100%\">\n\u003Csub>\u003Cb>Service map\u003C\u002Fb> — topology from real eBPF traffic flows; tech logos matched from container\nimages; live-updating.\u003C\u002Fsub>\n\n\u003Cbr>\u003Cbr>\n\n\u003Cimg alt=\"Alert rule firing and dispatching an auto-remediation workflow\" src=\".github\u002Fassets\u002Fshot-alerts.png\" width=\"100%\">\n\u003Csub>\u003Cb>Alerts\u003C\u002Fb> — typed checks or PromQL conditions with \u003Ccode>for\u003C\u002Fcode>-durations and\nsparklines. A firing rule can dispatch a remediation workflow: once per transition, fully audited,\nstill subject to verify-or-rollback.\u003C\u002Fsub>\n\n\u003Cbr>\u003Cbr>\n\n\u003Cimg alt=\"PromQL editor on ClickHouse\" src=\".github\u002Fassets\u002Fshot-promql.png\" width=\"100%\">\n\u003Csub>\u003Cb>PromQL\u003C\u002Fb> — the actual Prometheus evaluation engine, embedded and pointed at ClickHouse\n(\u003Ca href=\"services\u002Fcontrolplane\u002Finternal\u002Fpromqlx\">internal\u002Fpromqlx\u003C\u002Fa>); editor built on\ncodemirror-promql. Custom metrics are named PromQL expressions, validated at save.\u003C\u002Fsub>\n\n\u003Cbr>\u003Cbr>\n\n\u003Cimg alt=\"Full Kubernetes inventory, tabbed by resource kind\" src=\".github\u002Fassets\u002Fshot-resources.png\" width=\"100%\">\n\u003Csub>\u003Cb>Resources\u003C\u002Fb> — the complete cluster inventory (Services, Ingress, ConfigMaps, batch,\npolicies, volumes, quotas), synced every 60s. The same data the Copilot reads via\n\u003Ccode>list_resources\u003C\u002Fcode>.\u003C\u002Fsub>\n\n\u003Cbr>\u003Cbr>\n\n\u003Cimg alt=\"Actions catalog, grouped by category with risk levels\" src=\".github\u002Fassets\u002Fshot-actions.png\" width=\"100%\">\n\u003Csub>\u003Cb>Actions\u003C\u002Fb> — the catalog, searchable and risk-graded. Every built-in is also readable,\nforkable \u003Cb>Starlark\u003C\u002Fb>: automate what an operator does by hand, with typed parameters that\nrender as forms. Deterministic, compiled at save.\u003C\u002Fsub>\n\n\u003Cbr>\u003Cbr>\n\n\u003Cimg alt=\"Log stream with severity histogram\" src=\".github\u002Fassets\u002Fshot-logs.png\" width=\"100%\">\n\u003Csub>\u003Cb>Logs\u003C\u002Fb> — severity histogram, brushing, and the two-click path to the distributed\ntrace.\u003C\u002Fsub>\n\n\u003Cbr>\u003Cbr>\n\n\u003Cimg alt=\"Node infrastructure with kubelet stats\" src=\".github\u002Fassets\u002Fshot-nodes.png\" width=\"100%\">\n\u003Csub>\u003Cb>Nodes\u003C\u002Fb> — kubelet-level stats; cordon\u002Fdrain are verified actions, with a read-only\n\u003Ccode>drain preview\u003C\u002Fcode> that shows the blast radius first.\u003C\u002Fsub>\n\n\u003Cbr>\u003Cbr>\n\n\u003Csub>The UI follows a strict instrument-panel design system (RETICLE) — healthy is calm, only\nanomalies speak.\u003C\u002Fsub>\n\u003C\u002Fdetails>\n\n## Under the hood\n\n```\n YOUR CLUSTER   agent (Go, outbound-only, enumerated RBAC)      beyla eBPF DaemonSet\n                topology · logs · inventory · action pipelines   HTTP\u002FgRPC\u002FGo · SQL\u002FRedis\u002FKafka\n                        │ HTTPS                                          │ OTLP\n                        ▼                                                ▼\n CONTROL PLANE  control plane (Go, single binary)                OTel collector → ClickHouse\n                API · auth\u002Forgs · alert evaluator · action queue · Copilot loop\n                embedded Prometheus engine (PromQL → ClickHouse) · SSE broker\n                        │\n DATA           PostgreSQL (state, rules, runs, chats)  ·  ClickHouse (logs, traces, metrics)\n ACCESS         web (Next.js) — service map · copilot · logs · traces · metrics · alerts · actions · runs\n```\n\nThe Copilot is a tool-calling loop inside the control plane: 16 read tools (logs, traces —\nincluding single-trace waterfalls and trace↔log correlation — PromQL, service map, inventory,\ndebug bundles) plus exactly one mutating tool, `run_safe_action`, which pauses the stream for\nhuman approval. The same toolbox is exposed as an [MCP server](services\u002Fcontrolplane\u002Fcmd\u002Fmcp),\nso Claude Code or Cursor can operate your cluster through the identical guardrails.\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Monorepo layout\u003C\u002Fb>\u003C\u002Fsummary>\n\n```\n├── agent\u002F                      # in-cluster agent (Go): sync, logs, inventory, action pipelines + revert snapshots\n├── services\u002Fcontrolplane\u002F      # control plane (Go): API, auth, alerts, Copilot loop, PromQL engine\n│   └── internal\u002F\n│       ├── api\u002F                #   REST + SSE + copilot_* (loop, guardrails, approval gate)\n│       ├── promqlx\u002F            #   embedded Prometheus engine on ClickHouse\n│       ├── alerts\u002F · telemetry\u002F · events\u002F · store\u002F · migrations\u002F\n│       └── ..\u002Fcmd\u002Fmcp\u002F         #   MCP server — same tools for external agents\n├── apps\u002Fweb\u002F                   # Next.js UI (RETICLE design system)\n└── deploy\u002F                     # compose (platform + dev stores), helm chart, install.yaml, demo shop\n```\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Cb>Develop from source\u003C\u002Fb>\u003C\u002Fsummary>\n\u003Cbr>\n\nPrereqs: Go 1.25+, Node 22+ with pnpm, Docker.\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Folemeyer\u002FrocketplaneIO && cd rocketplaneIO\n\ndocker compose -f deploy\u002Fcompose\u002Fdocker-compose.yml up -d          # dev data stores + collector\ngo run .\u002Fservices\u002Fcontrolplane\u002Fcmd\u002Fcontrolplane                    # control plane on :8090\ncd apps\u002Fweb && pnpm install && pnpm dev                            # UI on :4173\n```\n\nBuilding the platform images yourself (what CI publishes):\n\n```bash\ndocker build -t rocketplaneio\u002Fcontrolplane -f services\u002Fcontrolplane\u002FDockerfile .\ndocker build -t rocketplaneio\u002Fweb          -f apps\u002Fweb\u002FDockerfile .\ndocker build -t rocketplaneio\u002Fagent        -f agent\u002FDockerfile .\n```\n\u003C\u002Fdetails>\n\n## Status\n\n| Works end-to-end today | On the roadmap |\n|---|---|\n| Copilot: BYO-LLM investigation → guardrailed fixes | Tagged releases + platform Helm chart |\n| eBPF traces incl. compiled Go, log→trace correlation | Hosted demo |\n| ~30 safe actions with verify, rollback and revert | Production-scale overhead benchmarks |\n| Runs audit trail, guaranteed-terminating cancel | Multi-user RBAC hardening |\n| Alerts with auto-remediation dispatch | Server-side LLM key vault |\n| PromQL + custom metrics on ClickHouse, full K8s inventory | |\n| Published multi-arch images (`edge`) + agent install.yaml | |\n\n## Contributing\n\nReports from real clusters are the contribution we want most —\n[open an issue](https:\u002F\u002Fgithub.com\u002Folemeyer\u002FrocketplaneIO\u002Fissues). See\n[CONTRIBUTING.md](CONTRIBUTING.md). If this resonates, a star helps others find it.\n\n## License\n\n[Apache-2.0](LICENSE).\n\n---\n\n\u003Cdiv align=\"center\">\n\u003Csub>Built with Go, Next.js, eBPF and ClickHouse · rocketplaneIO\u003C\u002Fsub>\n\u003C\u002Fdiv>\n","rocketplaneIO 是一个自托管的 Kubernetes AI 运维（SRE）工具，通过零侵入式 eBPF 实现全栈可观测性，并内置安全可控的 AI Copilot，可基于证据自动诊断问题并执行预定义、可验证、可回滚的操作。其核心特点是：不依赖应用侧埋点，直接采集内核级网络与系统调用数据；所有集群变更均经由服务端强制校验的确定性流水线执行，支持按风险等级分级审批（自动\u002F单击\u002F确认\u002F禁用）；支持 BYO-LLM，完全离线部署。适用于中大型 Kubernetes 环境中追求自动化运维但对安全性与合规性要求严格的 SRE 团队和平台工程团队。","2026-07-08 04:30:04","CREATED_QUERY"]