Q2 2026 Product Update: Harness Continuous Delivery & GitOps | Harness Blog

‍

Q2 | May – July 2026

Welcome back to the quarterly update series! If you've been following along, Q1 2026 brought AI-powered continuous verification, expanded deployment platform support, and GitOps workflow enhancements. Q2 builds on those foundations with progressive Kubernetes canary rollouts, native AI agent deployments, sharper verification controls, and a wave of GitOps improvements — from one-click application rollback to finer-grained RBAC — that make self-service operations a reality for platform teams.

‍

Deployments

Kubernetes

Progressive Canary for Kubernetes

Harness now supports progressive canary deployments as a dedicated subtype of the Kubernetes Canary strategy. Instead of a single canary phase, you can define percentage-based rollout stages — for example, 25%, 50%, and 100% — with verification or approval gates between each phase. Harness maintains two Deployments and shifts replicas between them, keeping the total pod count within a fixed budget throughout the rollout. This gives platform teams a repeatable, observable path for shipping changes with automated quality gates at each step rather than a binary canary-or-full-traffic decision. Learn more about Kubernetes progressive canary deployments →

Kubernetes Blue-Green: Scale-Up on Rollback

When a Kubernetes Blue-Green deployment fails and triggers a rollback, Harness now automatically scales up the previous (stable) deployment after the services are swapped back. Previously, the stable deployment could be sitting at zero replicas during the rollout, meaning traffic routed to it immediately after the service swap would hit unscaled pods. The automatic scale-up eliminates this gap, ensuring traffic reaches active pods as soon as the rollback completes. Learn more about Blue-Green Scale Up on rollback →

Kubernetes Dry Run: Additional kubectl Flags

The Kubernetes Dry Run step now accepts additional kubectl flags — including --server-side and --force-conflicts — so the dry run validation command matches the actual kubectl arguments used at deploy time. Teams using server-side apply can now ensure that their dry-run output accurately reflects what will happen at deployment, making approval gates and policy checks more reliable. Learn more about the Kubernetes Dry Run step →

Istio Traffic Routing: AND/OR Match Logic

Istio traffic routing steps now support configurable AND/OR match logic for route rules. The new Match all rules option lets you require that every configured rule (URI, headers, method, port) match before a request is routed, rather than routing on any single match. This gives teams with complex traffic shaping requirements finer control over which requests reach canary or stage deployments. Learn more about the Traffic Shifting step →

Kubernetes Connector: Client Credentials OIDC Grant

The Kubernetes cluster connector now supports the client credentials OIDC grant type for machine-to-machine cluster access. In addition to the existing password grant, you can now authenticate with a client ID and client secret alone — suitable for scenarios such as AKS clusters fronted by Microsoft Entra ID, where a human user credential is neither available nor appropriate. Existing connectors are unaffected.

‍

AWS

Bulk Post-Production Rollback

When a bad release reaches multiple infrastructure targets simultaneously, you no longer need to roll back each one individually. From the service dashboard, you can now select multiple infrastructures where a service is deployed and roll them back together — choosing the target execution for each infrastructure before confirming the rollbacks. This compresses what was previously a tedious per-environment operation into a single coordinated action. Learn more about rollback deployments →

ASG MixedInstancesPolicy Support

AWS Auto Scaling Group deployments now support MixedInstancesPolicy, enabling the use of spot instances and automatic fallback under capacity constraints. You can configure the policy in the ASG configuration JSON to allow AWS to select from multiple instance types, and Harness automatically detects and updates the launch template version within the MixedInstancesPolicy during deployments. This opens cost optimization options for teams running non-critical workloads on spot capacity without sacrificing deployment automation. Learn more about MixedInstancesPolicy →

AWS CDK on ECS Delegates

AWS CDK steps can now run on ECS-based delegates, removing the requirement for a Kubernetes delegate runtime to execute CDK synth and deploy steps. Teams running hybrid or ECS-only delegate fleets can now use CDK provisioning without having to stand up a dedicated Kubernetes delegate. Learn more about AWS CDK on ECS delegates →

Smart CDK Diff: Skip Deploy When No Changes

Harness now supports automatic skipping of AWS CDK Deploy steps when a preceding CDK Diff step detects no infrastructure changes. This prevents pipelines from executing a no-op CDK deploy when only the application code has changed, but the infrastructure definitions have not, reducing end-to-end pipeline runtime. Learn more →

ECS Rolling: Skip Application Auto Scaling

ECS Rolling deployments now support a Skip application auto scaling option that tells Harness to bypass all AWS Application Auto Scaling API calls for that deployment. This is designed for teams that manage auto-scaling externally (outside of Harness service definitions), and for scenarios where many ECS services are deployed in parallel, and the volume of scaling API calls risks hitting AWS rate limits. Learn more →

OIDC Environment Session Tags for AWS

AWS connectors with OIDC authentication now include environment identifiers as session tags in OIDC tokens. This lets you enforce environment-specific IAM policies — for example, restricting access to production secrets to pipelines running in production environments — while sharing a single delegate pool across environments. You no longer need separate connectors or delegates to achieve environment-level IAM isolation. Learn more about OIDC environment-based session tags →

