Feature Requests

Hi Harness Team, We’d like to request official support for deploying our applications to VMs that are managed by a Managed Instance Group (MIG) in Google Cloud Platform. Our current architecture uses MIGs to manage VM lifecycles (scaling, self-healing, etc.), and we’re integrating this with Harness for deployment automation. We want to confirm whether this setup — specifically targeting MIG-managed VMs as deployment destinations — is supported. Why This Matters: MIGs are a key part of how we manage our infrastructure in GCP. They help us ensure high availability and consistency at scale, but it’s not clear whether Harness currently supports deploying applications to these instances or if there are recommended patterns we should follow. What We’re Requesting: Official support and documentation for deploying to MIG-managed VMs Clarification on any risks, limitations, or required configurations We’re happy to discuss our use case in more detail if needed. Looking forward to your guidance on how best to proceed.

Customer wanted this functionality :- 1.Let user create a new token with the same name if the prior one is revoked. Only restrict on the same active delegate token name. Delete revoked token immediately and a new token with the same name should be allowed.

Description: Currently, Harness supports inheriting user groups from the account level into the organization-level scope via API (this API is not exposed in public docs). However, this functionality is not yet available through the Harness Terraform provider. To enable infrastructure as code (IaC) best practices and streamline access control configuration at scale, it would be highly beneficial to support this inheritance capability directly in Terraform. This would allow teams to manage user group inheritance declaratively and consistently across environments.

We'd like to see a method where Harness intelligently caches images for Harness-Managed CI processes. For example, there is no reason why if many customers use alpine, or nginx or other images why Harness should not help reduce Rate Limit strain and also speed up processes for their customers by not caching them. This would benefit Harness and their network costs and increase value to customers.

We would like a method to be able to define the notification personnel based on an input or expression. This is so that we can utilize an inputset to change what teams are notified for a pipeline template, depending on where it is used. We utilize the same pipeline template across may teams, and need notifications to go to different teams, depending on where the pipeline is being used. RIght now, the value is "hard coded" so we cannot have the notifications go to different teams.

Hi Harness Team, We’d like to request enhanced support for deploying to VMs in Google Cloud Platform (GCP) using GCP connectors, without requiring direct SSH keys (Linux) or WinRM username/passwords (Windows). Background: In AWS and Azure, Harness supports VM deployments using connectors tied to those platforms, without the need to manually provide OS-level credentials. This improves security posture, simplifies setup, and aligns better with cloud-native identity management. Request: We’re asking for equivalent functionality for GCP — the ability to deploy to GCP VMs (Linux or Windows) via the GCP connector using IAM permissions, metadata APIs, or similar identity-based mechanisms, without the need to configure SSH or WinRM access. Why This Matters: Reduces credential management overhead -Aligns with least-privilege, identity-based access practices Simplifies onboarding and scaling of VM-based deployments This is especially important for organizations standardizing on connector-based integrations and moving away from long-lived OS-level credentials.

Currently, output variables of type Secret are only supported for the Run and Shell Script steps. We'd like this functionality extended to Plugin steps as well. Use Case: We have a plugin that generates a short-lived GitHub token and returns it as an output variable, which subsequent steps in the pipeline use. We're looking for a way to instruct Harness to treat this output as a Secret, ensuring it is masked in logs, UI, and other exposed locations for security purposes.

Our team has had significant issues related to pulling images through Docker Hub. This ticket is being submitted per a request from Harness to do so. We are requesting the "CI_REMOVE_FQN_DEPENDENCY" feature flag to be enabled for account ID: s464IswmR7iEE8qzY-hL1A in the prod2 cluster.

Need a feature on impersonate user for non-admin users

We'd like to be able to utilize Harness Secrets to store the the plan output from Terraform Plan stages in the same way it happens for the Terraform Apply Stage: https://developer.harness.io/docs/continuous-delivery/cd-infrastructure/terraform-infra/run-a-terraform-plan-with-the-terraform-apply-step/#encrypt-the-terraform-apply-json-outputs This is in order to keep things secret and have a consistent behavior between Terraform stages. It is also for us to be able to ingest the values into container step/container step group processes