GitOps in Kubernetes: Argo CD vs. Flux for Deploying Cloud Applications

GitOps changes not the deployment command, but the Kubernetes management model. Git becomes the source of truth: it stores the desired state, while a controller in the cluster compares it with the actual state and applies the necessary changes.

CI does not disappear in this model. It still builds the image, runs tests, performs security checks, and publishes the artifact. But instead of having direct access to the production Kubernetes API, CI updates Git: the image tag, Helm values, a Kustomize overlay, or the chart version. The GitOps controller then handles the deployment.

Choosing between Argo CD and Flux is not a question of “which is better,” but a question of operational model:

• Argo CD is often a better fit when teams need a clear release dashboard: application status, differences between Git and the cluster, synchronization, resource errors, and manual control.
  
• Flux is often a better fit when GitOps is embedded into an internal platform: everything is described through the Kubernetes API, CRD, controllers, namespaces, and RBAC.
  
• Argo CD is easier to hand over to product teams and SREs, who need to quickly see the application status.
  
• Flux is better suited to platform automation, where teams receive ready-made templates and management is handled through Git and Kubernetes resources.
  
• In both cases, GitOps will not work without discipline: secrets must not be stored in Git in plaintext, manual changes in the cluster must be reflected back in the repository, and rollback must be defined in advance.

The takeaway is straightforward: choose Argo CD when release visibility for people is important. Choose Flux when GitOps needs to become part of a Kubernetes-native platform. Both tools solve the same problem, but they distribute responsibility among developers, SREs, and the platform team differently.

Why GitOps Becomes Necessary as Kubernetes Grows

Manual kubectl apply, direct deployments from CI, and urgent in-cluster fixes may seem acceptable when there are only a few services, the environments are easy to understand, and the on-call engineer remembers exactly what changed during the night. But as the system grows, this model quickly starts to break down.

Multiple teams, multiple clusters, different Helm values for dev, stage, and production, separate permissions for the production environment, and a recurring question all emerge: where is the source of truth now — in Git, in CI, in the actual state of the cluster, or in the incident chat?

GitOps answers this question decisively: the source of truth is in Git. Kubernetes should no longer be the place where the desired state is assembled manually. It becomes an environment that must match the definition stored in the repository.

Argo CD and Flux solve this problem in different ways. Argo CD structures management around the application and its status: what is synchronized, what has drifted, where the error is, and what needs to be applied. Flux is closer to a platform model: state is described through Kubernetes resources, CRDs, controllers, and in-cluster permissions.

It is worth first examining what GitOps actually changes in Kubernetes deployments, and only then comparing Argo CD and Flux by operational model, permissions, multi-cluster support, Helm/Kustomize, migration, and common mistakes.

What GitOps Changes in Kubernetes Deployments

With the introduction out of the way, the main question is: what exactly changes when a team adopts GitOps? At first glance, it may seem that only the way deployments are started changes. Instead of running kubectl apply directly, a controller applies manifests from a repository. In practice, however, something more important changes: where the decision about the system’s desired state is made.

In the old model, CI could build an image, run tests, and immediately apply changes to Kubernetes. In the GitOps model, CI should no longer manage the production cluster directly. It builds the image, validates it, publishes it to a registry, and updates the desired state definition in Git: the image tag, Helm values, a Kustomize overlay, or the chart version. The GitOps controller then detects the commit, compares the repository with the cluster’s actual state, and brings Kubernetes to the declared state.

In this way, GitOps is not “running YAML from Git,” but continuously reconciling the desired and actual states. Git stores what the system should look like. Kubernetes reflects what it looks like right now. The controller monitors discrepancies and applies changes through a pull model: the cluster retrieves the desired state from Git itself, rather than CI pushing commands into production.

The easiest way to see this is through the release of a SaaS service. CI builds a new image, runs tests, performs security checks, publishes the image to a registry, and updates its version in Git. After the merge, the GitOps controller detects the change, synchronizes the cluster, and shows the status of applying it. If an engineer manually increased the number of replicas overnight or edited values directly in the cluster, that is no longer an “invisible change”: drift appears—a discrepancy between Git and the actual state of Kubernetes.