‍

Google Cloud

MIG Blue-Green: Pre-Traffic Staging Deployment

Google Managed Instance Group (MIG) Blue-Green deployments now expose a staging deployment step before the traffic shift so that you can test and validate the new MIG version — including running pre-traffic checks and approval gates — before any live traffic is shifted to it. This closes a gap for teams that need to exercise the new MIG at scale before committing to the shift. Learn more about MIG Blue-Green deployments →

OCI Helm Charts from Google Artifact Registry

You can now use OCI-based Helm charts stored in Google Artifact Registry (GAR) as a manifest source for Helm deployments, expanding the set of OCI Helm registries Harness supports natively alongside ECR, Docker Hub, and others. Learn more about Helm chart cloud providers →

‍

AI Agent Deployments

Harness now natively supports deploying AI agent workloads as a dedicated deployment type in Harness CD — the first CI/CD platform to offer first-class pipeline automation for AI agent services.

This release adds out-of-the-box support for two agent runtimes: **AWS Agent Core** and **Google Agent Runtime**. You can model an AI agent service in Harness the same way you would any other service — define the artifact, configure the infrastructure, and attach a deployment pipeline. From there, all the same pipeline primitives apply: approval gates before a new agent version goes live, canary phases to validate agent behavior under partial traffic, automatic rollback when a verification step fails, and OPA policy checks before any agent deployment reaches production.

For platform teams managing a growing portfolio of AI agent workloads, this means agent deployments stop being one-off automation scripts and become first-class, auditable, policy-governed releases alongside the rest of your software. Explore AI Agent Deployments →

Traditional (SSH / WinRM)

Shell Script Step: Harness ID Tokens

The Shell Script step now supports Harness ID tokens via named identities. You declare one or more named identities on the step, and Harness generates an independent OIDC ID token for each, injecting it into the script as an environment variable at runtime. Scripts can then authenticate as the workload itself rather than through a connector, enabling fine-grained, per-script identity for sensitive automation tasks. Learn more about Harness ID tokens for the Shell Script step →

Preserve Directory Structure in Command Step Copy

The Copy command in the Command step now includes a Preserve Directory Structure option that maintains the original directory hierarchy when copying config files to target hosts. This prevents silent data loss from overwriting when multiple config files share the same name but reside in different subdirectories — a common pattern in multi-environment or multi-region SSH/WinRM deployments. Learn more about preserving directory structure →

‍

Connectors

Artifactory OIDC Authentication

The Artifactory connector now supports OIDC authentication, enabling credential-free federated authentication with JFrog Artifactory using short-lived JWT tokens. This eliminates the need to store static Artifactory credentials as Harness secrets and integrates Artifactory into the same keyless authentication model already available for AWS, GCP, and Azure connectors. Learn more about Artifactory OIDC authentication →

‍

Approvals

Approval Steps Inside Container Step Groups

Container Step Groups run all steps inside a single Kubernetes pod, which previously meant any pipeline that paused for human approval risked hitting the pod's 24-hour TTL before the approver responded. Harness now supports Harness Approval steps natively within Container Step Groups, and the pod's TTL automatically extends to match the stage timeout if it exceeds 24 hours. This removes the ceiling on containerized deployment workflows that span multiple time zones, require cross-team sign-off, or sit between canary and full-traffic phases. Note that only Harness Approval steps are supported inside Container Step Groups — Jira, ServiceNow, and Custom Approval types are not. Learn more →

Approval Visibility for Non-Approvers

Approval steps now support configurable visibility for non-approvers, letting users without approval permissions view step details during pipeline execution while keeping approval actions disabled. This is particularly useful for on-call engineers who need to monitor the approval status of an active deployment without approval authority. Configured at the project level under Default Settings. Learn more about approval visibility →

‍

Email Step

Email Step: Continue Send

The Email step now supports a non-blocking send mode, allowing pipeline execution to continue immediately after the email is dispatched, without waiting for delivery confirmation from the mail server. This removes an unnecessary blocking dependency for notification workflows where timely pipeline progress matters more than confirmed delivery. Learn more →

Verification

Git Experience for Monitored Services

Harness now supports Git Experience for monitored services, enabling version control and code review workflows for verification configurations. You can store monitored service configurations in your Git repository alongside the application code they verify, treat changes to health sources and SLOs as reviewable pull requests, and roll back verification configurations with standard Git operations. Learn more about Git Experience for monitored services →

AI Verify: New Configurable Properties

The AI Verify (v1) step now supports two additional **configurable properties** beyond the existing `deploymentStartTime`:

• dataCollectionDuration — Override the default data collection interval. Accepts a positive integer (number of minutes, maximum 60).
• customVerificationStartTime — Shift the verification window start to an earlier timestamp so that data from your health source already recorded between the deployment start and the Verify step execution is included in the analysis. Useful when:
  
  • Your observability tool (such as Dynatrace) begins recording immediately at service start
  • You have additional steps between your deployment step and the Verify step
  • Deployment and verification run in separate pipeline stages

