rocketplaneIO

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.

Three things you don't get anywhere else

1 · Traces for services you never instrumented

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.

2 · Logs, traces, metrics and topology — one dataset, not four tools

It's not four products bolted together. A log line is two clicks from its distributed trace. The service map is drawn from real eBPF traffic, not a static config — tech logos matched from container images, health live from RED metrics. PromQL runs on the actual Prometheus evaluation engine, embedded, over ClickHouse. And the complete Kubernetes inventory — Services, Ingress, ConfigMaps, policies, volumes — is synced and searchable right beside it. Everything self-hosted; your telemetry never leaves your infrastructure.

3 · And it can fix what it finds — safely

Observability that stops at "here's the problem" leaves the hard part to you. rocketplaneIO doesn't ship its own AI — it's the MCP interface your existing agent (Claude Code, Cursor, anything that speaks MCP) connects to. The agent reads everything above, and acts through kubectl-shaped primitives (k8s_get / k8s_patch / k8s_apply / k8s_delete / k8s_exec / Starlark workflows) on any resource, CRDs included.

The guardrail is a transaction. Nothing mutates outside one — every change is snapshotted durably before it commits, so cancel, timeout or a later Revert restores every before-state in reverse (LIFO). Each operation is risk-classified by rocketplaneIO, not by the model:

Classification is parameter-aware (replicas: 3 is reversible; : 0 is destructive) and fail-closed. Disruptive and destructive operations park until a human approves them — and an API token can never approve its own proposals.

Quick start

You need Docker and a Kubernetes cluster to point it at (minikube is fine).

1 — run the platform (one command)

curl -fsSL https://rocketplane.io/install.sh | sh

That's the whole install: it downloads the compose bundle, generates real secrets, pulls the published images and starts everything. The UI comes up on http://localhost:4173 (create the owner account there), the control plane on :8090. Re-running the same command later is the update path — secrets are kept, images are bumped to the newest release.

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

# REQUIRED: a real session secret — the control plane refuses to start without one.
echo "RP_SESSION_SECRET=$(openssl rand -hex 32)" >> .env

docker compose --env-file .env -f docker-compose.prod.yml up -d

Production mode by default (no anonymous login). For a throwaway localhost trial add RP_ENV=dev to .env to skip account setup.

2 — connect your cluster

Open the UI, 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. The installer auto-detects a LAN address your cluster can dial back to; for a local minikube that is http://host.minikube.internal:8090.

3 — connect your AI agent

Create an API token under Settings → API keys (role admin for mutations), then:

claude mcp add --transport http rocketplaneio \
  http://localhost:8090/mcp/orgs/<org>/clusters/<cluster> \
  --header "Authorization: Bearer rp_..."

The Settings → MCP tab generates this snippet (and the .mcp.json / Cursor variants) with your real IDs filled in. From that moment your agent can investigate freely — and every change it wants to make runs through a transaction you can watch, gate and roll back live under Transactions.

Images ship as pinned releases (see RP_VERSION in .env); edge tracks main for the latest unreleased changes. A platform Helm chart is 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).

Is it safe?

The section every platform team reads first:

• Outbound-only. The agent dials out over HTTPS; nothing connects into your cluster, nothing listens. Actions are claimed by the agent — never pushed in.
• Auth. In production the dev-login bypass is off: the first account is created at /setup, or you wire up Google SSO. Sessions are HMAC-signed with RP_SESSION_SECRET, and the control plane refuses to start with a missing or weak one — no forgeable cookies, no shipped default.
• Network / TLS. The control plane speaks plain HTTP on :8090 — put it behind a TLS reverse proxy (or the platform Helm chart's ingress) for anything past localhost. The OTLP ingest ports 4317/4318 are unauthenticated by design; keep them on a trusted network (in-cluster or behind the proxy), not on the public internet.
• RBAC, two blocks (deploy/install.yaml): observe is enumerated read-only; act is deliberately broad — the generic operation set works on any kind, CRDs included. The guardrails are architectural, not a resource list: no mutation outside a transaction, risk classification, human approval for hard operations, durable pre-mutation snapshots, LIFO rollback, full audit. Delete the act block (or set rbac.actions=false in Helm) for a strictly observe-only agent.
• Secrets: the inventory shows names, types and key counts — never values. That restraint is enforced in agent code; if you'd rather enforce it with RBAC too, delete the one secrets rule and the agent degrades gracefully.
• The agent is fenced, not trusted. It authenticates with an org-scoped API token against the same RBAC you use; mutations demand an admin token AND an open transaction; disruptive and destructive operations park until a human approves them in the UI — and a token can never approve its own proposals. Every tool call, decision and result lands in the transaction timeline.
• eBPF: Beyla runs as a privileged DaemonSet (kernel ≥ 5.8 with BTF). The capture layer is upstream OpenTelemetry tooling — rocketplaneIO is the investigation-and-action loop on top.
• Footprint (measured on single-node minikube under continuous synthetic load — indicative, not a production benchmark): the rocketplaneIO agent is one lightweight pod at ~2m CPU and ~10Mi memory, cluster-wide. Beyla is the real cost and scales with request volume — **~0.02 core idle, spiking