Skip to content
Eddy

v1.0 · early release

A fast, keyboard-first, multi-cluster UI for Flux

See every Flux cluster you run in one place. Jump anywhere with ⌘K, reconcile or suspend with a single key, and read logs, events and YAML without leaving the keyboard.

Watch changes ripple through a live dependency graph, and let Claude Code investigate for you over MCP.

Try it on kindView on GitHub

Open source · Apache-2.0 · Built for our own platform work, shared in case it helps yours

An illustration built in HTML and CSS from the app's own design tokens. The colours mark the environment, and protected clusters carry a solid badge.
  • Production
  • Staging
  • Development

Who it's for

For teams that run Flux on more than one cluster

  • Platform and SRE teamsOne view of every cluster, without handing out kubeconfigs or exposing API servers.
  • People who live in the terminalA UI that keeps up with you. Search, reconcile, suspend and read logs from the keyboard.
  • Anyone who wants it openMulti-cluster is in the open-source edition, under Apache-2.0. Read it, run it, change it.

Features

Fast to use, hard to misuse

Multi-cluster, open source

A hub runs in your management cluster and a light agent runs in each workload cluster. Agents dial out to the hub, so no workload API server is exposed and the hub holds no cluster credentials.

  • dev
  • staging
  • prod-euprotected
  • Production
  • Staging
  • Development

Environment colours match the app: teal for development, violet for staging, orange for production. Protected clusters carry a solid badge and need a typed confirmation for writes.

Kubernetes RBAC is the permission model

Every read and action runs as the signed-in user, impersonated by the agent in each cluster. Each cluster decides what they may do. Eddy invents no roles, and it cannot do more than the user could with kubectl. Sign in with GitHub or OIDC (Google, Okta, Entra, Dex), and the agent's ServiceAccount stays read-only.

Sign-in guide

Live dependency graph

See sources, then each dependsOn layer, then what depends on them. When a reconcile starts, the change ripples through the graph live, so you can see what is blocked and why.

Add a cluster in a minute

The Add cluster wizard shows the install command with a one-time join token, then a live checklist ticks as the agent connects and syncs. No kubeconfig leaves your hands.

Fast

Agents stream summaries through informers and batched deltas, and the UI watches only the clusters on screen. Lists are virtualised and fleet search runs on the hub, so a big fleet stays responsive: we measure at 100 clusters × 15k resources.

Command palette and vim-style keys

⌘K searches every resource in every cluster. The rest of the keymap stays out of your way.

  • jmove down
  • kmove up
  • lopen
  • hback
  • rreconcile
  • Rreconcile with source
  • ssuspend
  • Llogs
  • aAsk AI
  • 123switch cluster
  • ?all keys

Keys shown are from the design prototype. Press ? in the app for the current list.

Threads and MCP for Claude Code

The hub serves an MCP endpoint. Claude Code, or any MCP client, can list clusters, find unhealthy resources across the fleet, read events and leave review threads that show up in the UI, marked via mcp. It acts with your identity, so it sees only what your RBAC allows. Create a token under Settings → Access tokens, then:

$ claude mcp add --transport http eddy https://<your-hub>/mcp \--header "Authorization: Bearer eddy_pat_…"

Then ask: "Review every failing HelmRelease across the fleet and leave a thread on each one with the likely cause." MCP and Claude Code docs

Ask AI

Ask AI: bring your model

Ask about a resource or a selection and get an answer grounded in what you can see. It is off by default.

v1.0 · ready
  • The Anthropic API.
  • AWS Bedrock through the Converse API, which is model-agnostic. Set any Bedrock model or inference profile that supports tool use as ai.bedrock.modelId: Claude, Amazon Nova (Lite, Pro, Premier), Meta Llama, Mistral and others.
  • Claude is the default and the model we test with. Others should work, and we would like to hear how it goes.
  • With Bedrock, data stays in your AWS account, with IAM through IRSA or Pod Identity.
Future · planned
  • OpenAI-compatible endpoints: self-hosted Ollama or vLLM, Azure OpenAI and others.

Guardrails, whichever model you use

  • Read-only tools only.
  • Answers are scoped to what the signed-in user can see (RBAC).
  • Secrets are redacted before anything reaches the model.
  • It can be switched off at runtime.

Security model

How it works

One hub, any number of clusters, all connections outbound

Eddy architectureBrowsers and MCP clients connect to the hub in the management cluster. The hub runs as active/active replicas that keep their data in PostgreSQL. Agent replicas in the prod-eu and staging workload clusters open outbound WebSocket connections to the hub. Each agent talks to its local Kubernetes API server as the impersonated user.Browsercookie, SSEGitHub/OIDCClaude CodeBearer eddy_pat_…HTTPSHTTPS · /mcpManagement clusterHub × N · active/activeUI · /api · /mcp :8080agent endpoint :8443PostgreSQL (bring your own)sessions, tokens, threads, auditWebSocket, dials outWebSocket, dials outprod-eu clusterAgent × 2informers, summaries,read-only ServiceAccountstaging clusterAgent × 2impersonated readsand actions
  • Production
  • Staging
  • Development
  1. Agents connect out. Each agent replica opens a WebSocket to the hub's agent endpoint with a token bound to one cluster name.
  2. Only summaries travel. Agents send resource summaries. Secret and ConfigMap data are never read.
  3. Actions run as you. The agent impersonates the signed-in user, so the cluster's own RBAC and audit log decide and record.

Status

v1.0 is ready to try. v1.1 is about agent security and access.

Eddy is at v1.0, an early release. Plans for what comes next can change.

v1.0 · ready
  • Hub and agents over outbound WebSocket, with 1..N agent replicas per cluster
  • Add cluster wizard with one-time join tokens and a live connection checklist
  • Kustomizations, HelmReleases and sources, plus Karpenter and External Secrets presets, core kinds and inventory, with reconcile, suspend and resume
  • Live dependency graph
  • ⌘K palette with fleet-wide server-side search
  • YAML, events and workload logs with structured JSON, and Ask AI on a selection
  • GitHub and OIDC sign-in (Google, Okta, Entra, Dex), local users and trusted reverse-proxy sign-in
  • MCP for Claude Code with personal access tokens and threads
  • Ask AI with your choice of model: see below
  • PostgreSQL (bring your own, for example CloudNativePG) with active/active hub replicas
  • Measured at 100 clusters × 15k resources: in our single-user benchmarks, fleet counts take about 10 ms, a 15k-row list about 100 ms and a fleet search about 35 ms
v1.1 · next
  • mTLS for agents (planned)
  • MCP OAuth (planned)
  • Hub-managed access: assign users to groups, with break-glass expiry (planned)

Future

  • SAML 2.0
  • Image automation
  • Notification alerts
  • flux diff

Full roadmap

Try it in about five minutes

Everything runs on a local kind cluster.

$ task kind:up
QuickstartRead the docs