After adopting GitOps, the boundary of responsibility becomes clearer:

• CI is responsible for building the image, running tests, performing security checks, publishing the artifact, and updating Git.
  
• GitOps CD is responsible for detecting changes, reconciling Git with the cluster, synchronization, application status, and displaying discrepancies.

This separation reduces the need to give CI direct access to the production Kubernetes API. Every lasting change goes through a commit, pull request, review, and version history, rather than disappearing into pipeline logs or an administrator’s manual actions.

The practical value of GitOps lies precisely in this discipline. Environments become more reproducible, the reasons for changes become clearer, and manual hotfixes no longer live separately from infrastructure code. But if a team continues to edit the cluster directly and uses GitOps only as a decorative layer on top of the old process, the model breaks down: Git again stops being the source of truth, and drift becomes constant noise rather than a useful signal.

Once this basic model is clear, you can compare Argo CD and Flux. They solve the same GitOps problem, but they differ in how they present state, distribute responsibility, and fit into day-to-day Kubernetes operations.

Argo CD and Flux: Two Different GitOps Operational Models

Argo CD: the application as the control center

The easiest way to understand Argo CD is through the Application concept. It is not just a configuration object, but an operational entry point for the team: the application, its resources, synchronization status, differences between Git and the cluster, errors during application, and degradation of dependent objects.

A developer or SRE does not need to immediately drill down into dozens of Kubernetes resources to understand why a release did not make it through. The team opens the UI, API, or CLI and sees the application state as a single entity: what has been applied, what differs from Git, which resources need attention, and whether synchronization can be started.

For example, a product team can see that checkout-api is in the OutOfSync state. In Argo CD, it is clear which manifests differ from Git, which resources have already been applied, and where an error occurred. This is useful for organizations where teams take part in releases themselves and want to see the service state without a deep analysis of all internal Kubernetes objects.

In this model, Argo CD lowers the barrier to entry. It helps teams “see the application” and troubleshoot release issues faster.

Flux: GitOps as Part of the Kubernetes Platform

Flux is designed differently. It is closer to the model of Kubernetes as a platform: state is described using CRDs (Custom Resource Definitions), and controllers process Kustomization, HelmRelease, and other resources. CRDs are Kubernetes API extensions for custom resource types.

For a platform team, this approach often feels natural. A release becomes a managed object, just like a Deployment, Ingress, or namespace. Management happens through Git, the Kubernetes API, namespaces, RBAC, and automation, rather than through a separate visual layer around the application.

For example, a platform team defines a service using HelmRelease, sets a standard repository structure, environment rules, and access boundaries. Flux controllers then reconcile the cluster to the desired state, while product teams work with ready-made templates and clear rules.

In this model, Flux is a better fit where GitOps needs to become part of an internal platform. It is less tied to a visual interface and relies more heavily on the Kubernetes-native approach: resources, controllers, permissions, and automation.

To put it simply, Argo CD is more often chosen where clear release visibility for people is important. Flux is more often a good fit where GitOps needs to be embedded in platform automation. But this distinction alone is not enough: the tools also need to be compared against the same criteria—visibility for teams, multiple clusters, access rights, Helm and Kustomize, drift detection, notifications, and maintenance complexity.

Key Differences Between Argo CD and Flux

After comparing the operating models, it is useful to identify the differences across several practical criteria. What matters here is not the feature list itself, but the implications for the team: who can see release status, where permissions are configured, how multiple clusters are supported, and how deeply the tool integrates with the Kubernetes platform.

In short, the differences can be summarized as follows:

This table shows a different center of gravity. Argo CD makes GitOps more visible to users: the application, status, drift, and synchronization are brought together in one place. Flux relies more heavily on the familiar Kubernetes model: resources, controllers, namespaces, RBAC, and automation through Git.

Therefore, the comparison is better understood not as a choice of interface, but as a choice of operating model. First, it is worth identifying who needs to see releases and troubleshoot errors every day. After that, it makes sense to look at permissions, multiple clusters, and Helm/Kustomize support.

