Feature Requests

For some reason it seems like deployment type templates are not supported by the move to git operation. Support suggested we get an enhancement request open to get this supported. Technically there's ways to do this by modifying the YAML directly, but we would like this supported natively.

Currently, Harness AI features for Continuous Delivery (CD) on Self-Managed Enterprise Edition (SMP) rely on a fixed external endpoint ( https://harness.openai.azure.com ). For organizations running SMP, particularly in regulated industries or air-gapped/offline environments, this creates a blocker, as security and compliance policies often require the use of internally approved LLMs rather than external SaaS-hosted models. Harness Agents already support a BYOM model via LLM Connectors, allowing teams to connect Anthropic, OpenAI, or Gemini, including self-hosted model endpoints. We would like to see this same capability extended to Harness AI features in CD on SMP, so that teams can: Connect a company-approved or self-hosted LLM for AI-powered root cause analysis and deployment troubleshooting in CD pipelines Use a custom endpoint (e.g., an internal model deployment) via the existing AIModel connector type Maintain full compliance with internal data residency and security policies This would bring SMP customers to feature parity with SaaS for AI-driven CD capabilities, while respecting enterprise governance requirements.

Harness currently supports traffic splitting for Istio when using the sidecar data‑plane mode by configuring Istio VirtualServices with weighted routing rules. Istio now also supports the Kubernetes Gateway API, where traffic routing is defined through HTTPRoute resources and enforced at waypoints in Ambient Mesh. The legacy Istio custom CRDs (e.g., VirtualService, DestinationRule) are now in a frozen status, with no new feature development planned, as the Gateway API has become the standard configuration model. We require Harness to Full support for Gateway API–based traffic management, alongside continued compatibility with the older, now‑frozen Istio CRDs.

Currently, Custom Deployments only support the default Harness Config File Source. We'd like the ability to add a Config File source from Github.

As of now we have JIRA create and update, but, we are looking for an option to query JIRA issues as well. It shall be possible to query and fetch the Jira information for a ticket. Discovery of Jira query step on the information required to be consumed in the subsequent steps

Dynamic, interactive parameters should be added to Harness workflows. This enhancement would allow parameter options to change based on prior selections, creating a more user-friendly and efficient workflow configuration experience. For example, selecting an environment could dynamically populate a list of available services within that environment. This dynamic behavior would reduce errors, streamline complex workflows, and offer a more intuitive way to manage deployments. Like this below jenkins plugin https://plugins.jenkins.io/uno-choice/

When using the ASG Setup and ASG Phased deploys to create new AWS ASGs and scale the new ASG up for a given service wile scaling down the old one, the old ASG is left around scaled down to 0. We should have the option to have the old ASG deleted instead of just scale down to 0. Currently to achieve this it seems we need a script step and run some code to achieve this.

Basically, In CI Pipelines we observe that the test results will be published to the Tests tab. Likewise, we need to have the same for CD Pipeline also. But in one of the CD pipeline I'm unable to publish the test results to the Tests tab even after using right plugin. Enable the right feature request to publish the test results (Ex: JUnit XML from .NET Smoke Tests) in Tests tab of CD pipelines.

We currently maintain two sets of charts, one for an air gap environment and the other for our public cloud deployments. The Helm Chart for airgap uses helm hooks to deploy. The Helm chart in the public cloud has lifecycle jobs that runs to facilitate the same behavior as the hooks. When I make a change to the Helm Chart for airgap, I have to write code for the Helm Chart for public cloud deployment to perform the same hook functionality.

OPA allows us to set policies against scripts that are inline (e.g. RUN or Shell Script) but we cannot evaluate against FileStore objects. We would like a method to be able to do this so that we can evaluate for any non-compliant scripts at any level.