What Is a Promotion Control Plane? Highlights from the Kargo in Action Live Session
Heba Eid
Kargo is an open-source GitOps continuous promotion tool. It sits above deployment tools such as Argo CD and Terraform and decides how an artifact moves from dev to production once those tools have already synced it into a cluster.
Adoption has grown quickly since its inception a few years ago: the 2026 Argo CD User Survey found Kargo's use as a promotion method rising from 2% of respondents in 2025 to 20% in 2026. With that growth, Manning is working with Kargo's creators to publish Kargo in Action, a deep dive into all things Kargo.
This week, Manning hosted a live session with the authors of Kargo in Action: Ken Cochrane, Head of Engineering at Akuity; Jesse Suen, co-creator of the Argo project and Kargo, and co-founder and CTO at Akuity; and Kent Rancourt, co-creator and project lead for Kargo. Tushar Gupta of Manning hosted the discussion. This post covers the key takeaways from that conversation, and the full session appears below.
The Improvised Promotion Layer Most Teams Already Run
An improvised promotion layer is the ad hoc collection of scripts, jobs, and manual steps a team accumulates to move a change from one environment to the next. Ken opened by saying most teams don't recognize it as a system at all.
It starts small and grows organically, and every piece of it made sense at the time. Viewed as a whole, it is a Rube Goldberg machine: a pile of CI jobs, maybe a spreadsheet, Slack bot, or a pull request, each piece working together to deploy that application. Most teams run some version of this layer. No single system owns it, and no one can point to it on an architecture diagram.
The cause is specific. GitOps answered what should be running in a cluster. GitOps never answered how a change gets from dev to staging to prod, so that logic was scattered across scripts.
Kent Rancourt added: "That improvised promotion layer works," he said, "right up until it doesn't." It works so well for the team that built it that every other team wants it, and each one tweaks it slightly. In the book's running example, twelve versions of the same machine end up running across the company, and someone finds a bug in one.
Why Traditional CI/CD Isn't Enough for Modern Delivery
CI/CD was built to ship an artifact, not to decide where that artifact belongs. The natural place for promotion logic is the pipeline that already builds it, and Jesse Suen called that an understandable choice: the industry says "CI/CD" in one breath, and the automation is already there.
Driving deployments from CI holds up for a handful of pet environments: the small fixed set of dev, staging, and prod a team tends by hand. It breaks when environments multiply, spread across clouds, and belong to microservices on different release cadences. Jesse Suen noted that some teams Akuity works with deploy to hundreds of environments. Others want to promote configuration the way they promote an image tag, which CI was never built to model.
GitOps also changed the timing. A CI-driven deployment used to be immediate: the step finished, the change was live, tests ran. With GitOps,
a commit is eventually consistent, so the pipeline no longer knows when the change is live or when it is safe to test.
CI's job ends when it pushes a new artifact; deciding to deploy that artifact is a separate decision. Sometimes the artifact belongs to a third party, as with a Helm chart the team did not build. Sometimes a release manager controls the timing for reasons unrelated to when the build finished.
Where the Improvised Layer Breaks: Traceability and Audits
Two failure modes came up, and neither is a deployment failure.
Nobody can say where anything is. Ken's version of the question is the one every engineering leader has been asked: where is 1.4.2 right now? Someone wants to know whether a feature shipped, and the honest answer is that it went into a release, but where that release has reached is anyone's guess. Kent Rancourt framed the same problem from the sales side: has the fix customer X asked for reached production, and if not, how close is it?
Audits become archaeology. Ken owns security and compliance at Akuity, so he sits through the audits. Producing evidence for how a ticket traveled from development to production used to mean screenshots of GitHub pull requests and approvals stitched across five or six systems. GitHub gave one clean picture, followed by a black box covering how the change actually reached production.
The usual response to both is to add human gates, and Ken was blunt about where that ends: someone clicking approve without reading anything. "It's false confidence. It's theatre," he said, and it costs time without buying safety.
How Does Kargo Work as a Promotion Control Plane?
A promotion control plane knows the environments as a graph, knows which artifacts exist, knows where each one is, and knows the movement between them. Argo CD and other GitOps tools keep each environment in sync. Kargo decides which environment should be syncing to the next one.
The Audit Trail: Promotion Objects and Immutable Freight
Kargo creates a promotion object in the cluster for every promotion, recording which Freight (its immutable bundle of artifact references) went into which stage, what triggered it, what steps ran, and whether it succeeded. The object is queryable like any other Kubernetes resource, and there is no proprietary audit log to learn from: the evidence is Git and Kubernetes objects.
Freight immutability makes that record meaningful. Freight is pinned to specific artifact versions, so the Freight that reached production is verifiably the Freight that passed through dev and QA. A change produces different Freight rather than quietly altering the old one. Kent Rancourt calls the resulting view mission control: one place that shows what is where.
Governance Controls: Approvals, Policies, and Verification
Kargo puts gates only where they change the outcome and automates the checks that used to be a person's job. The controls the session covered:
Approval steps requiring sign-off from named groups or individuals.
Policies on artifact contents, such as blocking a release carrying critical or high vulnerabilities.
Promotion windows in both directions: freezing changes through Black Friday, or restricting releases to a maintenance window between 1 and 2 a.m. on a weekend.
Verification after every promotion, so Freight has to earn its way forward or stop where it is.
Auto-promotion follows the same qualifications as a human promotion, so it makes sense to auto-promote into dev and tighten stage by stage toward production.
Verification is built largely on Argo Rollouts analysis, whose analysis processes were designed to be reusable outside Rollouts. That enables integrations with systems like Datadog, though platform teams more often define a verification process that runs in a pod and executes arbitrary tests against the live environment. If no verification is defined and the promotion steps include an Argo CD update step, that step registers a health check, so Argo CD Application health becomes the floor.
Conditionals keep approvals meaningful without attaching them to every promotion. The syntax closely mirrors GitHub Actions, and two patterns emerged: skipping approval when the semantic version change is only a patch, and skipping it on an automated rollback, where the goal is to reach a known-good version quickly.
Kargo Promotion Templates for Repeatable Pipelines
Promotion templates define a set of steps once and let stages reference them. Templates compose, and conditionals inside a template handle exceptions such as requiring approval only for prod.
Cluster promotion templates extend that across Kargo projects, letting a platform team centrally enforce a process: image scanning before anything reaches a stage named prod, or running manifests through OPA rules to confirm nobody is requesting privileged pods.
How Do You Coordinate Promotions Across Multiple Services?
Freight handles services that move in lockstep by bundling their artifacts into one box. Multiple warehouses — the subscriptions Kargo keeps to your image, chart, and config repositories — handle the opposite case, carrying independent streams of Freight at their own cadence like several tracks through a series of railway stations.
Ordering falls out of stages being arbitrary promotion targets: for two services that travel together but must deploy in sequence, route the Freight through an A-dev stage, then a B-dev stage.
Kent Rancourt’s read on why this comes up so often was direct: the idea that every service moves through its own pipeline on its own schedule is, pun intended, a bit of a pipe dream.
How Kargo Fits with Argo CD and Other GitOps Tools
Kargo does not replace Argo CD. Argo CD doesn't write to Git, so something has to make the commit it reacts to, and it has no concept of a pipeline that connects applications in deployment order. Before Kargo existed, the Akuity team solved this with Jenkins, and Jesse Suen credited the clunkiness of that arrangement as the origin of the idea.
A rollback is a promotion of older Freight running the same steps, rather than an emergency code path that runs for the first time during an incident. Automated rollbacks build on that by re-promoting the last verified Freight when verification fails.
Kargo vs. Other Promotion Tools
Jesse framed it as: the field is thinner than you would expect, because very few tools treat promotion as their sole job. He sorted the comparisons into three buckets.
Table: How Kargo compares to adjacent tooling
Category | Examples | How Kargo differs |
|---|---|---|
GitOps and promotion tools | GitOps Promoter | Built around your SCM provider and pull requests, modeling environments as branches. Kargo is broader in scope, less opinionated about how you practice GitOps, and focused on integrating with surrounding tools including ServiceNow, Jira, and Terraform. |
Traditional automation platforms | GitHub Actions, Jenkins, commercial deployment vendors | Teams can build a homegrown promotion solution with any of these. Compared to Kargo, teams often struggle with GitOps timing and with adding governance and testing. |
Spot solutions | Argo CD Image Updater, ApplicationSets progressive syncs | Each solves one slice. Neither is wrong, but assembling them into a whole is left to the team. |
Open Source Kargo vs. Kargo Enterprise: What's the Difference?
Open source Kargo covers one team with a couple of clusters running Git and Kubernetes. Kargo Enterprise is aimed past that crossover: hosted instances with an agent that phones home, so multiple Argo CD instances and clusters across clouds work without opening inbound access, plus ServiceNow and Jira integrations, promotion to non-Kubernetes targets, and the promotion advisor, which diffs an image's source repository between the running and promoting commits and presents a risk assessment before you promote.
Who Is Kargo in Action For?
The book is written for the engineer implementing promotion, the manager who needs to understand how it fits, and the leader who approves paying for it. It opens with what promotion is and works up to advanced use cases; readers higher up the org chart may find the first three or four chapters sufficient.
Kargo in Action is available now through the Manning Early Access Program and can be downloaded here.
Further Reading and Resources
Kargo Quickstart: build a Warehouse and Stage on a local cluster and promote a first change
Kargo in Action: the book by Ken Cochrane, Jesse Suen, and Kent Rancourt, in early access
Continuous Promotion with Kargo: a complete guide to continuous promotion
Kargo Quickstart: build a Warehouse and Stage on a local cluster and promote a first change
Automated Rollbacks in Kargo 1.11: how stable Freight and automatic recovery work
The Promotion Layer GitOps Was Missing: The Rise of Kargo: origin story and adoption examples
Kargo Enterprise: the managed platform and its enterprise capabilities