Release Visibility

Argo CD is strongest when teams need to quickly understand what is happening with an application. Its interface shows synchronization status, differences between Git and the cluster, resource errors, and the overall health of the application. This is useful for product teams and SREs who need not only to apply manifests, but also to quickly determine why a release has stopped or become OutOfSync.

Flux is less centered on a unified application dashboard. It relies more on the Kubernetes API, resource states, controller events, and integrations. This approach works well in a mature platform model, but it requires the team to have a stronger understanding of Kubernetes objects and controller logic.

Release visibility is directly tied to how access is organized within the organization. If many teams can see the application, one type of governance is needed. If GitOps is operated by a platform team while product teams receive ready-made templates, the model may be different.

Permissions, isolation, and multiple clusters

Argo CD makes it easier to build a centralized access model: projects, roles, SSO, and restrictions by repository, namespace, and cluster. This is useful when an organization wants to give teams a single release dashboard and manage access from one place.

Flux fits more naturally with separation through namespaces, Kubernetes RBAC, and dedicated resources. It is often chosen when each cluster is expected to be more like a self-contained platform unit: it connects to Git, runs its own controllers, and follows shared templates.

For that reason, the question of multiple clusters is not “which tool supports them better,” but “where should control reside?” Argo CD is convenient for a unified overview. Flux is better suited to a model where clusters are more autonomous and GitOps is embedded in the platform as a set of Kubernetes primitives.

After permissions and clusters, there is one more practical layer: how teams already define their applications. If deployment has long been built around Helm and Kustomize, it is important to consider not only support for these tools, but also where the team will look for the release state.

Helm, Kustomize, and Maintenance

Both tools work with Helm and Kustomize, but they represent release ownership differently. In Argo CD, a Helm chart or a Kustomize overlay becomes the source for an Application, and the team sees the result as the application state. In Flux, HelmRelease and Kustomization become separate Kubernetes resources managed by controllers.

The difference becomes clear during ongoing maintenance. Argo CD is easier for users to understand, but it requires maintaining a central control plane: access, projects, SSO, cluster permissions, and synchronization policies. Flux is less visible to product teams, but it requires mature platform operations: controllers, CRDs, bootstrap processes, upgrades, and observability across clusters.

The conclusion is straightforward: Argo CD makes release management more visible and convenient for people. Flux makes GitOps a more natural part of the Kubernetes platform. Therefore, it is better to choose a tool not by its list of features, but by the organizational model: who owns the release, who sees errors, and who manages the platform.

Organizational Scenarios for Choosing Argo CD or Flux

After comparing the feature sets, it is important to map them to the real-world responsibility model. The question is not which tool is “better overall,” but who manages deployments, who sees release errors, and where the boundary lies between the product team, SRE, and the platform team.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

Scenario 1. Product teams monitor releases themselves

If several teams independently track release status, drift between Git and the cluster, resource errors, and manual synchronization, Argo CD is usually more convenient. It provides a clear visual view of the application, its status, drift, apply errors, and the state of dependent objects.

This is especially useful when there are many services and teams have varying levels of Kubernetes expertise. A developer does not need to immediately dig into dozens of low-level resources. They can see that the application is OutOfSync, understand which changes were not applied, and proceed according to the agreed process.

Scenario 2. The platform team builds an internal platform

If deployment needs to be part of a shared platform, and teams are provided with ready-made templates and rules, Flux is the more logical choice. It fits better with a model where everything is described through the Kubernetes API: HelmRelease, Kustomization, namespaces, RBAC, and controllers.

In this setup, the product team may not manage the GitOps tool directly. The platform team defines the repository structure, environment rules, permissions, and standard application delivery methods. Flux becomes part of the platform automation rather than a separate release dashboard.

Scenario 3. Many teams, different permissions, and strict isolation

When there are many teams and namespaces, the key issue is the permissions model. If you need a unified layer for access, visibility, and release management, Argo CD is often more convenient: projects, roles, SSO, allowed repositories, namespaces, and clusters can all be managed within a single framework.

