Feature Requests

Developer experience would be improved if there was a simple way for environmental variables to persist across steps in a stage. Right now we frequently have to set the same variables for each step which are outputs from a first step. This is very repetitive and can be prone to mistakes if you start involving expressions. as a specific example, we assume a AWS role and have to add the AWS environmental credential variables to each subsequent step that uses it. this is inconvenient and repetitive when setting up pipelines. It's also not fun to have to deal with those output expressions. Some more user-friendly way to persist these or set once would improve dev experience. especially if it can be set from within a template so that it's just plug and play

Currently the K8 manifest sources does not list S3 as an option, due to this we are not able to use s3 as manifest source in k8 deployment. This enhancement request is to support s3 as manifest source for k8 manifests.

Currently, AWS CDK steps (e.g., synth and deploy) in Harness CD pipelines can only run as Containerized Steps, which require a Kubernetes-based Delegate runtime. Customers running Delegates in Amazon ECS environments would like the ability to execute AWS CDK steps using their ECS-based Delegates instead of needing a Kubernetes setup. Feature Request: Expand Containerized Step support for AWS CDK to include non-Kubernetes runtimes, specifically Amazon ECS. Use Case: We operate Delegates as part of our ECS services and prefer to continue leveraging ECS for consistency, operational simplicity, and cost management. Requiring Kubernetes-based Delegates introduces unnecessary infrastructure overhead solely to run CDK-based deployment steps. Requested Enhancement: Enable AWS CDK steps (e.g., synth, deploy) to run on ECS-based Delegates

Helm Services currently support multiple manifests but, K8s services do not. We'd like the ability to add multiple manifests to our Services so we can select them at run time or use an expression to dynamically switch them.

Filtering pipeline executions by notes will offer users great flexibility as they can update notes in runtime with arbitrary metadata that later can be used as search criteria

Currently helm lint feature is not available out of the box and users have to rely on the hooks on the service to lint the helm chart that requires custom scripting. This request is to have helm lint support for helm services (Both native helm and K8s) in harness.

Please add support for specifying a CloudFormation StackPolicyBody when creating or updating stacks via Harness. This would allow us to apply stack policies that prevent accidental replacement or deletion of critical resources (such as DynamoDB tables) during updates, providing an important safeguard for infrastructure managed through Harness pipelines.

As a user, want to be able to select "All Environments" option in the deploy stage inputs, just like "All Infrastructures" while executing the pipeline.

Currently, in the advanced options of the monitored service, when adding fail-fast or ignore thresholds, the percentage value is capped at 100. This limitation is too restrictive for real-world use cases where we need to configure thresholds with much higher values, such as 1500 or even greater. Requested Enhancement: Remove the 100% upper limit for fail-fast threshold values Remove the 100% upper limit for ignore threshold values Allow users to specify arbitrary percentage values to accommodate various monitoring scenarios and metric scales

Enable native progressive/gradual rollout capabilities within Harness CD that allow users to deploy new application versions incrementally using percentage-based phasing (e.g., 10% → 25% → 50% → 100%) with manual or automated verification gates between phases. Unlike the current canary deployment approach which adds new instances alongside existing ones, this feature would progressively replace existing pods/instances with new versions, giving users fine-grained control to pause, validate, and resume deployments at each phase without doubling infrastructure resources.