Flux GitOps Config Builder

Both are CNCF GitOps tools for Kubernetes, but they take different approaches. Flux is pull-based and controller-driven — each resource type (GitRepository, HelmRelease, Kustomization) has a dedicated controller that watches and reconciles independently. ArgoCD is application-centric with a central server, a rich UI, and an opinionated Application CRD. Flux is generally more composable and CLI/YAML-first, while ArgoCD offers a better out-of-the-box UI. Flux v2 (the Flux this builder targets) is built on the GitOps Toolkit and supports multi-tenancy natively.

GitRepository sources manifests directly from a Git repository — Flux polls the repo on a defined interval and applies changes. OCIRepository sources OCI-compliant artifacts from a container registry (like GitHub Container Registry or Docker Hub). Use OCIRepository when your manifests or Helm charts are packaged as OCI artifacts and pushed to a registry as part of your CI pipeline. GitRepository is the standard choice for most GitOps setups where your YAML manifests live in Git.

A HelmRelease CRD tells the Helm controller to install or upgrade a Helm chart on a defined interval. The chart is sourced from either a HelmRepository or a GitRepository. On each reconciliation, Flux checks whether the installed release matches the desired state (chart version, values). If drift is detected or a new chart version matches the version constraint, Flux performs a Helm upgrade. Install and upgrade remediation settings control what happens on failure — the controller can automatically roll back or retry a configurable number of times.

The path field in a Flux Kustomization specifies the directory within the referenced GitRepository that contains your Kubernetes manifests or a kustomization.yaml file. It's relative to the repository root. For example, ./k8s/overlays/production points to a Kustomize overlay. If you don't use Kustomize overlays, you can point path to any directory containing plain YAML manifests — Flux will apply them all. Use path: ./ to apply everything in the root. The targetNamespace field lets you override the namespace for all resources in that path.

Flux image automation has three components: ImageRepository (scans a container registry for available tags), ImagePolicy (selects which tag to use based on a policy like semver range or alphabetical order), and ImageUpdateAutomation (writes the selected tag back to Git by updating image references in your YAML files). Flux detects the new commit in Git and reconciles your cluster to the updated image. This creates a fully automated image update pipeline: push a new image → Flux detects it → updates Git → Flux applies the updated manifests.

Run 'flux bootstrap github --owner=my-org --repository=my-fleet --branch=main --path=clusters/production' (or the equivalent for GitLab, Bitbucket, or generic Git). Bootstrap installs the Flux controllers into your cluster and creates the initial GitRepository and Kustomization pointing to your fleet repository. All future Flux configuration is managed via Git commits — you never need to run flux bootstrap again unless you're setting up a new cluster. Use 'flux check' to verify all controllers are healthy.