If the organization already implements isolation through Kubernetes RBAC, namespaces, and platform templates, Flux may be the more natural fit. It introduces less of a separate management layer and aligns more closely with the Kubernetes approach to separating responsibilities.

In this scenario, a mistake can quickly become an operational problem. A team either sees too much, cannot make sense of its own release, or gets access to the wrong resources. That is why tool selection should start not with deployment, but with permissions design.

Scenario 4. Multiple clusters and different areas of responsibility

With multiple clusters, it is important to decide where control should reside. A central management layer is useful for overall visibility, auditing, and access management. Argo CD often has an advantage here: it provides a unified view of applications across different clusters.

Flux is often a better fit when each cluster needs to be more autonomous. It can be deployed via bootstrap, connected to Git, and used to maintain a reproducible state without a constant dependency on a central dashboard. This model is useful for platform teams that want to standardize clusters without turning a single management layer into a critical dependency.

Scenario 5. Helm and Kustomize Are Already the Standard

If deployment has long been built around Helm and Kustomize, the comparison should not be about support for these tools, but about the release ownership model. In Argo CD, a chart or overlay becomes the source for an Application, and the team sees the result as the application state.

In Flux, HelmRelease and Kustomization become first-class Kubernetes resources. This is more convenient if the team is used to thinking in terms of resources, controllers, and status within the cluster. The difference matters when an error occurs: the cause will be investigated either in the application UI or in the state of Kubernetes resources and controllers.

The takeaway is this: Argo CD more often comes out ahead where release transparency for people is important. Flux is stronger where GitOps needs to become part of platform automation. But choosing the tool is only half the work. It then needs to be integrated into the existing deployment workflow and gradually move away from manual kubectl and direct deployments from CI.

Migrating from kubectl and CI-Driven Deployment to GitOps

After choosing Argo CD or Flux, it is important not just to install the controller, but to shift the center of change management. If CI previously built the image and ran kubectl apply in the production environment itself, CI should now go only as far as Git: updating the image tag, chart version, values, or overlay. GitOps CD takes over applying the state in Kubernetes.

First, put the desired state in Git

The first step is to gather everything the team already uses: manifests, Helm charts, Kustomize overlays, and values for different environments. Everything that should be considered the desired state must be moved to Git, eliminating dependencies on local files, manual commands, and the “knowledge in the heads” of individual engineers.

At this stage, it is also worth separating environments, namespaces, and team areas of responsibility. Otherwise, the GitOps controller will be in place, but the source of truth will remain blurred: part of the state will be in Git, part in the cluster, part in CI, and part in manual edits.

Next, separate CI from GitOps CD

CI does not go away. It remains an important part of delivery, but it no longer applies changes directly to the production Kubernetes API. It is best to define this separation in the process from the start so the team understands where the build ends and where applying the state begins.

For clarity, we have prepared the following table:

The GitOps controller connects to the selected repositories and environments, detects changes in Git, and synchronizes the cluster. At the start, it is better not to enable full automation right away. A safer approach is to begin with manual synchronization: the team can see the differences, understand the impact, and learn how to read the state in Argo CD or Flux.

Introduce automation gradually

It is better to start the transition with a pilot environment rather than with all production services. A good candidate is a stateless service without complex database migrations. For this service, you can create separate values or overlays for dev, stage, and prod, enable GitOps first for dev, then for stage, and only after validating the process, for production.

In the pilot, it is important to test more than just a successful deployment. You also need to cover failure scenarios:

• A wrong image;
• An invalid manifest;
• A manual change to replicas;
• Drift between Git and the cluster;
• A rollback to the previous version.

These are exactly the kinds of checks that show whether the team is ready to operate in a GitOps model. If everyone only looks at a “green” deployment, problems will surface later: during an incident, a manual hotfix, or a failed release.

Document emergency fixes and rollback in advance

GitOps does not eliminate incidents. Before enabling automatic recovery, teams need to agree on how emergency changes and rollback will be handled.

A manual edit may be acceptable as an exception, but afterward the change must be brought back into Git. Otherwise, the controller will either overwrite the edit or continuously report drift. Rollback should also be documented in advance: through a revert commit, a previous image tag, a chart version, or values.

