Q3 FY27 Product Update: Harness Deployments | Harness Blog

Welcome back to the quarterly update series! If you've been following along, you've seen how Q1 brought AI-powered continuous verification and broader deployment platform support, and how Q2 added progressive Kubernetes canary rollouts and native AI agent deployments. Q3 FY27 builds on these foundations with Helm v4 and a Helm Dry Run step, live cluster and pod visibility for Kubernetes, new ASG and ECS deployment options, import and gateway support for AI agents, more AI Verify health sources, and onSave OPA policies for Git-backed CD entities, giving you more visibility and control over how every release rolls out and rolls back.

Kubernetes and Helm

Better previews, better visibility into your clusters, and more control over what gets deployed.

Cluster view for Kubernetes

See live resources, health, and deployment history for your Kubernetes clusters without leaving Harness. Enable Cluster Discovery in a static infrastructure definition with a fixed namespace, and the K8s Resources tab shows each resource's readiness and the deployments that touched it. Discovery is read-only.
Learn more

Pods tab on pipeline executions

Rolling, Canary, and Blue/Green steps now list pod status, events, and logs on a Pods tab, even after Kubernetes deletes the pod. Data is kept for 7 days.
Learn more

Direct link to the K8s Diff tab

Add tab=K8S_DIFF_VIEW to a step's URL to open its K8s Diff tab directly. This is ideal for approval messages because it takes reviewers straight to what will change before they approve. Learn more

Git Fetch Type as a runtime input

Choose Latest from Branch or a Specific Commit ID at deployment time by setting Git Fetch Type to Runtime Input. Learn more

Kubernetes Gateway API in Traffic Routing

The Kubernetes Traffic Routing step now supports the Kubernetes Gateway API as a routing provider. Harness shifts weighted traffic by updating an HTTPRoute on a Gateway you already own; the same configuration applies to Canary, Progressive Canary, and Blue/Green. Enabled through Harness Support.
Learn more

Helm v4 support

Choose Helm v4 as the deployment engine by setting the Helm Version to Version 4 on a service's manifest. Harness converts deprecated v3 flags such as --atomic to their v4 equivalents, so existing services keep working.
Learn more

Helm Dry Run step

A new Native Helm step previews rendered manifests, hooks, and notes without changing the cluster, using helm upgrade --install --dry-run. Pair it with an Approval step before Helm Deploy.
Learn more

AWS

More control over Auto Scaling Group and ECS deployments, from scale-out readiness to cleanup after a traffic shift.

Warm pools for ASG deployments

Add a warmPool block to the ASG Additional Configuration manifest to keep pre-initialized EC2 instances ready for scale-out, so new capacity is available faster when the group grows.
Learn more

Standby and scale-in protected instances in ASG Rolling Deploy

These AWS instance refresh options control how standby and scale-in protected instances are handled during a rolling update. The ASG Rolling Deploy step now supports both, and rollback reuses them.
Learn more

Delete old ASG after Blue-Green

A new Delete old ASG option permanently deletes the old Auto Scaling Group after Harness downsizes it to zero (requires Downsize old ASG). Rollback cannot restore a deleted ASG. Enabled through Harness Support.
Learn more

Phased rollback for ASG canary

If a canary phase fails, Harness rolls back only the phases already deployed, optionally in batches, as specified by batchSize or batchPercentage.
Learn more

Multiple ALB listener rules for ECS Blue-Green

Set several production listener rules by listing their ARNs, each with an optional stage target group. Harness shifts traffic on all of them together, so every production listener stays in step during a Blue-Green swap.
Learn more

Downsize old ECS service after traffic shift

ECS Blue-Green can scale the old service to zero once 100% of traffic has shifted, with an optional delay, so idle containers stop accruing cost. Rollback restores the old service. Enabled through Harness Support.
Learn more

CloudWatch alarm management for ECS scaling

Declare a CloudWatch alarm as an ECS CloudWatch Alarm manifest and link it to a step-scaling policy. Harness creates the alarm on deploy and manages it through rollback, so the alarm and its scaling policy stay consistent with the deployment.
Learn more

AI Agent Deployments

More ways to bring AI agents under the same delivery workflows as the rest of your services.

Import an existing AI agent

Bring an agent already running on Google Agent Runtime or AWS Agent Core under Harness as an Agent Service without redeploying it, then manage, promote, and roll it back through pipelines.
Learn more

