What is
Flux CD
?
Most platform initiatives fail the same way: they start too big, get funded like projects instead of products, build for too long without testing with users, and confuse renaming an infrastructure team with building a platform team. Instead, start small, learn fast and scale deliberately.
At a glance
Fact | Value |
|---|---|
Primary use case | Automated GitOps continuous delivery for Kubernetes applications and infrastructure |
Deployment type | Self-hosted on Kubernetes |
Pricing model | Free/open source under Apache 2.0 |
API compatibility | Kubernetes API and RBAC, OCI standards, S3-compatible object storage, webhooks |
Supported integrations | Flagger, Helm, Kustomize, GitHub, GitLab, Bitbucket, Harbor, OCI-compatible container registries, S3-compatible buckets, CI workflow providers, Cluster API, Slack, OPA, Kyverno, Kubernetes admission controllers |
Source type | Open |
Cloud provider | Cloud Agnostic |
Required skills | Kubernetes, Git and pull-request workflows, YAML configuration, Kubernetes RBAC; Helm or Kustomize for supported deployment workflows |
AEP branch | Tooling |
AEP category | Integration & Delivery |
AEP subcategory | CD / GitOps |
Profile
CD / GitOps is the most specific AEP level supplied for Flux CD. Flux is a set of continuous and progressive delivery solutions for Kubernetes, and it automatically reconciles the desired system state declared in Git with the cluster state. Teams describe that desired state in YAML, and Flux synchronizes changes without requiring them to run kubectl for each change.
Flux can manage Kubernetes resources, applications, infrastructure, and dependencies between infrastructure and workloads. It supports multiple Git repositories and clusters, and can use one Kubernetes cluster to manage applications in that cluster or in other clusters.
Focus
Flux is for teams delivering applications and managing infrastructure on Kubernetes. It addresses the work of keeping deployed cluster resources aligned with declared configuration: changes in Git are applied through automatic reconciliation, while pull requests and Git history provide a reviewable record and a way to recover a prior state.
For progressive delivery, Flux works with Flagger to support canary deployments, feature flags, and A/B rollouts.
Background
The supplied project information describes Flux as open and extensible and identifies it as a CNCF Graduated project. Flux 2 source is available in the fluxcd/flux2 GitHub repository. The provided research does not state a founding date or funding history.
Features
Automatic reconciliation
Flux automates Kubernetes continuous delivery by applying declared changes to the cluster. It synchronizes the desired state in Git with the actual state of Kubernetes resources.
Declarative configuration and auditability
Teams can describe system state in YAML and review changes through pull requests. Git history records a sequence of changes and provides a way to recover state from a prior snapshot; Flux applies changes through automatic synchronization.
Progressive delivery
Flux works with Flagger to support canary deployments, feature flags, and A/B rollouts. Flagger provides the progressive delivery capabilities alongside Flux’s application deployment and reconciliation.
Automated image updates
Flux can automate container image updates in Git. Its image automation capabilities scan for images and patch the corresponding Git configuration.
Multi-cluster management and access control
Flux supports managing applications and infrastructure across clusters and multiple Git repositories. It uses Kubernetes RBAC through impersonation, and integrates with policy validation tools such as OPA, Kyverno, and Kubernetes admission controllers.
Integration with existing tools
Flux works with Git providers, container registries, and CI workflow providers. It supports tools and sources including GitHub, GitLab, Bitbucket, OCI, S3-compatible buckets, Helm, and Kustomize.
Pros and cons
Pros
Automatic reconciliation applies the desired state declared in Git to Kubernetes clusters.
Pull-request-based changes and Git history provide an auditable change record and a route to recover an earlier state.
Supports multi-cluster management, multiple Git repositories, and Kubernetes RBAC through impersonation.
Works with Flagger for progressive delivery and supports automated image updates to Git.
Integrates with common Git providers, registries, deployment tooling, CI workflow providers, and policy validation tools.
Cons
The standard GitOps workflow depends on a Git repository as the source of desired state, so teams that do not maintain deployment configuration in Git must adapt their workflow.
Flux is designed for Kubernetes delivery and is self-hosted on Kubernetes, so operating it requires a Kubernetes cluster and ongoing management of its deployment configuration.
Configuration is declarative and YAML-based; teams adopting Flux need to manage YAML configuration and the associated Git and pull-request workflows.
FAQs
Flux CD FAQs
Which tools and platforms does Flux CD integrate with?
Flux CD integrates with Flagger, Helm, Kustomize, GitHub, GitLab, Bitbucket, Harbor, OCI-compatible container registries, S3-compatible buckets, CI workflow providers, Cluster API, Slack, OPA, Kyverno, Kubernetes admission controllers.
How much does Flux CD cost?
Flux CD's pricing model is Free/open source under Apache 2.0.
What skills are required to run Flux CD?
Flux CD requires Kubernetes, Git and pull-request workflows, YAML configuration, Kubernetes RBAC; Helm or Kustomize for supported deployment workflows.
What are Flux CD's main limitations?
Flux CD is designed for Kubernetes delivery and uses a Git repository as the source of desired state, so teams that do not maintain deployment configuration in Git must adapt their workflow. Flux CD is self-hosted on Kubernetes.
How does Flux CD manage access control?
Flux CD uses Kubernetes RBAC through impersonation and supports policy-driven validation with OPA, Kyverno, and Kubernetes admission controllers.
