Details
GitOps can continuously reconcile an environment with the desired state declared in Git, but it does not decide which application version should advance from development to staging or production. Teams often fill that gap with CI scripts, bots, pull requests, Slack approvals, and other disconnected processes.
In this session, Akuity Developer Advocate Graziano Casto explains how open source Kargo adds a dedicated continuous-promotion layer to a GitOps workflow. Argo CD remains responsible for deploying the state recorded in Git, while Kargo determines what should move between environments, applies verification and approval gates, updates Git, and preserves a complete promotion history.
In a GitOps model, teams describe the desired application state through version-controlled configuration such as YAML files or Helm charts. Engineers do not directly modify the cluster to deploy an application.
A GitOps controller such as Argo CD or Flux reads that desired state, applies it to the target environment, and continuously reconciles differences between Git and the running cluster.
Argo CD answers a specific question: Does the cluster match the desired state declared in Git?
It does not decide which version should move from development to staging, whether that version passed the required tests, who approved it, or when it should advance to production.
That boundary is intentional. Argo CD manages deployment reconciliation, while another process must govern promotion between environments.
Continuous integration builds and tests application artifacts. GitOps deployment tools apply the state already recorded in Git.
Between those activities, teams still need to determine what moves forward, preserve the complete tested application bundle, apply approvals and verification, and track the result.
Many organizations currently handle this with shell scripts, CI pipeline steps, update bots, or manual changes. Those approaches can work, but they often lack shared state and end-to-end visibility.
An application version may depend on a container image, Helm chart, configuration, and specific Git commit.
Moving only the image between environments does not necessarily promote the same application that was previously tested. If the associated configuration or chart changes, staging may validate a different bundle from the one eventually deployed to production.
Kargo represents the complete collection of artifact references as Freight, allowing the tested bundle to move through the promotion pipeline as one unit.
Kargo is an open source continuous-promotion tool designed to move validated artifacts through environments using defined stages, policies, verifications, and approval gates.
Its resources are Kubernetes custom resources, so promotion logic can be stored, versioned, templated, and managed in a declarative way. Akuity
Kargo works primarily with Git. It determines the desired state for a stage and writes the appropriate artifact references into the Git repository.
Argo CD then detects that change and synchronizes the target cluster with the newly declared state.
In simple terms:
Kargo decides what should advance.
Argo CD makes the environment match Git.
Development may use automatic promotion whenever a new artifact is detected. Staging can require tests and a pull-request approval. Production can retain a manual gate, change request, or promotion window.
Continuous promotion does not require removing every human approval. It allows teams to automate routine movement while preserving deliberate controls where risk is highest.
Kargo records which Freight moved into each Stage, who initiated the promotion, which steps ran, whether verification succeeded, and when the transition occurred.
Because promotions ultimately update Git, teams retain both application deployment history and promotion history.
Kargo’s Core Concepts
Warehouse
A Warehouse watches artifact sources such as container registries, Helm repositories, and Git repositories. When it detects a new or updated artifact, it creates Freight.
Freight
Freight is the application bundle promoted through the pipeline. It can reference a container image, Helm chart, configuration, Git commit, or several related artifacts that should move together.
Stage
A Stage represents a promotion target. It might be development, staging, production, a geographic region, a cluster, or a temporary pull-request environment.
Promotion
A Promotion advances specific Freight into a Stage and executes the configured steps, such as updating Git, opening a pull request, or running a verification.
Verification
Verification determines whether the promoted Freight meets the conditions required to advance. It can include smoke tests, analysis, policy checks, or other automated validation.
Promotion Pipeline
A promotion pipeline defines how Freight moves through Stages. It can be linear, branch into multiple regions, or require several upstream Stages to pass before the release proceeds.
Deployment and promotion are different responsibilities
Practical implication: Keep Argo CD responsible for reconciliation while using a promotion system to govern which version Git declares for each environment.
CI jobs should not become the permanent promotion control plane
Practical implication: Use CI to build and test artifacts, then hand the resulting references to a stateful promotion workflow.
Promote the tested application bundle
Practical implication: Track images, Helm charts, configuration, and Git commits together when they collectively define the release.
Automate according to risk
Practical implication: Enable automatic promotion and verification in lower environments while preserving pull requests or manual approvals for production.
Every gate should have a defined owner and condition
Practical implication: Document what opens the next Stage, whether that is a successful test, human approval, change request, schedule, or policy result.
Promotion workflows should be reusable
Practical implication: Template Kargo resources and promotion tasks so platform teams can distribute consistent workflows across applications and tenants.
Auditability should span the entire delivery path
Practical implication: Record which artifact bundle moved, who promoted it, what checks ran, and why the next gate opened.
Q: What is continuous promotion?
A: Continuous promotion is the automated or policy-controlled movement of validated application artifacts through successive stages such as development, staging, regional production, and global production.
Q: What is the difference between deployment and promotion?
A: Deployment makes a target environment match a declared state. Promotion determines which validated state should advance to the next environment and under what conditions.
Q: Where does Argo CD’s responsibility end?
A: Argo CD reads the desired state from Git and reconciles the cluster with it. It does not independently decide which application version should advance to another environment.
Q: What does Kargo add to an Argo CD workflow?
A: Kargo monitors artifact sources, creates versioned Freight, moves that Freight through Stages, runs promotion and verification steps, updates Git, and records the promotion history.
Q: Does Kargo deploy directly to Kubernetes clusters?
A: Kargo generally updates the desired state in Git. A GitOps controller such as Argo CD then detects the change and applies it to the cluster.
Q: What is Freight in Kargo?
A: Freight is an immutable reference to one or more artifacts moving through the promotion pipeline. It may include a container image, Helm chart, configuration commit, or a combination of those references.
Q: Can Kargo promote several artifacts as one unit?
A: Yes. Bundling related artifact references is one of the principal purposes of Freight. A Warehouse can also subscribe only to an image repository when an image is the sole promotion unit.
Q: How is Kargo different from Jenkins or GitHub Actions?
A: Jenkins and GitHub Actions execute CI or workflow jobs and then finish. Kargo retains the state of the promotion pipeline, including which Freight occupies each Stage, which checks passed, and which versions can advance.
Q: Can teams keep a manual approval gate for production?
A: Yes. Teams can automatically promote through development and staging while requiring a pull request, manual approval, or enterprise change request before production.
Q: Can Kargo support multi-region deployments?
A: Yes. Stages can represent regions or other deployment targets. A verified production Stage can branch into additional regional Stages with separate or automatic promotions.
Q: Can Kargo scale across many applications?
A: Kargo resources are Kubernetes custom resources and can be templated. Teams can define reusable promotion tasks and reference them across applications instead of creating every workflow manually.
Q: What does Kargo Enterprise add?
A: The session describes managed scaling and additional capabilities such as notifications, automatic rollback, promotion windows, custom containerized steps, ServiceNow integration, Terraform workflows, and other governance features. Akuity’s current platform materials similarly distinguish the managed enterprise layer from the open source promotion engine.
Ken Underhill: Hello, everyone, and welcome to today’s DZone webinar with Akuity, Transform Your CI/CD Approach With Continuous Promotion Using Open Source Kargo.
I’m Ken Underhill, and I’ll be your host for today’s session.
Before we begin, today’s session is being recorded. We’ll share the recording with everyone who registered after the event.
If you have questions during the presentation, please submit them through the Q&A function. We’ll address as many as possible during the Q&A portion at the end.
Getting an application deployed is one thing. Knowing exactly where it is in the delivery process—and moving it safely from staging to production—is another.
For many engineering teams, manual scripts, configuration drift, and scattered approval processes still create uncertainty around what happens after deployment.
Even when an application is healthy and running in one environment, getting it to the next stage can involve a series of disconnected steps.
Today, we’ll explore how GitOps and continuous promotion can bring those steps together in a more automated and auditable workflow.
We’ll examine how defining desired state in Git creates a foundation for consistent deployments, where Argo CD’s responsibility ends, and how Kargo bridges the gap between deploying an application and moving it safely toward production.
I’m pleased to introduce today’s speaker. Graziano Casto is a Developer Advocate at Akuity, where he helps developers explore technologies and approaches that can improve their workflows.
He is also an active member of the DZone community, and we’re always pleased to feature voices from our developer community.
Graziano, it’s great to have you with us. I’ll turn it over to you.
Graziano Casto: Thank you, Ken, and thank you to DZone for having us.
We’re going to discuss continuous promotion and Kargo.
We’ll begin by defining GitOps. We’ll then examine the current problem with promotions, explain what Kargo is and why it exists, and finish with a demonstration of Kargo managing a promotion pipeline for a simple application.
I’m a Developer Advocate at Akuity and a DZone Core member, so you may know me from my articles on the platform.
I’m also active in the Cloud Native Computing Foundation community. I’m a co-chair of the Developer Experience Technical Advisory Group, one of the maintainers of the Kubernetes blog, and a CNCF and platform engineering ambassador.
I’m currently focusing primarily on the GitOps side of application delivery and working closely with the Kargo and Argo communities.
Akuity was founded by creators of the open source Argo CD and Kargo projects. We support and contribute to those upstream communities.
Akuity also offers an enterprise software-delivery platform. Its promotion capabilities use Kargo as the promotion engine. The platform provides a managed Kargo instance with additional enterprise features.
It also provides management for Argo CD and AI agents designed to assist with day-two operations.
Before discussing Kargo and promotion, let’s begin with what GitOps means.
GitOps Fundamentals
The most important rule in GitOps is that the desired state of the application lives in Git.
You do not directly modify the cluster. You define the state of the application through YAML files, Helm charts, or other configuration stored in a Git repository.
The Git repository becomes the source of truth for the application.
A GitOps agent—such as Argo CD or Flux—pulls the application manifests from the Git repository and synchronizes them with the target environment or cluster.
GitOps is based on four main principles.
First, everything should be declarative. The application’s desired state should be described through configuration in the Git repository.
Second, everything is versioned and immutable. Because the system uses Git, every deployment corresponds to a Git commit. The repository preserves the history of the deployment states.
Third, changes are pulled automatically. Argo CD or another GitOps agent reads the manifests in the repository and applies them to the cluster.
This differs from a push model in which a CI/CD pipeline reads a repository and pushes changes directly into the cluster.
The pull model enables the fourth principle: continuous reconciliation.
An agent in the cluster does not apply a change once and then stop. It continually checks whether the cluster matches the desired state in Git.
This reconciliation loop is familiar to people working with Kubernetes. Argo CD keeps the cluster synchronized with the Git repository.
A push-based CI/CD pipeline generally follows a fire-and-forget approach. It applies the configuration and then loses the ongoing state relationship. It does not provide the same continuous reconciliation loop.
Argo CD’s Responsibility
Now that we understand GitOps, we can define Argo CD’s responsibility.
Argo CD reads what is stored in Git and applies it to the cluster. That is its job.
Everything written into the GitOps repository can be applied to the target environment.
But who decides what should be written into Git? Who decides when it should change, how it should change, and why?
That is the problem we’re addressing today.
The Promotion Gap
A real CI/CD process is more complicated than a Git repository connected to Argo CD and a cluster.
The process starts when a developer pushes code into an application repository.
CI builds the artifact, runs tests, and publishes the artifact to a container registry.
The artifact is then deployed into a development environment and tested with the applicable configuration.
If those tests pass, it advances to staging and is tested again, potentially with another set of configuration.
After staging succeeds, it may advance toward production. Production may use a canary strategy, manual analysis, regional rollout, or another progressive-delivery model.
The release can also split into different paths. One group may pass the tests while another fails, forcing the team to stop or restart part of the process.
Only after navigating this larger decision tree does the application reach the production cluster.
There is therefore a substantial gap between CI and CD. Many teams fill that gap with scripts.
Teams generally promote changes in one of three ways.
They may use a shell script or CI step to update the version in a manifest and move the updated configuration into an environment directory.
They may use a bot that watches a registry and opens a pull request whenever a new version appears.
Or they may perform the update manually.
All three approaches can work, but they do not always solve the complete promotion problem.
Consider moving an application from development to staging and then production. Teams often think only about moving container image version 1.0.0 through those environments.
The image may be the principal artifact, but it could also depend on a specific Helm chart or configuration.
If the process moves only the image, it may not promote the same complete application that was tested previously.
Development may test image 1.0.0 with one configuration. Staging may receive the same image but use another chart or configuration.
The system is no longer promoting the same tested bundle.
The other significant problem is visibility.
Teams need to know what is currently in development, staging, and production. They need to know who promoted a version, when the promotion happened, which process initiated it, and why it was allowed to advance.
That is why we need continuous promotion.
Continuous Promotion
Continuous promotion moves changes from the desired state of one Stage to the next.
It promotes the complete bundle from one Stage to another until it reaches the final target.
In this model, Argo CD continues performing the same job. It owns deployment and keeps the cluster synchronized with Git.
Kargo is the additional component. It owns promotion.
Kargo replaces the collection of promotion scripts with one declarative system.
Kargo is an open source project available under the Apache License. It is created by Akuity but developed with contributions from its community and used in production by several organizations.
The first important point is where Kargo fits and what it can change.
Kargo sits above Argo CD and interacts with Git.
It orchestrates promotion and determines the desired state for each Stage. It commits that state to the Git repository.
Argo CD then pulls the desired state for the applicable Stage from Git and synchronizes it with the cluster.
Warehouses, Freight, and Stages
Kargo is built around three principal concepts: Warehouses, Freight, and Stages.
A Warehouse subscribes to artifact sources. Those sources may include container registries, Helm repositories, and Git repositories.
When something is added or changed in one of those sources, the Warehouse creates Freight.
Freight is the application bundle. It is the unit that moves through the promotion pipeline.
Freight does not have to represent only an image. It can include the image, configuration, chart, and other subscribed artifact references.
Stages are the promotion targets.
A Stage can represent development, staging, production, a pull-request environment, a cluster, a geographic region, or another target appropriate to the organization.
When a Warehouse detects a change, it creates Freight. That Freight moves from one Stage to another.
Each Stage functions as a gate and can have its own policies.
For example, development can use automatic promotion. Whenever the Warehouse creates new Freight, Kargo automatically promotes it into development.
A Stage can also include verification or require an approval before the Freight advances.
Automated and Auditable Promotion
Kargo converts script-based promotion into an automated and auditable workflow.
It can automatically promote Freight and execute verification gates. A promotion succeeds or fails according to the tests and conditions the organization defines.
The promotion steps are declarative. Kargo resources are Kubernetes resources and can be stored in Git.
The process is auditable because every promotion produces a Git commit and a recorded history.
For each Freight object, teams can see who promoted it, where it moved, when the promotion occurred, why it advanced, which steps ran, and whether verification succeeded.
Akuity also offers Kargo Enterprise with additional capabilities.
These include notifications when promotions succeed or fail, automatic rollback to previous Freight, promotion windows that restrict when releases may advance, governance controls, ServiceNow and Jira integrations, Terraform workflows, and other enterprise features.
Kargo Demonstration
Let’s look at the demonstration pipeline.
Everything starts with a Warehouse.
This Warehouse subscribes to a container-image repository in GitHub Container Registry and another repository running inside the cluster.
The pipeline includes a development Stage with automatic promotion enabled.
Whenever the Warehouse creates new Freight, that Freight is promoted automatically into development.
The pipeline then includes staging and production gates. The verified production Stage branches into separate geographic environments, including North America West, North America East, and EMEA.
Let’s publish a new container image.
After publishing version 1.4.0, the Warehouse detects it and generates new Freight.
Because automatic promotion is enabled for development, the development Stage begins promoting the new version.
The promotion executes several steps.
It clones the Git repository, updates the YAML configuration with the new version, commits and pushes the change, and then allows Argo CD to apply that change to the cluster.
The Stage also performs verification.
In this example, the verification is a smoke test that makes an HTTP call to confirm that the guestbook application is available.
We can now promote version 1.4.0 to staging.
Kargo will not allow us to skip directly to production because the required upstream Stages must be verified first.
The only valid next action is to promote 1.4.0 into staging.
Kargo shows that the image tag will change from 1.3.1 to 1.4.0.
The staging promotion includes an approval step. Kargo can update Git directly, but it can also open a pull request.
In this example, the pull request is the gate. Once the pull request is reviewed and merged, Argo CD can deploy the new state into staging.
The staging Stage then performs its verification test.
Development and staging are now running version 1.4.0, while the EMEA production environment remains on 1.3.1.
We can now promote the verified version into the production Stage.
The promotion contains three YAML update steps because it updates the configuration for each geographic region.
After the repository updates and verification steps succeed, automatic promotion advances the application into the regional production Stages.
Kargo also displays all Freight generated from version 1.0.0 through 1.4.0.
For each Freight object, teams can inspect every Stage it entered, who promoted it, the promotion steps that ran, and the verification results.
That is a brief demonstration of how Kargo works.
When reviewing your own pipelines, ask three questions:
What is the unit being promoted?
Where is the successful result recorded?
Who or what opens the next gate?
Kargo answers these questions through concepts such as Freight, Stages, Promotions, and Verifications.
Your organization may use a different solution, but it should still have clear answers.
Q&A
Ken Underhill: Thank you, Graziano. That was a helpful walkthrough of how deployment and promotion fit together and how teams can create a more consistent path from Git to production.
Our first question is: How is Kargo different from Jenkins or GitHub Actions?
Graziano Casto: I’ll answer with a metaphor.
Jenkins and GitHub Actions are like delivery carriers. They deliver a parcel when called and then leave.
Kargo is more like the complete logistics system. It knows which parcel is in each Warehouse, which one passed inspection, and which one is allowed to move forward.
CI and pipeline tools are excellent for the jobs they were designed to perform, including running build and test scripts.
Promotion, however, is an asynchronous process. It requires something that retains state and provides visibility across the complete workflow.
At any point, teams need to understand what is happening. That is what Kargo provides.
Ken Underhill: What is the difference between open source Kargo and the Akuity platform?
Graziano Casto: With the Akuity platform, you receive a managed Kargo instance. The platform scales the Kargo control plane according to the number of applications being managed.
It also adds notifications for promotions, Custom Steps that can run containerized logic, and integrations with other enterprise systems.
For example, a Custom Step could perform a vulnerability analysis during every promotion.
The enterprise platform can integrate with ServiceNow so that a change request gates a promotion.
It can also integrate with Terraform, allowing teams to promote application and infrastructure changes together.
For example, a workflow could update infrastructure required by a serverless function alongside the application release.
Ken Underhill: We have two related scalability questions.
First, is multitenancy supported? If an organization has many customers requiring an update, can it push that update to multiple instances?
Second, if a team operates hundreds of applications, can Kargo scale without requiring every workflow to be maintained manually?
Graziano Casto: The scalability question has two parts.
The first is whether the engine scales.
The enterprise version is managed by Akuity and scales automatically.
With open source Kargo, teams can distribute controllers and connect multiple Argo CD control planes. They can also replace polling with webhooks to improve artifact detection.
The second question is how teams manage the volume of YAML required for thousands of applications.
Kargo resources are Kubernetes custom resources, so teams can template them in the same way they template other Kubernetes resources and store them in Git.
A platform team can define promotion logic once as a reusable PromotionTask and distribute it across the organization.
Each application Stage can reference that PromotionTask while supplying the variables that differ for the application.
Ken Underhill: If a team wants to distribute one update to many customers, can it promote to 100 instances at once, or is each instance considered a separate deployment?
Graziano Casto: Kargo’s concepts are designed to be customizable.
Teams can build a pipeline that promotes to hundreds of applications or targets simultaneously, or they can divide the rollout into separate groups.
The short answer is that multitenancy is supported, and teams have several ways to model it.
Ken Underhill: Can Kargo promote a bundle of artifacts—such as an image, Helm chart, and configuration—as one unit, or can it promote only individual images?
Graziano Casto: Bundling artifacts is the default purpose of Freight.
Freight can include an image, configuration represented by a Git commit, and a Helm chart. It can contain the references that collectively describe the application.
A Warehouse can also subscribe only to a container registry and promote just an image. The choice depends on how the application is defined.
Ken Underhill: Can teams keep manual approval gates for production while automating everything below it?
Graziano Casto: Yes.
In the demonstration, automatic promotion was enabled only for development so that I could also show a pull-request gate.
A team could automatically promote into development, run verification, automatically promote into staging, run another verification, and retain an approval gate only for production.
That production gate could be a pull request or, in the enterprise version, a ServiceNow change request.
Ken Underhill: Thank you again, Graziano.
This was a helpful look at how Argo CD and Kargo can create a more connected approach to application delivery.
Hopefully, the session has provided ideas for rethinking delivery workflows and identifying manual steps that could be simplified.
Thank you to everyone who attended. Keep an eye on your inbox for the on-demand recording, and we look forward to seeing you at another DZone webinar.
Presenters:
Graziano Casto
Developer Advocate, Akuity
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
