Overview

Eddy shows every Flux cluster you run in one place. It is a fast, keyboard-first web UI, it is open source (Apache-2.0), and it is at v1.0. These docs take you from a local demo to a production install, one step at a time.

Full reference: docs/architecture.md in the repository.

Two parts

• The hub runs in your management cluster, two replicas by default. It serves the UI, the API and the MCP endpoint, and keeps its own data (sessions, tokens, threads, audit) in PostgreSQL.
• An agent runs in every workload cluster. It watches Flux and workloads, and it dials out to the hub over one WebSocket. Workload API servers are never exposed, and the hub holds no credentials for them.

Eddy has no permission model of its own. Each person signs in to the hub, and their requests run in each cluster as that user, impersonated by the agent. What they can see and do is decided by your normal Kubernetes RBAC. Only summaries leave a cluster: never Secret or ConfigMap data.

What you get in v1.0

• Flux Kustomizations, HelmReleases, Git, OCI and Helm repositories, HelmCharts and Buckets, plus workloads, pods and an inventory tree. Optional presets add Karpenter and External Secrets.
• Reconcile (with source), suspend and resume, with a typed confirmation on protected clusters.
• A ⌘K palette across every cluster, a live dependency graph, YAML, events and logs, and dark mode.
• Sign-in with GitHub or OIDC (Google, Okta, Entra ID, Dex), local users, or a trusted proxy.
• An Add cluster wizard, review threads, an MCP endpoint for Claude Code, and Ask AI.

How to read these docs

The pages follow the order you will need them. Each one ends with how to check that it worked.

Examples use made-up names: the domain eddy.internal.example.com, the organization acme and the clusters prod-eu and staging. Replace them with yours. Shell blocks show the command after a dimmed $; the Copy button leaves the prompt out.

The reference material lives in the repository: API and the design decisions.