Feature Requests

The cost forecasting in CCM Budgets currently looks like all it does is add 5-15% for each future month and that's it. There's no variation we're seeing to bring it more in line with historical costs or any alignment, the cost just goes up and that's it so not much is being done there currently. The second (but primary) thing we need is to be able to configure our own values for future forecasting months in budgets.

Request a Harness-supported API endpoint that allows authorized automation to update an SCS license family and manage direct and indirect dependency relationships in a way that is compliant with internal firm standards (e.g., governance, auditability, RBAC, validation, and change controls). Without an API: -Changes are manual, inconsistent, and hard to govern -We cannot enforce required approval, validation, or audit controls -Dependency graph correctness drifts, increasing operational and compliance risk

Description The customer has requested support for pipeline-level execution concurrency limits with execution queueing to better control high volumes of pipeline executions. Use Case The customer's CD pipelines are triggered by AWS Auto Scaling Groups, which can generate a large number of pipeline executions simultaneously. This results in significant delegate resource consumption and increased infrastructure costs. The customer is looking for a mechanism to throttle execution at the pipeline level while ensuring all executions are eventually processed. Requested Functionality Configure a maximum concurrency limit for an individual pipeline. Queue any executions that exceed the configured concurrency limit instead of rejecting or running them immediately. Automatically start queued executions as active execution slots become available. Enhancement Request The customer also requested consideration for a dynamic concurrency model that adjusts the allowed concurrency based on available delegate capacity. Example: 1 delegate → 20 concurrent executions 2 delegates → 40 concurrent executions 3 delegates → 60 concurrent executions This would allow execution throughput to scale automatically with available delegate capacity while preventing sudden execution spikes from overwhelming delegate infrastructure. Customer Benefits Prevent delegate resource exhaustion during traffic spikes. Reduce delegate infrastructure costs. Improve deployment stability during burst workloads. Enable automatic scaling of deployment throughput based on delegate availability.

We are looking for a centralized mechanism within Harness where policy exceptions can be recorded, reviewed/approved with validity periods, and then automatically considered during OPA policy evaluation so that approved exceptions do not result in policy enforcement failures. With this managing and tracking OPA policy exception within the Harness UI would really help to provide better control.

Currently, Overlay Input Sets merge multiple input sets into a single pipeline execution. We would like the option to trigger separate pipeline executions when multiple input sets are selected, allowing the same pipeline to run independently and simultaneously for each input set. This would reduce manual effort, simplify multi-environment deployments, and provide better support for parallel execution use cases while maintaining individual execution tracking and visibility.

We have scenario about repositories type - infra that this repos not exist backend file tf cause this file's buiding in runtime pipeline in github action, we've including this file in runtime before to start terraform plan and apply.

Summary Harness currently lacks a native mechanism to generate ephemeral, short-lived API tokens at pipeline runtime — comparable to GitHub Actions' GITHUB_TOKEN or the OIDC-based tokens available for GCP and Azure in Harness CI. Reviewed Documentation & Why It Is Insufficient API Keys & Token Expiry https://developer.harness.io/docs/platform/automation/api/add-and-manage-api-keys https://developer.harness.io/docs/platform/automation/api/add-and-manage-api-keys#token-expiry Harness allows setting an expiration date (30, 90, 180 days or custom) when creating a token. However, this is a statically configured expiry, not a dynamically generated short-lived token. The minimum API key duration is 30 days. This does not meet the requirement for tokens that are valid only for the duration of a single pipeline run. Delegate Token Revocation Delegate tokens can be created with a revokeAfter epoch timestamp via API. However, this mechanism is scoped to delegate authentication only and is not applicable to general CI pipeline use cases. IDP Create/Delete Secret Pattern https://developer.harness.io/docs/internal-developer-portal/tutorials/using-secret-as-an-input/ The IDP workflow pattern allows creating a Harness secret before a pipeline run and deleting it afterward using harness:create-secret and harness:delete-secret actions. This is a workaround, not a native solution — and explicitly noted in the documentation that if a pipeline step fails, the secret is not automatically cleaned up, requiring manual deletion. Token Rotation [Rotate tokens] Token rotation is a manual process and does not provide runtime-scoped ephemeral tokens. What Is Needed A native Harness CI mechanism to generate a short-lived, pipeline-scoped token at runtime that: Is automatically invalidated when the pipeline run ends. Requires no manual cleanup. Can be used to authenticate against the Harness API within the same pipeline run. Is comparable to GitHub Actions' GITHUB_TOKEN or the existing OIDC plugins for GCP https://developer.harness.io/docs/continuous-integration/secure-ci/gcp-oidc-token-plugin/ and Azure https://developer.harness.io/docs/continuous-integration/secure-ci/azure-oidc-token-plugin/

Our security team has requested that it be recorded in an audit log when a secret is exposed via an export and is visible on the output tab.

For using COSIGN in the SCS module to sign container images and SBOMs, we want to be able to store and source signing keys and certificates from a connected KMS key store.

Currently most everything a pipeline reference can be stored in a git except 2 things. Variables and Overrides V2. I see there is already an RFE for overrides v2 to be backended by git. RFE to allow variables to be stored in git. Now that services are allowed to be stored in git, the variables associated with service are in git. Would request to keep this user experience across the board where variables are first class git citizens