Kargo moves the promotion decision into a controller, and the gate is the part left blank
A dev.to writeup lays out per-account EKS clusters, digest-only promotion and OIDC everywhere. The metric-backed gate it calls critical is the thinnest part of the design.
The Engineer · Build desk
What happened
- Argo CD's remit stops at making a cluster match Git; it does not decide when a version should advance from dev to staging to production.
- That decision has been left to a person editing a values file, or to a CI job running sed against the repository.
- Kargo takes the gap: it models each environment as a Stage, packages artifact versions as Freight, and promotes by committing to the GitOps repo.
- The writeup calls for one EKS cluster per environment, ideally in separate AWS accounts under AWS Organizations rather than namespaces on a shared cluster.
- Promotion moves immutable digests by reference, so the artifact reaching production is byte-identical to the one validated in staging.
Why it matters
- Who's exposed exposure With OIDC in place, a leaked repository secret is no longer the route into ECR.
- What it costs cost The isolation argument bills you four AWS accounts and four Kubernetes control planes before a workload ships, and each of those clusters has to be upgraded and kept current by whoever owns the...
- Who has to decide decision Teams have to pick between a management cluster holding credentials into every environment and three separate Argo CD installs fed only by Git commits from one Kargo.
Kargo's value is less in writing the commit than in forcing somebody to state the condition under which the commit gets written. A person editing a values file carries that condition in their head [3]. A Stage with a verification gate has to put it in configuration, and whoever writes that configuration owns the release policy from then on. The author calls metric-backed gates the critical element of the architecture [16], and says his team runs variations of it in production [17]. The specificity in the material supplied here sits elsewhere: OIDC trust policies pinned to a repository and branch [12], one IAM role per service with push rights to a single ECR repository [12], registry policies granting cross-account pull [9]. That is an honest reflection of where the plumbing work is, and it also leaves the decision logic as the least described component of a design whose stated purpose is to automate a decision.
"Rollback is git revert" [6] describes the declaration, not the artifact. Reverting the commit points the Stage back at the previous digest, and that only restores service if the digest is still in the shared-account ECR repository and the registry policy still grants the workload account pull rights [9]. Image lifecycle rules become part of the recovery path. Most teams do not keep them there.
The topology choice compounds this. Three Argo CD installs driven by one centralized Kargo [14] means three reconcilers whose behaviour you have to reason about separately when a promotion half-lands, against one management cluster that holds credentials into every environment [1]. Neither option is free, and the writeup is straight about the tradeoff rather than selling one.
Everything the gate is supposed to prove rests on the byte-identical rule [10]. If a pipeline rebuilds per environment, the metrics a gate reads in staging describe a build that never reaches production, and the gate certifies nothing while still producing a green result. That failure is quiet, which is the worst property a release control can have. The isolation argument is easier to make: namespaces on a shared cluster do not contain a noisy neighbour or a failed cluster upgrade [7], and account boundaries scope IAM, billing and quotas without extra machinery [8]. Digest discipline is the cheaper half of this architecture and the half that decides whether the expensive half means anything.
What to watch
- Whether admission-time cosign verification is enforced in production or left in a warn-only mode, which decides if provenance is actually a gate.
- Whether the attached SBOMs get consumed by anything downstream or simply accumulate as OCI artifacts nobody queries.
- Whether promotion authority stays entirely with Kargo at the production Stage, or a human approval step gets reinserted after the first bad automated promotion.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence30
- Adoption12
- Hype gap+28
- Incentives42
- Confidence44
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
A shared services account hosts Argo CD and Kargo on a management cluster, registering the workload clusters as deployment targets; the stated alternative is an Argo CD instance per cluster with a centralized Kargo driving all of them through Git, which keeps the prod cluster from needing inbound access from anywhere.
- [2]
Argo CD's job is narrow: make the cluster match what Git says. It does not decide when a new version should move from dev to staging to production.
- [3]
The promotion decision has historically been made by a human editing a values file, or by a brittle CI job running sed against the repository.
- [4]
Kargo watches artifact sources (ECR, Git, Helm repos), models each environment as a Stage, packages new artifact versions as Freight, and promotes that Freight between stages by writing commits to the GitOps repo, which Argo CD then reconciles.
- [5]
The separation of concerns described: GitHub Actions builds, tests, signs and pushes but never touches a cluster; Kargo decides what version belongs in which environment and records that in Git; Argo CD makes each cluster converge on what Git declares.
- [6]
Every environment's state is a commit, every promotion is auditable, and rollback is git revert.
- [7]
Namespaces on a shared cluster do not give blast-radius isolation: a misbehaving controller, a noisy neighbour exhausting node resources, or a cluster upgrade gone wrong take dev and prod down together.
- [8]
The recommended setup is one EKS cluster per environment, ideally in separate AWS accounts (dev, staging, prod) under AWS Organizations, because account boundaries are the strongest isolation primitive AWS gives: IAM, billing, service quotas and security tooling all scope naturally.
- [9]
ECR sits in the shared account with cross-account pull permissions granted to each workload account via registry policies: one image, one immutable digest, promoted by reference and never rebuilt per environment.
- [10]
The artifact that reaches production must be byte-identical to the one validated in staging; rebuilding "the same" image per environment silently invalidates everything the pipeline verified. Promote digests, not tags.
- [11]
An AWS_ACCESS_KEY_ID in GitHub repository secrets is a standing credential waiting to leak; GitHub's OIDC provider lets each workflow run exchange a short-lived, cryptographically verifiable token for a scoped IAM role session.
- [12]
The IAM role's trust policy pins the exact repository and branch (repo:digitalzone/frontend:ref:refs/heads/main), so a compromised fork or a rogue workflow in another repo cannot assume it; the guidance is one role per service with push rights to only that service's ECR repository.
- [13]
Two additions recommended: sign images with cosign keyless via the same OIDC identity and verify signatures at admission time with a policy controller on each cluster, and generate an SBOM at build time attached as an OCI artifact.
- [14]
The alternative topology means three Argo CD installations, one per workload cluster, driven by a single centralized Kargo.
- [15]
The recommended layout implies four AWS accounts and four Kubernetes control planes before any workload ships: dev, staging and prod workload accounts plus a shared services account, and three workload EKS clusters plus one management cluster.
- [16]
The author lists automated verification gates backed by real metrics before anything gets promoted as the critical element of the AWS architecture, alongside per-environment EKS clusters, ECR, OIDC federation instead of static credentials, and ApplicationSets instead of copy-pasted manifests.
- [17]
The author states this is the architecture his team runs variations of in production.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.