Argo CD vs Harness for Kubernetes Deployments: Policy Controls, Licensing Economics and Multi-Cluster Support in 2026

Key points:

• Harness GitOps is built on Argo CD. Harness documents Argo CD as its only GitOps reconciler and does not support Flux. Choosing between them is choosing what sits on top of the same engine: your own assembly of add-ons, or Harness's commercial control plane.
• Policy controls: Argo CD gives you per-instance RBAC (Casbin policies, SSO groups), AppProjects and sync windows, and you add Kyverno or OPA Gatekeeper for admission policy. Harness adds OPA Policy as Code on GitOps Applications, approvals, freeze windows, account/org/project RBAC and a 2-year audit trail. However, Harness GitOps policies do not apply to Argo CD auto-syncs.
• Licensing economics: Argo CD is Apache 2.0 and costs nothing to license; you pay in engineering time, with four minor releases a year and patches for only the three most recent. Harness CD does not publish paid prices. It licenses by active service, consuming 1 service license per 20 service instances at the 95th percentile over 30 days, so replica counts drive the bill.
• Multi-cluster: Argo CD pushes from a hub that needs network access to each cluster's API server, or you run one instance per cluster. The pull-based argocd-agent is still on 0.x releases (v0.11.0, 11 November 2026). Harness GitOps Agents connect outbound over HTTPS, and one agent can reach several clusters.
• Qovery is a third option when the goal is self-service deployment across clouds without assembling or buying a GitOps governance layer. It runs in your own cloud account or existing clusters, and its Argo CD integration can bring the Argo CD instances you already run into one view, read-only.

Most "Argo CD vs Harness" comparisons treat them as rival engines. Harness GitOps runs Argo CD, so you are comparing two ways to govern the same reconciler: build the governance yourself on open source, or pay Harness for it.

I talk with platform teams about this choice regularly, and the decision almost never turns on sync performance. It turns on three things: who can deploy what and under which policy, what the bill looks like in year two, and how the setup behaves when you go from 3 clusters to 30. Those are the three axes of this article, each backed by the vendors' own documentation as of November 2026.

We covered the GitOps governance problem more broadly in GitOps at scale: sync policies, RBAC and audit trails across clusters. This piece goes deeper on the head-to-head, especially the licensing math, which is where most evaluations stay vague.

Argo CD or Harness: what is the short answer?

Pick Argo CD if you have platform engineers who will own RBAC, admission policies, audit plumbing and quarterly upgrades, and you want zero license cost and full control. Pick Harness if you would rather buy approvals, OPA policy evaluation, freeze windows and a central audit trail across teams, and can live with service-based licensing and a sales-led price.

Pick neither, and look at a platform like Qovery, if what your developers need is self-service deployment into your own cloud accounts, and GitOps governance was a means to that end rather than the goal.

How are Argo CD and Harness actually related?

Harness GitOps is a commercial control plane over Argo CD. The Harness GitOps FAQ says it plainly: "Harness GitOps supports Argo CD as the only GitOps reconciler", and Flux is not supported.

The architecture follows from that:

• A Harness GitOps Agent runs in your cluster and either installs Argo CD components or connects to an existing Argo CD, which Harness calls "Bring Your Own Argo CD" (agent installation docs).
• The agent connects out. It needs outbound HTTPS to app.harness.io, so your clusters do not have to expose their API servers to a central hub.
• Harness lags upstream by design. It supports "n to n-2" minor versions of Argo CD, and the docs list GitOps Agent 0.129.0 to 0.130.0 as supporting Argo CD 2.8.2 through 3.5.6. Upstream Argo CD v3.6.0 shipped on 3 November 2026.

Argo CD itself is a CNCF graduated project with about 24,600 GitHub stars and an Apache 2.0 license (checked on the GitHub repository on 14 November 2026). Harness leaves reconciliation as it is and changes who decides, who approves, who records it, and who pays.

Which gives better policy controls, Argo CD or Harness?

Harness gives you more policy controls out of the box: OPA policies on GitOps Applications and pipelines, approval steps, freeze windows and a central audit trail. Argo CD gives you solid primitives (RBAC, AppProjects, sync windows) and expects you to add admission control and approvals yourself. The gap is narrower than vendor pages suggest, because Harness's GitOps policies do not cover Argo CD auto-syncs.

What does Argo CD give you for policy?

Argo CD ships four policy primitives:

