Ring Promoter vs Argo CD, Kargo and CI: Which Tool Answers Which Release Question

Argo CD, Flux, Kargo, Spinnaker, Octopus, Harness and your CI pipeline all appear on the same shortlist when a team says “we need better releases”. They are not interchangeable. Each one answers a different question, and picking the wrong one leaves the hardest question unanswered. This post uses Ring Promoter’s own comparison at ringpromoter.com/compare to separate those questions, sets out the limits honestly, and explains why whichever choice you make should be written down as an Architecture Decision Record (ADR).

Three tools, three questions

The compare page opens with a framing that is worth keeping in your head during any tooling discussion:

• Argo CD and Flux ask: “Does the cluster match the manifests in Git?” They provide sync, drift detection and self-heal per environment. Moving a version from staging to production is left to you: a pull request, an image updater, or another tool such as Kargo.
• CI pipelines (GitHub Actions, Jenkins, GitLab) ask: “Did the deploy job exit 0?” They are good at build and test, but they keep no record of what runs in each environment and do not roll back on their own. A green job can leave the old version answering 200 OK.
• Ring Promoter asks: “Is this exact version healthy here, and is it allowed into the next ring right now?” Promotion is its main concept. It keeps the current version, previous version and full history per app and ring, and stops at the first failure.

Seen this way, most “Argo CD or Ring Promoter?” debates dissolve. If your problem is keeping clusters in line with Git, a sync engine is the answer. If your problem is deciding what is allowed into production and proving it is really running there, you need something that treats promotion as a first-class object.

What actually differs

The compare page lists capabilities that Ring Promoter provides out of the box. The ones that matter most in practice are:

1. Version-verified health checks. Set health_version_field or health_version_header on a ring and every post-deploy health check must report the exact version just deployed. If the old pods are still answering, the check fails and the ring rolls back. The same check confirms the source ring really runs the version being promoted.
2. Gates before anything changes. Maintenance windows, version-specific Go/No-Go sign-off, Jira change-request codes and a Grafana go/no-go are checked before any deploy. A failed gate leaves every ring untouched. Only the Grafana gate can be overridden, and only with a written reason that goes to the job log.
3. Rollback that cannot be cut off. Operations run on a context detached from the HTTP request, so a CI runner timeout or dropped connection cannot abort a deploy or the rollback after it. Postgres advisory locks serialise operations per app across replicas.
4. Kubernetes and VMs in one place. The deployer is chosen per app: kubectl, a Kubernetes Job, or dispatching an existing GitHub Actions workflow for VM apps. The compare page notes that Argo CD, Flux and Kargo deploy only to Kubernetes.
5. Safe production defaults. A separate production password is needed to promote or seed into prod, or to enable auto-promote into it. Rollbacks are exempt so incident response is never blocked, and config cannot switch on auto-promote into prod.
6. One curl for CI. A pipeline calls seed or promote; any non-2xx means the promotion failed, and 422 means it ran, failed and was rolled back.

Kargo is the closest match. The compare page describes it as promotion on top of Argo CD: GitOps-native (it writes to Git) with traffic-level analysis through Argo Rollouts. Its verdict is straightforward: if you are fully committed to Argo CD on Kubernetes, look at Kargo; if you have a mixed estate or no GitOps stack yet, Ring Promoter needs less to run.

Where it is not the better choice

The compare page is explicit about current limits, and any fair evaluation should start from them:

• No SSO or per-user RBAC yet. Access is an API bearer token plus a production password. Teams that need per-user roles and audit by identity should put it behind an auth proxy for now.
• No traffic shifting. A ring is deployed as a whole. For canary or blue/green inside a ring, pair it with Argo Rollouts or Flagger.
• Not GitOps. Ring state lives in Postgres, not Git. You get a clear history per ring, but not drift detection or self-heal.
• Smaller ecosystem. Deployers today are kubectl, Kubernetes Jobs and GitHub Actions. Argo CD and more CI adapters are planned for V2.

All competitor statements here summarise Ring Promoter’s own comparison. Products change quickly, so check each claim against the vendor’s current documentation before you rely on it.

Which one fits

The compare page closes with a short guide, reproduced here as a table:

Your situation	Suggested fit
Versions must move int → prod with proof each step worked	Ring Promoter
Some apps on Kubernetes, some on VMs with existing pipelines	Ring Promoter
Releases need change windows, sign-off and a Jira CR	Ring Promoter (or Harness, if you are buying)
Git must be the only source of truth for cluster state	Argo CD or Flux, with Ring Promoter for promotion
All-in on Argo CD and want promotion as CRDs	Kargo
Percentage-based canary traffic	Argo Rollouts or Flagger, alongside either

Note how often the answer is “both”. Ring Promoter is not positioned as a replacement for CI (“CI produces the version; Ring Promoter moves it”) or for a sync engine. Our earlier posts cover the promotion protocol in Every Release Earns Production and where human gates belong in QA Gates Before Production.

Write the choice down: why an ADR

Release tooling decisions are expensive to reverse and easy to forget. Two years from now someone will ask why prod promotions need a password and a Jira code, or why Argo CD is installed but does not decide what reaches production. An Architecture Decision Record answers that in one page. The widely used format from Michael Nygard has five parts: Title, Status, Context, Decision, Consequences. The record lives in the repository, usually under docs/adr/, and is reviewed in a pull request like code.

For this decision, an ADR is especially useful because the limits above are likely to change. Writing “revisit when SSO lands” into the consequences turns a vague worry into a trigger someone can act on.

A compact example:

# ADR-001: Use Ring Promoter for environment promotion; keep Argo CD for sync

Status: Accepted (2026-10-05)

Context
  We run Kubernetes apps and VM apps deployed by GitHub Actions.
  Argo CD keeps clusters in sync but has no promotion model.
  Releases into acc and prod need a change window, sign-off and a Jira CR.

Decision
  We will promote versions int -> test -> acc -> prod with Ring Promoter.
  Argo CD continues to own cluster sync where it is already in use.

Consequences
  + One record of what runs in every ring; automatic rollback on failed health.
  + VM apps keep their existing workflows as a deployer.
  - No SSO or per-user RBAC: we place it behind our auth proxy.
  - Ring state lives in Postgres, not Git: no drift detection from this tool.
  Revisit when: SSO/RBAC ships, or an Argo CD deployer is available (V2).

The long technical article goes further: the full feature matrix, head-to-heads, three release workflow designs, the failure modes this setup prevents, and three worked ADRs with a decision checklist.

Next steps

1. Read the comparison at ringpromoter.com/compare and check the rows that matter to you against vendor docs.
2. Read the technical deep dive for workflow designs and full ADR examples.
3. See the product at ringpromoter.com or on the Workstation Ring Promoter page.