What tools and platforms does Flux work with?

Updated

Flux works with the tools you likely already run: GitHub, GitLab, and Bitbucket as Git sources (plus S3-compatible buckets), major container registries with full OCI integration, any CI workflow provider, Kustomize and Helm for configuration, webhooks from GitHub, GitLab, Harbor or custom endpoints, and any Kubernetes distribution. It is a CNCF Graduated project, and its APIs are stable.

The sections below break that down by category so you can check each piece against your own stack.

Git and source providers

Flux reconciles the desired state you keep in Git, so the source layer is the first thing to verify.

  • Git hosting: GitHub, GitLab, and Bitbucket are named as supported Git providers.
  • Object storage as a source: You can use S3-compatible buckets as a source instead of (or alongside) a Git repository.
  • Multiple repositories: Flux supports more than one Git repository, which matters if you separate app config from infrastructure config.

If your organization uses a self-hosted Git server that speaks the same protocols as these providers, the same source mechanisms apply — but confirm against your provider's API compatibility rather than assuming.

Container registries and OCI

Flux handles image automation and OCI artifacts:

  • Registries: It works with all major container registries.
  • OCI: Integration with OCI is described as full, covering OCI artifacts as a delivery format.
  • Image automation: Flux can scan for new container images and patch the image reference back into Git automatically, so a new build becomes a Git commit rather than a manual edit.

This is the mechanism behind "push to Git and Flux does the rest" — you push an image, Flux writes the updated tag or digest to your repository, and reconciliation deploys it.

CI and delivery tooling

Flux is designed to sit alongside CI rather than replace it:

  • CI providers: It integrates with all CI workflow providers. The common pattern is CI builds and tests, then Flux pulls the result into the cluster.
  • Progressive delivery: With Flagger, Flux deploys apps using canaries, feature flags, and A/B rollouts.
  • Configuration tools: Kustomize and Helm are both supported.
  • Webhooks: GitHub, GitLab, Harbor, and custom webhooks can trigger reconciliation.

A practical example: your CI pipeline builds an image and pushes it to a registry; Flux's image automation commits the new tag to Git; Flux reconciles the cluster; Flagger shifts traffic gradually while watching metrics.

Kubernetes and multi-cluster

  • Any Kubernetes: Flux is described as working with any Kubernetes distribution.
  • Multi-tenancy: It uses true Kubernetes RBAC via impersonation, so tenants are isolated with native Kubernetes permissions rather than a Flux-specific model.
  • Multi-cluster: With Cluster API, one cluster can manage apps in the same or other clusters, spin up additional clusters, and manage cluster lifecycle and fleets.

Notifications and observability

  • Notifications: Slack is named, and the webhook support means you can route events to other systems as well.
  • Auditability: Because everything flows through pull requests, your Git history is a sequence of transactions you can recover state from.

How to decide whether it fits

Your situation What to check
Git provider is GitHub, GitLab, or Bitbucket Directly supported
Git provider is something else Verify protocol/API compatibility, or use an S3-compatible bucket as source
Registry is a major public or private registry Supported, including OCI artifacts
You already have CI Flux integrates with CI providers rather than requiring replacement
You use Kustomize or Helm Both supported
You run a non-standard Kubernetes distribution Flux targets any Kubernetes; validate against your distribution's conformance
You need canary or A/B releases Pair Flux with Flagger

The main decision point is not whether Flux supports a given category — it covers the common ones — but whether your specific provider's API matches what Flux expects. For anything outside the named list, test the source or webhook integration in a non-production cluster before committing.