> ## Documentation Index > Fetch the complete documentation index at: https://radarhq.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # FluxCD UI and Kubernetes integration > Use Radar as an open-source Flux UI for Kustomizations, HelmReleases, sources, dependency topology, failure diagnosis, and reconciliation controls. [Flux](https://fluxcd.io/) reconciles Kubernetes resources from Git, OCI, Helm, and bucket sources. Radar adds a graphical Flux UI on top of the CRDs already in your cluster, using your existing Kubernetes identity and RBAC. There is no Flux-side plugin or separate integration service to configure. This page focuses on the Flux experience. See the [GitOps workspace](/docs/features/gitops) for the shared Argo CD and Flux workflow, or the [GitOps coverage matrix](/docs/features/integrations/gitops-flux-argo) for exact CRD and feature support. ## See every Flux workload and state Open **GitOps** to see Flux Kustomizations and HelmReleases in one operational view. Each row resolves the source URL and revision, path or chart, target namespace, reconciliation status, health, automation mode, and lifecycle state. Search and filter across healthy, reconciling, failed, suspended, and terminating resources without switching between `flux get`, `kubectl describe`, and controller logs. Radar Flux fleet view showing Kustomizations and HelmReleases with source, sync, health, destination, and lifecycle state ## Follow sources, dependencies, and managed resources Radar builds a live topology for each Kustomization and HelmRelease: * The source relationship to a GitRepository, OCIRepository, HelmRepository, or Bucket. * `dependsOn` relationships between Kustomizations or HelmReleases. * Resources from a Kustomization's Flux inventory. * Resources owned by a HelmRelease, matched using the labels written by Flux helm-controller. * Kubernetes ownership from workloads through ReplicaSets and Pods. Click a nested Kustomization or HelmRelease to open its own GitOps detail page while retaining a breadcrumb back to the parent. Radar topology for a healthy Flux Kustomization showing its GitRepository, dependent Kustomization, Service, Deployment, HPA, ReplicaSet, and Pods ## Diagnose failed reconciliations Radar turns Flux conditions into an operator-facing issue band. It highlights failing `Ready`, `Healthy`, `Released`, and `TestSuccess` conditions, plus `Stalled=True` and active `Reconciling=True` state. Radar preserves the controller's exact message and adds action guidance for common source, chart, build, dependency, and apply failures. The Activity tab shows the current condition transitions and applied or attempted revision. Terminating resources get a dedicated lifecycle state, deletion-age severity, finalizer ownership, and controller-health attribution when Radar can read the Flux controller Pods. Radar diagnosing a failed Flux HelmRelease because no chart version matches, with its HelmRepository source and Reconcile, Sync with source, and Suspend actions ## Operate Flux from the UI Kustomization and HelmRelease detail pages expose the common Flux operations: | Operation | Radar behavior | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Reconcile** | Adds `reconcile.fluxcd.io/requestedAt` to trigger reconciliation outside the configured interval. | | **Sync with source** | Reconciles the referenced source first, then reconciles the Kustomization or HelmRelease. This mirrors `flux reconcile ... --with-source`. | | **Suspend / Resume** | Toggles `spec.suspend` to pause or resume reconciliation. | The same reconciliation, suspend, and resume operations are available to AI clients through Radar's [MCP server](/docs/features/mcp). Kubernetes RBAC remains the enforcement boundary. ## Flux context throughout Radar Flux ownership is useful outside the GitOps workspace: * **Helm releases** installed by Flux carry a `Managed by Flux` link back to the owning HelmRelease and warn that direct Helm changes may be reconciled back. * **Topology and Timeline** route Flux Kustomizations and HelmReleases to their GitOps detail pages. * **Resource views** provide dedicated renderers for Kustomizations, HelmReleases, GitRepositories, OCIRepositories, HelmRepositories, and Alerts. ## Supported Flux resources Kustomizations and HelmReleases get the complete GitOps workflow: fleet status, dedicated detail pages, topology, diagnosis, activity, and operations. GitRepositories, OCIRepositories, HelmRepositories, and Alerts have dedicated resource details, while Bucket sources can appear in topology and use Radar's generic resource detail. See the [GitOps coverage matrix](/docs/features/integrations/gitops-flux-argo) for exact CRD versions and per-resource fleet, topology, detail, and structured AI coverage. ## Install and permissions If Flux is already installed, [install and run Radar](/docs/install) against the same cluster. Radar discovers the Flux CRDs automatically. Local Radar uses the permissions of your current kubeconfig identity. For in-cluster Radar, Flux CRD read access is enabled by default through `rbac.crdGroups.flux`; leave it enabled. Reconcile, sync-with-source, suspend, and resume require `patch` on the relevant Flux CRDs. See [in-cluster configuration](/docs/configuration/in-cluster) for Helm values and narrower `rbac.additionalRules`. Radar currently builds Flux topology from resources in the connected cluster. It does not expose generic rollback or per-resource selective sync for Flux, and desired manifest content is not yet available for Git-to-live field diffs. See the broader [GitOps workspace](/docs/features/gitops) for the current Argo CD and Flux capability split.