From commit to production: how Kargo completes the GitOps flow

Most teams that adopt GitOps end up with two-thirds of a delivery pipeline. CI builds and pushes an image. Argo CD reconciles the cluster to whatever is declared in Git. Both halves are solid. But the bit in the middle — moving a change through dev, staging and production, with checks at each step — is almost always a pile of bespoke scripts, manual pull requests, and “just bump the tag in the prod values file.” That’s where Kargo comes in.

The gap: CI and CD, but no PD

It helps to separate three things that often get lumped together:

• CI — build and test the artifact (your image, chart, config).
• CD — make a target environment match the desired state in Git. This is Argo CD’s job, and it does it well.
• PD — progressive delivery: deciding which version goes to which environment, when, and only if it passed verification in the previous one.

GitOps tooling has historically owned CI (your runner of choice) and CD (Argo CD), but left PD as an exercise for the reader. So we wrote promotion scripts. They worked until they didn’t — a hardcoded environment here, a missing rollback path there, no audit trail when someone asks “who promoted this to prod and what did it pass?”

What Kargo actually does

Kargo is a Kubernetes-native controller that orchestrates promotions across stages. Crucially, it doesn’t replace Argo CD — it sits on top of it. Argo CD still does the reconciling; Kargo decides what to feed it. The vocabulary is small:

• Warehouse — subscribes to your sources (container registry, Git repo, Helm chart) and produces a piece of Freight every time something new shows up.
• Freight — an immutable, promotable bundle: this image digest, this Git commit, this chart version, pinned together.
• Stage — an environment (dev, staging, prod). Freight is promoted into stages.
• Promotion — the act of moving Freight into a Stage. It runs declarative steps: update the GitOps repo, then let Argo CD sync.
• Verification — after a promotion, Kargo runs checks (it reuses Argo Rollouts’ AnalysisTemplates), and Freight only becomes eligible for the next stage if those checks pass.

The flow, end to end

1. CI builds and pushes a new image — nothing changes here.
2. The Warehouse notices the new tag and produces Freight.
3. Kargo auto-promotes that Freight to dev: it writes the change into your GitOps repo, Argo CD reconciles, and a verification AnalysisRun confirms the deploy is healthy.
4. Green in dev makes the Freight eligible for staging — promote automatically, or behind a manual approval.
5. Production is usually a gated, one-click promotion of the exact same Freight that already passed every earlier stage.

Git stays the source of truth the whole way. Every promotion is a recorded, reviewable event, and rolling back is just promoting older Freight.

Why I reach for it

For the platforms I build, this closes the loop without reintroducing a black-box CD server. Promotions become declarative and auditable instead of tribal knowledge in a CI script. Verification gates are first-class, not bolted on. And because the same Freight moves stage to stage, “it worked in staging” finally means the identical artifact — not a rebuilt lookalike.

It’s worth being honest about the trade-offs: Kargo is young and still moving fast, it’s another controller to operate, and the value depends entirely on modelling your stages and verification thoughtfully. Garbage stages in, garbage promotions out.

But if you already live in Argo CD and your promotion story is a folder of shell scripts, Kargo is the missing third of the pipeline.

Want help wiring CI, Argo CD and Kargo into a promotion flow your team can actually trust? Get in touch.