Most teams start deploying to Kubernetes the same way: the CI system builds an image, then runs kubectl apply or helm upgrade against the cluster. It works, until the number of apps and clusters grows. This guide explains what changes when an agent inside the cluster, like Flux, pulls the desired state from Git instead, and what trade-offs come with that.

The push model and where it strains

In a push pipeline, the CI job is the only thing that touches the cluster:

1. A commit triggers tests and an image build.
2. The job updates a manifest with the new image tag.
3. The job runs kubectl apply (or helm upgrade) against the cluster.

Three problems show up as you scale:

• Credentials live outside the cluster. Every pipeline needs a kubeconfig or cloud credentials, and that multiplies with each application and each cluster.
• It happens once. After the job finishes, nothing watches the cluster. Someone’s kubectl edit two weeks ago is invisible until it causes an incident.
• There’s no easy answer to “what is deployed?” You have to inspect the cluster itself, because the pipeline’s last run is not a reliable record.

Flip the direction: pull

With a pull model, an agent runs inside the cluster, watches a Git repository, compares what’s declared there with what’s running, and applies the difference. Flux is that agent. It is made of several small controllers, each doing one job:

Controller	What it does
source-controller	Fetches Git repositories, Helm repositories, OCI artifacts, and buckets, and makes them available to the others
kustomize-controller	Builds and applies Kubernetes manifests (plain YAML or Kustomize overlays) from a source
helm-controller	Installs, upgrades, tests, and rolls back Helm releases
notification-controller	Sends alerts (Slack, Teams, and others) and receives webhooks
image-reflector / image-automation controllers	Optional. Scan container registries and commit new image tags back to Git

Developer ─▶ App repo ─▶ CI (test, build) ─▶ Image registry
                            │
                            └─ commits new image tag ─▶ Config repo
                                                            ▲
                                          Flux (in cluster) ┘ pulls, compares, applies
                                                │
                                                ▼
                                            Kubernetes

Cluster credentials never leave the cluster, because the only thing that applies changes is the agent running inside it. Engineers and CI systems only need write access to Git.

The four GitOps principles

The OpenGitOps working group defines GitOps with four principles. Flux implements all of them:

1. Declarative. The system is described in YAML, not scripts.
2. Versioned and immutable. Git is the single source of truth. Every change is a commit that can be audited and reverted.
3. Pulled automatically. Approved changes are fetched by the cluster, not pushed to it.
4. Continuously reconciled. Agents compare desired and actual state and correct drift.

Flux manages itself

A distinctive Flux feature is bootstrap. The flux bootstrap command installs Flux into the cluster and commits Flux’s own manifests to your Git repository, then configures Flux to sync from that same repository. From day zero, even the GitOps tooling is managed through Git. The next guide walks through it.

Keep application code and configuration in separate repositories

The usual recommendation is two repositories: one for application source code, one for Kubernetes configuration (Deployments, Services, HelmReleases, and so on).

Configuration changes on its own schedule. Editing a Service or a ConfigMap shouldn’t trigger a full build-and-test pipeline for code that didn’t change. With two repositories, the CI pipeline’s last step becomes “commit the new image tag to the config repo”, and Flux takes it from there. It also splits ownership cleanly: developers own CI, platform or operations teams own delivery.

Flux gives you two ways to get the new image tag into the config repo:

• CI commits it. A script in the pipeline updates the tag in YAML and pushes. This works with any CI system.
• Flux commits it. The optional image automation controllers watch the registry and push the tag change to Git themselves. See the image automation guide in this series.

Make Git the only way in: drift correction

Flux reconciles on an interval. When the live cluster differs from Git, Flux applies Git’s version again, so a manual change is reverted. This has practical consequences:

• Every change has a commit, an author, and usually a reviewed pull request, which gives you an audit trail.
• Permissions move to Git. Many people can open pull requests; only a few can merge.
• A quick manual kubectl edit in production stops being a silent, lasting change.

Rollback and recovery become Git operations

Because desired state is versioned, going back to a known-good state is a git revert, and Flux converges the cluster to it. The same idea covers recovery. If a cluster is lost, you create a new one, run flux bootstrap against the same repository and path, and the workloads are recreated from Git. Anything that isn’t in Git, such as persistent data or secrets you manage elsewhere, still needs its own backup story.

What Flux doesn’t replace

Flux is a delivery toolkit, not a build tool. You still need CI to test code, build images, and push them to a registry. It is specific to Kubernetes, so other deployment targets need other tooling. And it isn’t the only GitOps controller: Argo CD implements the same principles with a different design, which the comparison guide in this series covers. The rest of this series assumes Flux and starts with installing it. For the full reference, see the official Flux documentation.