Guide
GitOps tools: 8 options for Kubernetes delivery, compared
By Muhammad Soliman, Founder at SeaGit · Verified September 2026 ·
GitOps tools reconcile what runs in a Kubernetes cluster against what a Git repository says should run, replacing manual kubectl and ad hoc CI deploy scripts with a declarative, auditable source of truth. Argo CD and Flux CD are the two CNCF-graduated controllers that do this reconciliation, both open source under Apache 2.0, differing mainly in shape: Argo CD ships a web UI for diffing and syncing, Flux is a set of composable controllers with no UI of its own, which is why GitLab built its GitOps integration on Flux rather than a UI-first tool. Neither provisions the cluster, ingress, DNS or certificates underneath it, and neither handles multi-stage promotion between environments, which is the gap Kargo, built by the Argo CD maintainers, targets. Jenkins X and Rancher Fleet take different shapes again: Jenkins X couples GitOps to its own CI pipelines, Fleet targets GitOps across large fleets of clusters from Rancher. Codefresh sells a commercial Argo CD-based product, now under Octopus Deploy after its 2024 acquisition.
Each entry states what it actually reconciles, what it assumes already exists underneath it, and its licence and CNCF status where one applies — the details that decide whether a tool fits next to what you already run.
Key takeaways
- GitOps means the cluster state is declared in Git and a controller keeps the cluster matching it. Argo CD and Flux are the two projects most teams compare.
- Argo CD is a single controller with a web UI and an Application resource. Flux is a set of controllers, each with its own custom resources, and it has no bundled UI.
- Both tools reconcile on an interval and on Git events. Both can prune resources that were removed from Git, which is useful and also the most common way to delete something by accident.
- Promotion between environments is a Git operation: a pull request that changes an image tag or a values file. Kargo and similar tools automate that step.
- GitOps does not manage secrets, database migrations or cloud resources by itself. Plan those separately before you adopt it.
At a glance
| Tool | Best for | Pricing model |
|---|---|---|
| Argo CD | Teams that want the most widely adopted, CNCF-graduated GitOps controller, with a strong UI and an ecosystem (Argo Rollouts, Argo Events, Kargo) to build on top of. | Free and open source (Apache 2.0, CNCF Graduated). Akuity and others sell hosted, managed commercial offerings on top of it. |
| Flux CD | Teams that want a lightweight, API-first GitOps toolkit that integrates into existing CI/CD or platform tooling rather than a standalone dashboard product — this is what GitLab’s built-in GitOps integration runs on. | Free and open source (Apache 2.0, CNCF Graduated). |
| Jenkins X | Teams that specifically want CI and GitOps CD unified in one Kubernetes-native platform instead of assembling separate tools. | Free and open source. No vendor sells a supported commercial tier the way Codefresh or Akuity do for Argo. |
| Rancher Fleet | Teams already on Rancher, or specifically needing GitOps deployment across a very large fleet of clusters managed from a single place. | Free and open source (Apache 2.0). Rancher has a free community edition and SUSE-sold enterprise support. |
| SeaGit | Teams that want a managed Argo CD instance and the EKS cluster underneath it provisioned together, instead of standing up EKS separately and then installing and operating Argo CD by hand. | Flat per-seat platform fee with a free plan; your AWS account is billed directly for compute, with no infrastructure markup. |
| Kargo | Teams already running Argo CD who want a purpose-built tool for what happens after Git changes, instead of scripting stage-to-stage promotion in CI. | Free and open source (Apache 2.0). Akuity also offers it as part of its managed Akuity Platform. |
| Codefresh | Teams that want a supported, commercial GitOps product with a promotion and pipeline UI built on Argo CD, rather than running open-source Argo CD themselves. | Commercial SaaS with tiered plans, published on Octopus’s pricing pages; no longer an independent company. |
| GitLab built-in GitOps | Teams already standardized on GitLab who want GitOps without adding a second platform or login for deployment. | Included in GitLab Free, Premium and Ultimate (GitLab.com, self-managed or Dedicated); no separate charge for the GitOps integration itself. |
1. Argo CD
A Kubernetes-native GitOps continuous-delivery controller that continuously reconciles cluster state to match a Git repository, with a web UI for diffing, syncing and visualizing application state. Part of the Argo project, CNCF Graduated since December 2022.
- Not for you if
- Reconciles what should run; it does not provision the cluster, ingress, DNS or certificates underneath it, and multi-stage promotion (dev to staging to prod) needs a separate tool such as Kargo or a hand-built Application-of-Applications setup.
2. Flux CD
A set of Kubernetes controllers — the GitOps Toolkit: source, kustomize, helm, notification — that reconcile cluster state from Git, OCI or Helm repositories. CNCF Graduated since November 2022. No built-in web UI.
- Not for you if
- No first-party dashboard: Weave GitOps used to provide one, but Weaveworks shut down in February 2024 and its commercial products are discontinued. Flux itself, donated to the CNCF in 2019, is unaffected and continues to be maintained independently of Weaveworks — but anyone wanting a Flux UI today needs a third-party one or the CLI.
3. Jenkins X
A Kubernetes-native CI/CD platform using Tekton pipelines, automatic preview environments per pull request, and a GitOps promotion model for deployments — a cloud-native reinvention of Jenkins, not classic Jenkins running on Kubernetes.
- Not for you if
- Spread across many smaller repositories under the jenkins-x GitHub organization with uneven activity between them — check the specific components you would depend on before committing a production pipeline to it, rather than assuming Argo CD- or Flux-level momentum.
4. Rancher Fleet
A GitOps engine built into Rancher (SUSE) for deploying raw Kubernetes YAML, Helm charts or Kustomize overlays from Git — everything is converted into Helm charts under the hood and applied to potentially thousands of clusters from one control plane.
- Not for you if
- Most valuable as part of the Rancher multi-cluster stack — running Fleet standalone, outside Rancher, is less common and less documented than adopting Argo CD or Flux directly.
5. SeaGit
Provisions Amazon EKS clusters inside the customer’s own AWS account and installs Argo CD as a one-click add-on alongside Argo CI, Prometheus, MinIO, cert-manager and external-dns, so GitOps CD is running on infrastructure the customer owns from day one, with ephemeral preview deployments per branch.
- Not for you if
- SeaGit provisions AWS (Amazon EKS) today; Azure and GCP are on the roadmap, not available now. It manages Argo CD as an add-on rather than building its own reconciliation engine, so it is not a Kargo-style promotion layer.
6. Kargo
An open-source promotion layer, built by the Argo CD maintainers at Akuity, that detects new artifacts or configuration changes and promotes them through a defined sequence of stages — dev, test, prod — with policy and approvals.
- Not for you if
- A newer project, created in late 2023, that sits alongside Argo CD rather than replacing it — you still need Argo CD or another reconciler underneath. It is not currently a CNCF project, so its governance sits with Akuity rather than a foundation.
7. Codefresh
A GitOps CD and CI platform built around Argo CD by a team of long-standing Argo maintainers, now operated by Octopus Deploy after Octopus acquired Codefresh in February 2024.
- Not for you if
- A paid, hosted product now on a different company’s roadmap since the acquisition — check Octopus’s current Codefresh plans and direction directly rather than assuming continuity with the pre-acquisition product.
8. GitLab built-in GitOps
GitLab integrates Flux, via the GitLab agent for Kubernetes, so a GitLab project can drive GitOps reconciliation with Flux as the underlying engine, alongside GitLab CI/CD for the build side.
- Not for you if
- The engine is Flux under the hood, not a GitLab-native reconciler, so it inherits Flux’s lack of a built-in dashboard, and it requires the GitLab agent plus the relevant tier’s features to use.
Vendor descriptions and pricing models were checked against each vendor's public site as of September 2026. Prices and limits change; the links above go to the current pages.
What GitOps means in practice
GitOps is a way of operating software where the desired state of a system lives in a Git repository, and an automated agent makes the running system match that state. The OpenGitOps working group describes four principles: the system is described declaratively, the desired state is versioned and immutable, approved changes are pulled automatically by the system, and software agents continuously reconcile the actual state with the desired state. Those four properties are what separate GitOps from a CI job that runs kubectl apply at the end of a pipeline.
The practical difference shows up when something changes outside Git. A pipeline pushes a change once and then forgets the cluster. A reconciling controller notices that a Deployment was edited by hand, or that a pod was deleted, and restores what the repository says. Drift does not disappear, but it is reported and corrected on a timer rather than discovered during an incident.
How Argo CD and Flux describe a deployment
Argo CD describes one deployment as an Application resource. The Application points at a repository, a path and a revision, and at a destination cluster and namespace. The syncPolicy block decides whether the controller applies changes on its own. The example below is the minimal form. Check the field names against the Application specification reference before you copy it into a cluster.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: web
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/example-org/deploy-config
targetRevision: main
path: apps/web/overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: web
syncPolicy:
automated:
prune: true
selfHeal: trueFlux expresses the same idea with a source object and a Kustomization object. The GitRepository (or an OCI or Helm source) tells Flux where to fetch from. The Kustomization tells the kustomize-controller which path to build and apply, and how often. Flux has no bundled dashboard, so teams usually read status with the flux CLI or with the object conditions in kubectl.
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: web
namespace: flux-system
spec:
interval: 10m
path: ./apps/web/overlays/prod
prune: true
targetNamespace: web
sourceRef:
kind: GitRepository
name: deploy-configBoth files do the same job. The choice usually comes down to whether the team wants a UI with application-level views (Argo CD) or a set of composable controllers that fit into an existing Kustomize or Helm workflow with no extra console (Flux). Neither choice is wrong.
How changes move from staging to production
The usual repository layout keeps one base of manifests and one overlay per environment. A change to staging is a commit to the staging overlay. Promotion is a pull request that copies the same image tag or chart version into the production overlay. The reviewer sees exactly what changes in production, and the history of the production branch shows who approved each step.
Kargo models this as a pipeline of stages. It watches for new image versions, promotes them through stages in order, and can run verification between steps. Argo CD and Flux do not decide promotion order on their own. They apply whatever revision they are pointed at. If the team has no promotion tool, the same flow works with pull requests and a required review on the production path.
Image tags need care. A mutable tag such as latest breaks the rule that the repository describes exactly what runs, because the same commit can deploy different bytes on different days. Pin an immutable tag or a digest in the overlay, and let a bot or the CI pipeline open the promotion pull request.
What GitOps does not cover
Secrets are the first gap. Git history is permanent, so a plaintext secret in a repository has to be treated as leaked and rotated. The Flux documentation covers two common answers, SOPS and Sealed Secrets, which encrypt the value before it is committed. External Secrets Operator and similar tools keep the value in a cloud secret store and sync it into the cluster. Pick one before the first production deployment, not after.
Database migrations are the second gap. A reconciler can roll out a new image in seconds, but a migration that drops a column must run before the old code stops needing it. Keep migrations in the application pipeline, run them as a Kubernetes Job or a pre-sync hook, and make the rollback path explicit. Argo CD supports sync hooks for this. Flux supports dependsOn ordering between Kustomizations.
Cloud resources are the third gap. A GitOps controller reconciles Kubernetes objects. A load balancer, a DNS record or a managed database created by Terraform is outside its view unless a Crossplane-style controller or a separate Terraform pipeline manages it. Keep infrastructure and application delivery as two pipelines with two owners.
How to choose among these tools
Start from the team, not the feature list. If the people who deploy are application developers who want to see sync status, logs and history in one place, Argo CD’s UI is a direct fit. If the platform team wants controllers it can compose with Helm and Kustomize, and does not need a console, Flux fits. If the organisation already uses a CI server with a strong promotion model, Jenkins X and GitLab’s built-in GitOps are worth a look, though each brings its own CI system with it.
Check three things before you commit. First, whether your manifests are plain YAML, Kustomize or Helm, because each tool handles them differently. Second, how many clusters you run, since Argo CD can manage many clusters from one control plane and Flux is usually installed per cluster. Third, who will be paged when the controller itself fails, because a GitOps stack that is down stops every deployment.
Do not adopt a second controller on top of the first. Argo CD and Flux both want to own the same objects, and two reconcilers fighting over one Deployment produce a loop that looks like a flaky cluster. Choose one per cluster.
Where SeaGit fits
SeaGit provisions Amazon EKS clusters in your own AWS account, and installs Argo CD as part of setting up the cluster. Deployments run as slots on an instance, with a main slot for production and ephemeral slots for previews. That covers the push-to-deploy part of this list without a second tool to install.
The limits matter. SeaGit supports AWS and Amazon EKS only today. If your cluster runs on Azure or GCP, or you need to bring your own GitOps repository layout and controller configuration, use Argo CD or Flux directly on that cluster. The Argo CD and Flux options in this guide work without SeaGit.
Sources
Checked as of October 2026.
- OpenGitOps: GitOps Principles v1.0.0 — the four principles used in the first section
- Argo CD: Application Specification Reference — field names in the Argo CD Application example
- Flux: Kustomization (kustomize.toolkit.fluxcd.io/v1) — field names in the Flux Kustomization example
- Flux: Concepts — source and reconciliation model, and the SOPS and Sealed Secrets guides
Read next
Frequently asked
What are the alternatives to Argo CD?
- Flux CD is the closest equivalent — another CNCF-graduated reconciler, just without a built-in UI. Jenkins X and Rancher Fleet solve adjacent but different problems (unified CI+CD, and multi-cluster fleets). Codefresh and GitLab’s built-in GitOps are commercial or platform-integrated options built on Argo CD and Flux respectively, rather than independent alternatives to them.
Argo CD vs Jenkins: what is the difference?
- Classic Jenkins is a general-purpose CI server that runs build and test pipelines; it has no native concept of continuously reconciling a Kubernetes cluster against Git. Argo CD does exactly that reconciliation and nothing else. Jenkins X is a separate, Kubernetes-native project that combines Tekton-based CI with a GitOps promotion model — closer to what Argo CD plus a CI tool does together than to classic Jenkins.
Is GitOps the same as DevOps?
- No. DevOps is a set of practices and culture around shipping software faster and more reliably. GitOps is one specific technique within that: using Git as the single source of truth for what should be running, reconciled automatically by a controller such as Argo CD or Flux. You can practice DevOps without GitOps, and GitOps is most valuable as part of a broader DevOps practice, not a replacement for one.
What is a GitOps workflow?
- A commit or merge to a Git repository — application manifests, Helm values, or Kustomize overlays — triggers a controller (Argo CD or Flux) to detect the change and reconcile the cluster to match it, rather than a person or CI job running kubectl or helm upgrade directly. Multi-stage workflows add a promotion step, handled by tools like Kargo, that moves a validated change from one environment to the next.
How do I install Argo CD?
- The official path is applying Argo CD’s installation manifests to a Kubernetes cluster with kubectl, or installing its Helm chart, then accessing the UI via port-forward or an ingress you configure yourself — the project’s own getting-started docs cover both. Platforms that provision the cluster and the add-on together, including SeaGit, install Argo CD as part of setting up the cluster instead of as a separate manual step.