Promotion Across Kubernetes and Hybrid Environments
In 2026, multi- and hybrid environments are increasingly the norm. For platform engineering, DevOps and application developers, this adds complexity to the software delivery lifecycle. For cloud-native teams, Kubernetes may anchor application delivery, but releases often span infrastructure, identity, networking, and workloads running outside the cluster.
We’ve worked with hundreds of organizations adopting GitOps at scale, and we’ve seen a consistent pattern. While many organizations have been able to build reliable deployment workflows inside Kubernetes, promotion across environments remains a persistent challenge. Industry surveys, including the recent CNCF annual cloud-native survey on Argo CD usage, reveal that environment management and coordination are among the top-reported areas of concern.
Where Promotion Gets Complex
Many teams rely on consistent GitOps workflows for Kubernetes deployments. Configuration lives in Git, promotions follow a defined path, and tracing a deployment is straightforward.
As soon as a release spans additional systems, that alignment becomes harder to maintain. Infrastructure updates follow one process, VM deployments follow another. Serverless changes rely on different tooling. Each system introduces its own approval flow, logging model, and rollback semantics.
Consider a typical release. Cloud permissions are updated to support a new feature. The application depends on those permissions. A background job running elsewhere also needs configuration changes. All of this belongs to a single release, yet it moves through separate pipelines.
The order of changes has to be managed deliberately. Approvals often happen in more than one place, and audit trails end up spread across multiple tools.
Deploying each component on its own usually isn’t the hard part. The difficulty shows up when those pieces need to move forward together as a single promotion.
Promotion Across Hybrid Environments
As organizations adopt Kubernetes alongside existing infrastructure, they end up operating multiple execution models.
Within Kubernetes, promotion typically involves updating configuration in Git and allowing controllers to converge the cluster to the desired state.
Other systems behave differently. Infrastructure changes require deliberate plan-and-apply cycles. VM and serverless deployments follow their own release workflows, whether that involves publishing artifacts, updating images, or triggering platform-specific deployments. Some changes can be reversed quickly; others are harder to unwind.
When a release spans these layers, promotion becomes coordination across systems with different behaviors. Dependencies need to be understood, sequencing enforced, and evidence captured in a way that stands up over time.
A production environment includes every resource an application depends on. Moving those pieces independently may work in isolation, but over time it fragments visibility and increases operational risk.
Patterns We See in Multi-System Delivery
In working with teams managing releases across multiple environments, a few patterns have emerged:
- Environmental boundaries are defined differently across systems. What one platform treats as “production” does not always align with another, which complicates promotion workflows.
- Related changes move through separate pipelines. Infrastructure and application updates are often handled independently, even when they depend on each other.
- Sequencing is managed manually. Teams understand dependencies, but the workflow does not always enforce them explicitly.
- Cross-system handoffs rely on implicit contracts. Infrastructure produces values that applications consume, and those handoffs are frequently handled informally.
- Approval and audit expectations vary by system. The level of traceability depends on the tool involved, leading to inconsistent promotion practices.
These patterns extend GitOps discipline from the cluster boundary to the broader environment.
How These Challenges Impact Software Teams
As the creators of Argo CD, we’ve been neck-deep in work with the open source community and customers. The complexity of environment promotion comes with real operational pain:
- Slower releases: What should take hours stretches into days because someone has to manually coordinate across systems, verify sequencing, and track down who approved what.
- Failed promotions: The application deploys successfully, but the infrastructure isn’t ready. Or the infrastructure updates, but a dependent service missed its configuration change. Debugging requires checking multiple systems.
- Challenging compliance audits: Proving compliance becomes much more difficult with evidence spread across GitHub, Terraform Cloud, Jenkins logs, and Slack.
- Increased configuration drift: Manual promotion means shortcuts. “We’ll fix staging later” becomes “staging and production are configured differently and nobody knows why.”
How Environment Promotion Tools Help
The GitOps community has started addressing this challenge. Open-source tools like Kargo and GitOps Promoter emerged specifically to formalize environment promotion workflows. These tools provide structure around what’s traditionally been manual: defining promotion stages, enforcing sequencing, requiring approvals, and maintaining audit trails across environments.
For teams working within Kubernetes, these tools formalize promotion workflows. They make the “dev to staging to production” workflow explicit and traceable, rather than relying on custom scripts or manual coordination.
But production environments rarely stop at the cluster boundary. When a release includes Terraform infrastructure, AWS Lambda functions, database migrations, and Kubernetes deployments, the promotion workflow needs to coordinate across all of them—not just the pieces running inside the cluster.
Extending GitOps Beyond Kubernetes
GitOps brought structure to what happens inside the cluster. As organizations operate across Kubernetes and other platforms, that same discipline needs to extend to the full environment.
When a release spans infrastructure, identity, and application layers, promotion cannot remain a cluster-level concern. It has to reflect the full shape of the system.
For teams operating in hybrid environments, that shift in perspective is increasingly necessary.