Migration usually fails not because of Argo CD or Flux, but because of change discipline. If secrets are stored in Git as plain manifests, the cluster continues to be modified manually, and there is no rollback process, GitOps becomes a formal layer on top of the old deployment process. Therefore, the next step is to examine the common mistakes that prevent GitOps from becoming a true source of truth.

Common Mistakes When Moving to GitOps

GitOps exposes the weak points of legacy deployment processes. What used to look like a “quick manual fix” or a peculiarity of a specific CI pipeline becomes persistent drift, a permissions conflict, or a security risk after Argo CD or Flux is introduced.

Critical mistakes should be addressed before enabling full automation:

The most common problem is secrets. A Kubernetes Secret stored as YAML should not be considered secure just because the value is base64-encoded. This is especially dangerous in GitOps: the repository becomes the central control point for environments, and commit history preserves the mistake even after the line is deleted. Secrets should therefore either be moved to an external store or stored in Git only in encrypted form.

The second common problem is manual changes. If an engineer uses kubectl edit to change replicas, adjusts a resource, or manually updates a Helm release, the GitOps controller will detect drift. Two bad scenarios can then follow: the controller overwrites the manual change, or it continuously reports OutOfSync. To avoid this, every persistent change must be committed back to Git.

Rollback also needs to be defined in advance. In GitOps, it often looks simpler: you can revert to a previous commit, image tag, chart version, or values. But this does not solve everything automatically. Database migrations, queues, data, and external dependencies may require a separate plan. Rollback should therefore be part of the release process, not something improvised during an outage.

If these mistakes are addressed before full automation is enabled, the move to GitOps becomes smoother. The team understands where the source of truth resides, how exceptions are handled, who can change production, and what to do if a release fails.

Conclusion

The choice between Argo CD and Flux should start not with installation, but with the operating model. If deployments need to be understandable to product teams, SREs, and developers through application status, diffs, and controlled synchronization, Argo CD is often the more convenient option. If GitOps is intended to become part of an internal platform where everything is described through the Kubernetes API, CRDs, namespaces, and RBAC, it makes more sense to consider Flux.

In both cases, GitOps works only when the process is disciplined: Git remains the source of truth, CI does not apply changes directly to production, manual changes are committed back to the repository, secrets are not stored in plaintext, and rollback is defined in advance. The tool helps maintain the cluster state, but it does not replace rules for ownership of environments, access, and releases.

FAQ

Can Argo CD and Flux be used together?

Yes, but this is rarely needed at the start. Using them together is justified when teams already have different mature practices in place—for example, Argo CD for applications and Flux for platform components. Without clear boundaries, this approach makes maintenance more complex.

Which is easier for development teams to adopt?

Argo CD is usually easier. Its UI, application status, diffs, and synchronization make it quicker to understand what is happening with a release. Flux requires more familiarity with working through Kubernetes resources, the CLI, and the controller model.

Should CI be removed entirely after moving to GitOps?

No. CI remains responsible for builds, tests, security checks, publishing images, and updating manifests or values in Git. What changes is the CD part: applying changes in Kubernetes is handled by the GitOps controller.

How should you perform a rollback in GitOps?

Typically, by reverting the commit, image tag, chart version, or values to a previous state. However, this type of rollback does not automatically roll back database migrations, data, queues, or external dependencies. These require a separate recovery plan.

Why shouldn’t Kubernetes Secrets be stored in Git as-is?

Because base64 in Kubernetes Secrets is not encryption. GitOps requires secure approaches: external secret stores, Sealed Secrets, SOPS, External Secrets Operator, encryption at rest, and strict RBAC.

What should you do if a manual change is made in production after all?

It should be committed to Git as quickly as possible. Otherwise, the controller will either overwrite the change or keep reporting drift. Emergency access should be defined as a separate process rather than left as a standard deployment method.

Sources

1. OpenGitOps — GitOps Principles v1.0.0

2. Argo CD Documentation

3. Flux Documentation

4. Kubernetes Documentation — Good practices for Kubernetes Secrets