• RBAC. Casbin policies in the argocd-rbac-cm ConfigMap, in the form p, <subject>, <resource>, <action>, <object>, <effect>, with two built-in roles, role:readonly and role:admin, and SSO groups mapped with g lines (RBAC docs). Application permissions go down to resource level, for example update/*/Pod/*/*.
• AppProjects. Restrict which repositories an app may deploy from, which clusters and namespaces it may deploy to, and which cluster-scoped resources it may create (Projects docs).
• Sync windows. allow and deny windows on a cron schedule, scoped by application, namespace or cluster, defined in the AppProject (sync windows docs).
• Git itself. Branch protection and required reviews are your approval gate.

Here is an AppProject for a payments team that can only deploy from its own repository to its own namespaces, cannot create cluster-scoped resources, and cannot auto-sync production on Friday evenings:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: payments
  namespace: argocd
spec:
  sourceRepos:
  - https://github.com/acme/payments-deploy.git
  destinations:
  - server: https://prod-eu.k8s.acme.internal
    namespace: payments-*
  clusterResourceWhitelist: []        # no cluster-scoped resources
  syncWindows:
  - kind: deny
    schedule: "0 16 * * 5"
    duration: 64h
    timeZone: "Europe/Paris"
    applications: ["*"]
    manualSync: true                  # humans can still sync in an incident
  roles:
  - name: deployers
    policies:
    - p, proj:payments:deployers, applications, sync, payments/*, allow
    groups:
    - acme:payments-oncall

What is missing is content policy. Argo CD will happily sync a Deployment running as root or pulling :latest. That is the job of an admission controller such as Kyverno or OPA Gatekeeper, which you install, write policies for and upgrade on every cluster. We compared those two in where deployment policy belongs: OPA Gatekeeper, Kyverno or the platform layer.

RBAC is also per instance. Ten Argo CD instances means ten argocd-rbac-cm ConfigMaps to keep consistent, usually through a GitOps repository that manages Argo CD itself.

What does Harness add on top?

Harness adds a governance layer that Argo CD does not have:

• OPA Policy as Code for GitOps Applications. Policies of entity type "GitOps Application" are evaluated "On Save" and "On Sync", against an input document that carries the Argo CD Application (Harness docs). The same engine governs pipelines (Policy as Code overview).
• Hierarchical RBAC. Principals, resource groups and roles bound at account, organization or project scope, inherited downward. The model is strictly additive: Harness states there is "no explicit deny" (Harness access control).
• Approvals and freezes. Manual and ticket-based approval steps in pipelines, and deployment freeze windows at account, org or project scope.
• Audit trail. Built in, retained for 2 years, with streaming to external storage for longer retention (Harness audit trail).

Here is an "On Save" policy, adapted from the patterns in Harness's samples, that blocks GitOps Applications targeting system namespaces and refuses Argo CD auto-sync (the next section explains why):

package gitopsApplication

blocked_namespaces := ["kube-system", "kube-public", "default", "argocd"]

deny[msg] {
  ns := input.gitopsApplication.app.spec.destination.namespace
  blocked_namespaces[_] == ns
  msg := sprintf("Application '%s' targets protected namespace '%s'", [input.gitopsApplication.name, ns])
}

deny[msg] {
  input.gitopsApplication.app.spec.syncPolicy.automated
  msg := sprintf("Application '%s' enables auto-sync; syncs must go through Harness so policies apply", [input.gitopsApplication.name])
}

Where does Harness policy stop?

Harness policy stops at Argo CD's own reconciliation loop. Harness's docs state that "OPA policies do not apply to auto-syncs" and are "evaluated only when a sync is initiated through the Harness UI or API". Syncs triggered from the Argo CD CLI are not evaluated either. Harness's own workaround is an On Save policy that denies applications with auto-sync enabled, which is the second rule above.

Two more boundaries worth knowing before you sign:

• Freeze windows are a CD pipeline feature. The freeze docs say deployment freeze "does not apply to Harness GitOps PR pipelines".
• Neither tool replaces admission control. Harness evaluates the Application definition, not every Pod spec rendered from a Helm chart. If you need "no privileged containers" enforced at the cluster, you still run Kyverno or Gatekeeper.

If you stay on Argo CD, the missing piece is usually the approval record. Our post on audit trails and RBAC across multi-cluster Argo CD shows how to join Git reviews, Argo CD events and API server audit logs into one trail.

What do Argo CD and Harness really cost?

Argo CD costs $0 in licenses and an ongoing slice of a platform team. Harness costs a negotiated license that scales with active services and their replica counts, and a much smaller slice of a platform team. Which one is cheaper depends almost entirely on how many services you run, how many replicas each one has, and what an engineer-week costs you.

How is Harness CD licensed?

Harness CD is licensed by service, not by cluster or seat. From the Harness CD service licensing docs:

• "Harness CD consumes 1 service license for every 20 service instances of a service" for containerized and VM workloads. A service with 5 instances uses 1 license; a service with 25 instances uses 2.
• Instances are sampled every 60 minutes and measured at the 95th percentile over 30 days, so a load test or a blue-green cutover does not spike your count, but steady autoscaling does.
• Only active services count: those deployed in the last 30 days.
• Serverless: 1 license per 5 functions. Pipeline executions with no service: 1 license per 2,000 executions.
• GitOps applications linked to a Harness Service count through that Service (behind the CDS_GITOPS_SERVICE_BASED_LICENSING feature flag); applications not linked to a service use application-based counting.

Harness also sells a developer-based model. Under "Developer 360", CD includes "1 Service for every 3 Developers", with more services bought as add-ons (Harness subscriptions).

On the pricing page, both paid plans route to sales and show no price. The Continuous Delivery and GitOps limits that are public: Essentials allows up to 60 concurrent pipeline executions and up to 5 deployment templates; Enterprise allows up to 500 concurrent executions. Both include GitOps and freeze windows.

A worked example, using only the documented rules. Take 40 microservices, each running on average 6 replicas in production, 2 in staging and 2 in dev, all deployed weekly:

• If instances are counted per service across environments, each service sits at 10 instances, which means 40 service licenses.
• Turn on autoscaling that holds production at 18 replicas most of the month, and each service sits at 22 instances at the 95th percentile, which means 80 service licenses. The code and the team stay the same, and the license units double.

Model this before signing, because Harness cost tracks your runtime footprint. Ask your account team how instances across environments are aggregated for your contract, and model your 95th-percentile replica counts, not your averages.

What does free Argo CD actually cost to run?

Argo CD's cost is operational. Three items dominate:

• Upgrades. A minor release "occurs four times a year, once every three months", and "only the three most recent minor versions are eligible for patch releases" (release process). Skip three quarters and you are on an unpatched version.
• Scaling. Past a certain number of clusters, the application controller needs sharding across replicas with ARGOCD_CONTROLLER_REPLICAS and a sharding method (high availability docs).
• The add-ons. Kyverno or Gatekeeper, SSO, notifications, audit log shipping and the approval record are each a project with its own upgrades.

If you want Argo CD without operating it, there is a published reference price. Akuity, founded by Argo's creators, lists its Pro plan "starting at $495/month" with one Argo CD instance and 50 Argo CD applications included, then $99 a month per extra 10 applications, up to 1,500 applications. That is a useful benchmark for what the hosting part of Argo CD is worth, separate from governance.

Which handles multi-cluster Kubernetes better?

Harness has the simpler network model for many clusters: agents connect outbound, and one Harness account gives you one RBAC and audit layer across all of them. Argo CD can run very large fleets, but you choose between a central hub that must reach every API server and one instance per cluster with N copies of RBAC, unless you adopt the newer agent-based model.

How does Argo CD do multi-cluster?

There are three patterns, each with a cost:

• Hub and spoke (push). One Argo CD registers remote clusters as Secrets labelled argocd.argoproj.io/secret-type: cluster (declarative setup) and pushes to them. One RBAC config, one UI, but the hub needs network access and credentials to every API server, and it becomes a single high-value target.
• Instance per cluster. Each cluster runs its own Argo CD and pulls from Git. No inbound access needed, but RBAC, SSO, notifications and upgrades multiply by the number of clusters.
• argocd-agent (pull, hub-managed). The argocd-agent project splits Argo CD into a principal on the hub and agents on workload clusters, so spokes connect out to the hub. It is still under argoproj-labs and on 0.x releases, with v0.11.0 published on 11 November 2026. It is worth piloting, but plan for change.

ApplicationSets with the cluster generator template the same app across clusters, which solves config sprawl but not RBAC or audit sprawl.

How does Harness do multi-cluster?

Harness puts a GitOps Agent near your clusters. The docs say you typically install it in the target cluster, but "you can install it in any cluster, and it can connect to remote clusters using the credentials you provide". Agents connect outbound, multiple agents provide high availability, and everything rolls up into one Harness account with account, org and project RBAC. One constraint from the FAQ: "All applications within an Argo CD ApplicationSet must be managed by the same agent."

The trade-off is that Harness becomes the control plane. Your clusters reconcile through Argo CD either way, but who-can-do-what lives in Harness.

How does Qovery do multi-cluster?

Qovery manages clusters on AWS, GCP, Azure and Scaleway, or connects clusters you already run (EKS, GKE, AKS, k3s, on-premise) through qovery cluster install. The Qovery control plane is separate from your data plane: workloads run in your own accounts, and one RBAC model covers every cluster. Custom roles scope access per project and per environment type (Development, Preview, Staging, Production), and per cluster. Cross-cloud networking between clusters is not built in; it is configurable with a VPN, Cilium Cluster Mesh or Tailscale.

Where does Qovery fit as a third option?

Qovery fits when the outcome you want is developers and agents deploying safely to many clusters in your own cloud accounts, and neither assembling Argo CD governance nor buying it from Harness is how you want to get there. It does not fit if your organization has standardized on Git-only GitOps for every change; keep Argo CD then.

Qovery is an Agentic DevOps platform. It does not host your applications: they run on Kubernetes in your AWS, GCP, Azure or Scaleway account, or on clusters you already run. What it brings to this comparison:

• Policy for humans and agents. Built-in roles (Owner, Admin, DevOps, Billing Manager, Viewer) plus custom roles per project and environment type. For AI agents, an API Policy Token attaches an Open Policy Agent (Rego) policy evaluated on every request, before it reaches the endpoint, and logs the agent as policy:<token-id>:<token-name>. The feature is in preview and its input contract may change. The background is in our OPA permissions post.
• Unifying Argo CD instances you already run. The Argo CD integration maps each Argo CD instance to a Qovery cluster. Argo CD applications appear as Qovery environments organized by namespace, with pod status, shell, logs, sync and health status, and a manifest diff. Deployment ownership stays in Argo CD, and those applications are read-only in Qovery; sync and rollback actions are listed as planned. For a team with five Argo CD instances and five argocd-rbac-cm files, that is one place to see all of them without migrating anything (announcement).
• Everything else on the same plane: git-push deployments, preview environments per pull request, environment cloning, Helm and Terraform services, a Terraform provider, audit logs, cost visibility and deployment rules.

Qovery is not a drop-in Harness replacement for pipeline-heavy release orchestration with multi-stage approvals and change-ticket integrations, and it is not an admission controller. If your auditors require a ServiceNow approval on every production change, Harness is closer to that out of the box.

For the wider field (Akuity, Codefresh, Flux, GitLab, OpenShift GitOps, Plural), see our guide to Argo CD alternatives and managed GitOps control planes.

Which one should you pick?

Match the tool to who will own governance:

• Pick Argo CD if you have at least one platform engineer who wants to own RBAC, Kyverno or Gatekeeper, notifications and quarterly upgrades, your fleet is reachable from one hub or small enough for an instance per cluster, and license cost is the constraint.
• Pick managed Argo CD (Akuity, for example) if you want Argo CD exactly as it is, without operating the control plane, and you will still build approvals and policy yourself.
• Pick Harness if you need approvals, freeze windows, OPA policy and a 2-year audit trail across many teams now, you are comfortable routing syncs through Harness so policies apply, and you have modelled the service license count at your 95th-percentile replicas.
• Pick Qovery if the goal is self-service deployment to your own cloud accounts across AWS, GCP, Azure or Scaleway without a dedicated platform team, with RBAC per environment type and scoped access for AI agents, and you want your existing Argo CD instances visible in the same place while you decide.

How do I evaluate Qovery from Claude Code or Cursor?

If you want your coding agent to look at your Qovery organization and clusters while you compare, install the Agent Skills and the read-only MCP Server:

curl -fsSL https://skill.qovery.com/install.sh | bash

# MCP Server for Claude Code: OAuth sign-in, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

• The first command installs skills such as qovery-onboard and qovery-deploy. Your agent asks before it creates anything.
• The second opens an OAuth sign-in in your browser. The server can list clusters, environments and deployment status but cannot change them.
• Then ask in plain language, for example: "List my Qovery clusters and the environments on each, and tell me which ones come from Argo CD."

Details on the AI agent quickstart.