AgentCore Gateway management

Harness can now create and manage the AgentCore Gateway for AWS Agent Core deployments, enabling weighted canary traffic shifts between live and candidate endpoints. Without a gateway, each deploy is a direct cutover.
Learn more

S3 as the agent zip source

Reference an agent package stored in an S3 bucket by setting the artifact type to S3 Direct Code, then enter the bucket, object key, runtime, and entry point. You can pin an optional version ID so an overwritten object does not cause drift.
Learn more

Agent identity for AWS Agent Core

Control who can invoke your agent runtime with an agent authorizer: AWS_IAM for SigV4-signed callers or CUSTOM_JWT for OIDC and OAuth tokens. Restrict invocation of Gateway limits to the AgentCore Gateway.
Learn more

Verification

More health sources and tighter control over how AI Verify judges a deployment.

Configurable sensitivity for AI Verify v2

Set sensitivity to High, Medium (default), or Low to control how strictly AI Verify v2 flags deviations from the baseline. Clear deployment-blocking errors are always reported.
Learn more

New Relic metrics health source

AI Verify v2 can now collect metrics from New Relic, using a connector and an NRQL query that returns a time series. Map the metric value, timestamp, and service instance identifier from the response.
Learn more

Splunk Logs health source

AI Verify v2 can now collect logs from Splunk, using a connector and a query that returns individual events. Map the timestamp, service instance, and message fields from the response.
Learn more

Custom Health source for logs and metrics

Collect logs and metrics from any HTTP-accessible monitoring tool, such as a self-hosted OpenSearch, through a Custom Health connector. Log and metric sources can be mixed in one step.
Learn more

No Data fail-fast in AI Verify v1

Stop verification right away when a metric returns no data by adding a Fail-Fast Threshold with the No Data criterion, so broken queries surface early. For logs, a per-query Fail Fast toggle fails on unknown clusters.
Learn more

OIDC authentication for CloudWatch health sources

Use short-lived OIDC tokens instead of stored access keys for CloudWatch Logs and Metrics health sources by selecting an AWS connector that uses OIDC credentials. This keeps long-lived keys out of your verification setup.
Learn more

AI Verify (v2) feedback on log analysis

Give plain-language feedback on a log cluster, or on the whole run, from View Analysis, and Harness applies it to later verifications of the same service and environment. The run you commented on is never changed.
Learn more

Steps and Connectors

Fewer custom scripts and tighter credential scoping.

Authentication options in the HTTP step

The HTTP step now supports Basic, Bearer Token, and API Key authentication, so you no longer add headers or Base64-encode credentials by hand. Credentials are stored as Harness secrets.
Learn more

Download Nexus Artifact step

Download raw, Maven, npm, or NuGet assets from Nexus 3.x in a containerized step group, with checksum validation and no custom plugin.
Learn more

Enhanced Subject Identifier for Azure OIDC

Add account, organization, project, or pipeline IDs to the OIDC token subject (the sub claim) to scope Azure access more narrowly.
Learn more

Jenkins jobs in folders now load

The Jenkins Build step now loads jobs within folders without the UI freezing. Select a folder in Job or folder name, then pick the job inside it or search by name.
Learn more

Extended Choice Parameters for Jenkins jobs

The Jenkins Build step now supports Extended Choice Parameters, so you can pass multiple values to a parameter when you run a job. This makes Jenkins jobs that rely on multi-select parameters usable from CD pipelines.
Learn more

Governance

onSave OPA policies on Git-backed CD entities

Harness now enforces OPA policies onSave for services, environments, infrastructure definitions, and overrides committed directly to Git. If the latest commit fails a policy, pipeline steps that use the entity are blocked until a compliant commit clears it. Requires a GitX webhook and enablement through Harness Support.
Learn more

Freeze windows for individual infrastructure definitions

Scope a freeze window to selected infrastructure definitions, or match them with an expression, so only that part of an environment is frozen. This gives finer control than freezing a whole environment, for example during maintenance on a single cluster.
Learn more

What's Next

We are continuing to invest in Kubernetes and Helm, AWS, AI agent deployments, and AI-assisted verification. To explore everything Continuous Delivery offers today, head to the Harness documentation.

Get Started

Explore the documentation linked above for each feature, or reach out to your Harness account team to see these capabilities in your environment.