Learn more about AI Verify configurable properties →

Per-Metric Sensitivity Override in AI Verify

The AI Verify step now supports per-metric sensitivity overrides, allowing you to set different sensitivity levels for individual metrics rather than applying a single threshold across the entire verification run. This means you can configure strict sensitivity for latency metrics and relaxed sensitivity for noisy metrics like memory usage — within the same Verify step — rather than tuning the global threshold to a compromise value. Learn more about per-metric sensitivity override →

CloudWatch: Full Metrics Insights Query Support

The CloudWatch health source now fully supports the complete CloudWatch Metrics Insights SQL syntax, including WHERE and ORDER BY clauses. You can now filter metrics by dimension values — for example, isolating metrics for a specific ALB target group, EC2 instance, or EKS namespace — directly in the query field. This is particularly useful for Continuous Verification comparisons: configure separate metric definitions with WHERE clauses targeting each group's dimensions to compare control and test traffic during blue/green or canary deployments. Learn more about CloudWatch health sources →

‍

‍

GitOps

Application Rollback

You can now roll back a GitOps application to a previous deployment directly from the Harness UI. A new History & Rollback tab on the application details page shows the full deployment history and lets you select a version to roll back to. Rollback is also available as a dedicated pipeline step, making it composable with approval gates and automated verification in your GitOps pipelines. Learn more about syncing and rolling back GitOps applications →

Applications in Any Namespace

GitOps now supports Applications in Any Namespace. When you configure a cluster-scoped agent, you can specify applicationNamespaces to allow ArgoCD Application resources to be created in namespaces outside the agent's install namespace. This removes a longstanding constraint for multi-tenant clusters where different teams need application isolation without per-team agents. Learn more about applications in any namespace →

Force-Delete Unreachable Applications

You can now force-delete a GitOps application from Harness when the underlying ArgoCD application is unreachable — for example, when the agent or ArgoCD project has been deleted. The Delete from Harness option removes the application record without requiring connectivity to the agent, unblocking cleanup workflows that previously got stuck when infrastructure was partially torn down. Learn more about managing GitOps applications →

Fine-Grained RBAC for Application Resource Actions

GitOps now enforces finer-grained RBAC, separating application-level operations (create, edit, delete) from Kubernetes resource actions (sync, restart, delete pod). This lets you grant operators the ability to restart pods or sync applications without granting them the ability to delete the application definition itself — a meaningful privilege boundary in shared platform environments. Learn more about managing GitOps access →

Squash and Merge in PR Pipelines

GitOps PR pipelines now support squash-and-merge when closing a GitOps pull request. Instead of a standard merge commit, Harness will squash all commits on the PR into a single commit before merging, keeping the release repository history clean and readable. This is especially useful for teams with many incremental commits per deployment that want a one-commit-per-release history in their release repo. Learn more about PR pipelines →

Selective Sync for GitOps Applications

The GitOps Sync step now supports selective sync — letting you choose a specific subset of resources to sync rather than syncing all resources in the application. Useful for large applications where you need to apply a targeted change without touching unrelated resources. Learn more about syncing GitOps applications →

Update Release Repo: Succeed When No Files Changed

The GitOps Update Release Repo (URR) step now supports an option to succeed even when no files are changed in the PR. Previously, the step always failed when there was nothing to commit, which blocked pipelines where the deployment state was already current. Teams using URR in pipelines that may or may not produce a change can now configure the step to treat a no-op commit as a success rather than a failure. Learn more about the Update Release Repo step →

Harness AI for GitOps

Harness AI now supports GitOps entities and pipeline stages. When creating or troubleshooting GitOps Applications or ApplicationSets, the AI can diagnose common setup errors and suggest remediations — including manifest syntax errors, incorrect service or environment types, missing GitOps clusters on linked environments, incomplete manifests, and connectivity issues with Git or infrastructure connectors. Learn more about Harness GitOps →

Zero Trust Service for Agent Communication

The GitOps agent now supports the Zero Trust Service (ZTS) for agent-to-SaaS communication, routing task parameters through the ZTS validation flow. This brings GitOps agent communication in line with the Zero Trust security posture available across other Harness services. Learn more about installing the GitOps agent →

ArgoCD 3.3.10 Bundled in GitOps Agent

The GitOps agent now bundles ArgoCD 3.3.10 (upgraded through the quarter from 3.3.9), incorporating the latest security fixes, stability improvements, and Helm and Kustomize updates from the ArgoCD project. Learn more about the GitOps agent →

‍

Repository Templates Across Scopes

You can now select repository templates from different scopes (account, organization, or project) when configuring GitOps repositories. Teams with shared repository templates defined at the account or org level no longer need to duplicate them at the project level to make them available during repository configuration. Learn more about GitOps repository credentials templates →

---

What's Next

Q3 will continue to expand Kubernetes-native deployment capabilities, streamline management of large-scale GitOps setups, and extend AI-assisted operations across more CD workflows. Explore the Harness Developer Hub for full documentation.

‍