<p>The short answer is, GitOps Toolkit is Flux. If you are using Flux then you are using the GitOps Toolkit. Flux is an un-opinionated distribution of the GitOps Toolkit, and I know of no other distributions that do call themselves GitOps Toolkit.</p>
<p>The philosophical answer is a bit deeper, since a GitOps Toolkit is defined here, as a set of components, and somewhat innate in the definition of sets is the idea that they can be updated, or changed:</p>
<p><a href="https://fluxcd.io/flux/components/" rel="nofollow noreferrer">https://fluxcd.io/flux/components/</a></p>
<p>Indeed in Flux itself, in the 6 components that are all definitely part of Flux, 4 are defaulted, and only 3 of those are now considered &quot;generally available&quot; in the sense that they receive the &quot;GA&quot; label on our roadmap, and have left the Beta period of the API. Those GA controllers are the Source Controller, Kustomize Controller, and the Notification Controller. There's also Helm Controller, which will be GA soon, and the Image Automation and Reflector controllers that may go GA some time later on, depending on the roadmap priorities.</p>
<p>The GitOps Toolkit officially contains those 6 APIs. The APIs are defined as Kubernetes CRDs. Any product that depends on bits of Flux's functionality can integrate GitOps Toolkit APIs, and the promise of GA is that those APIs are stable and you can build on them, and expect them to go on working as long as Flux is being developed. Those are Flux's guarantees, but they're also GitOps Toolkit's guarantees as an API, you don't need to integrate or even consider the Flux CLI in order to depend on those guarantees.</p>
<p>Other products can <em>integrate</em>, but can also <strong>implement</strong> &quot;GitOps Toolkit.&quot; One such example is the TF-Controller project, that leverages the Source API to provide Flux's Git capabilities to a Terraform K8s-controller experience. While this isn't strictly speaking a part of Flux's &quot;trademark&quot; GitOps Toolkit, Flux itself is made under the CNCF, and with contributions from many other members of the community, also mainly by engineers at Weaveworks.</p>
<p>TF-controller does not simply consume the Source API and use it to do some work, that's integrating GOTK, and while anyone can do that, it's not the same as implementing GOTK. TF-controller is also a (hopefully) faithful implementation of the principles and patterns of Flux's GitOps Toolkit.</p>
<p>A faithful implementation uses the Controller Runtime, it implements Kubernetes Conditions and Status following the guidance and patterns laid out in the <a href="https://fluxcd.io/flux/gitops-toolkit/source-watcher/" rel="nofollow noreferrer">GOTK developer guides</a>. TF-controller depends on Flux libraries and its authors are working in collaboration with the Flux core team to produce a cohesive experience.</p>
<p>The project roadmap tracks Flux development and it includes a <a href="https://github.com/weaveworks/tf-controller" rel="nofollow noreferrer">roadmap</a> that shows how its development can be expected to progress in line with future plans. While there's no official conformance suite or test to say if your project implements the &quot;GitOps Toolkit,&quot; there's no set of requirements that you must adhere to be considered for membership in the group and so you get invited when we have parties, etc. you know, maybe there should be a conformance guide for GitOps Toolkit as well!</p>
<p>Hopefully this disambiguated the term somewhat so you can understand the difference better.</p>

CC BY-SA 4.0
2023-07-06T16:58:55.363Z
2023-07-06T16:58:55.363Z
Kingdon
<p>What is the difference between Flux and the GitOps Toolkit?</p>
<p>Is Flux v2 simply a distribution of the GitOps Toolkit components (such as the source controller for polling/scraping git repos, the kustomisation controller for syncing cluster resources with manifests, and the helm controller for declarative releases from manifest templates)? Does Flux include anything else in addition to the toolkit components, or in other words, is it possible to use all of the toolkit components and still not be &quot;using flux&quot;? (For example, is the flux CLI just a bootstrap for deploying the toolkit components into a k8s cluster?) Conversely, does the toolkit include anything that is not used in flux?</p>

<kubernetes><continuous-deployment><terminology>
Is there a distinction between Flux and GitOps Toolkit?
benjimin
# Is there a distinction between Flux and GitOps Toolkit?

(Asked by: username_0 on 2023-07-05)

What is the difference between Flux and the GitOps Toolkit?

Is Flux v2 simply a distribution of the GitOps Toolkit components (such as the source controller for polling/scraping git repos, the kustomisation controller for syncing cluster resources with manifests, and the helm controller for declarative releases from manifest templates)? Does Flux include anything else in addition to the toolkit components, or in other words, is it possible to use all of the toolkit components and still not be "using flux"? (For example, is the flux CLI just a bootstrap for deploying the toolkit components into a k8s cluster?) Conversely, does the toolkit include anything that is not used in flux?

**Tags:** kubernetes, continuous-deployment, terminology


---

## 1 answers

### Answer by username_1 on 2023-07-06. Score: 0 | Accepted answer

The short answer is, GitOps Toolkit is Flux. If you are using Flux then you are using the GitOps Toolkit. Flux is an un-opinionated distribution of the GitOps Toolkit, and I know of no other distributions that do call themselves GitOps Toolkit.

The philosophical answer is a bit deeper, since a GitOps Toolkit is defined here, as a set of components, and somewhat innate in the definition of sets is the idea that they can be updated, or changed:

<https://fluxcd.io/flux/components/>

Indeed in Flux itself, in the 6 components that are all definitely part of Flux, 4 are defaulted, and only 3 of those are now considered "generally available" in the sense that they receive the "GA" label on our roadmap, and have left the Beta period of the API. Those GA controllers are the Source Controller, Kustomize Controller, and the Notification Controller. There's also Helm Controller, which will be GA soon, and the Image Automation and Reflector controllers that may go GA some time later on, depending on the roadmap priorities.

The GitOps Toolkit officially contains those 6 APIs. The APIs are defined as Kubernetes CRDs. Any product that depends on bits of Flux's functionality can integrate GitOps Toolkit APIs, and the promise of GA is that those APIs are stable and you can build on them, and expect them to go on working as long as Flux is being developed. Those are Flux's guarantees, but they're also GitOps Toolkit's guarantees as an API, you don't need to integrate or even consider the Flux CLI in order to depend on those guarantees.

Other products can *integrate*, but can also **implement** "GitOps Toolkit." One such example is the TF-Controller project, that leverages the Source API to provide Flux's Git capabilities to a Terraform K8s-controller experience. While this isn't strictly speaking a part of Flux's "trademark" GitOps Toolkit, Flux itself is made under the CNCF, and with contributions from many other members of the community, also mainly by engineers at Weaveworks.

TF-controller does not simply consume the Source API and use it to do some work, that's integrating GOTK, and while anyone can do that, it's not the same as implementing GOTK. TF-controller is also a (hopefully) faithful implementation of the principles and patterns of Flux's GitOps Toolkit.

A faithful implementation uses the Controller Runtime, it implements Kubernetes Conditions and Status following the guidance and patterns laid out in the [GOTK developer guides](https://fluxcd.io/flux/gitops-toolkit/source-watcher/). TF-controller depends on Flux libraries and its authors are working in collaboration with the Flux core team to produce a cohesive experience.

The project roadmap tracks Flux development and it includes a [roadmap](https://github.com/weaveworks/tf-controller) that shows how its development can be expected to progress in line with future plans. While there's no official conformance suite or test to say if your project implements the "GitOps Toolkit," there's no set of requirements that you must adhere to be considered for membership in the group and so you get invited when we have parties, etc. you know, maybe there should be a conformance guide for GitOps Toolkit as well!

Hopefully this disambiguated the term somewhat so you can understand the difference better.


---

