Feature Requests

After a Terraform, OpenTofu or Terragrunt plan step runs in Harness IACM, there is no way to download the plan from the execution. Users can only view the plan output in the UI. To feed the plan into other tooling, they have to re-run the plan outside Harness or copy the output by hand. Requested feature Add a Download option on the plan step of an IACM pipeline execution that lets users save: the parsed plan (the JSON representation, equivalent to terraform show -json <planfile>) the human-readable plan output Why it matters Teams can keep a record of what was planned before an apply. Debugging and review: engineers can inspect large plans in their own tools and attach them to change tickets or PRs.

For workspaces with many resources, the Resources tab in the pipeline execution view can take a long time to load. Today users only see a generic loading indicator, so they can't tell whether it's working or how long to wait. Supplement the spinner with a progress indicator that shows the percentage of resource data loaded, for example "Loading resources… 45%". Why it matters: Users get an expectation of the wait time and are less likely to assume the page is stuck. They are also less likely to refresh or leave.

Every Harness IaCM workspace produces a Terraform/OpenTofu plan, but users can't see how large it is without digging into logs. Add two pieces of metadata to each workspace: Plan size: the size of the latest plan. Resource count: the number of resources managed by the workspace. These should be exposed as workspace outputs/parameters and shown in the workspace UI. They should also be available through the API. Why it matters: Teams can see at a glance which workspaces have large plans or many resources. Those workspaces are the candidates for modularization or splitting. Large plans also tend to mean slower runs and heavier resource tabs.

Use Case Customers running IaCM pipelines with KubernetesDirect infrastructure need to apply Kubernetes pod-level settings consistently to the build execution pods created for Terraform operations such as Plan and Apply. For example, the customer needs to configure: spec: terminationGracePeriodSeconds: 600 tolerations: - key: "<key>" operator: "Equal" value: "<value>" effect: "NoSchedule" IaCM currently supports podSpecOverlay when it is configured directly on the individual IaCM stage through pipeline YAML: infrastructure: type: KubernetesDirect spec: connectorRef: <connector> namespace: <namespace> podSpecOverlay: |- spec: terminationGracePeriodSeconds: 600 tolerations: - key: "<key>" operator: "Equal" value: "<value>" effect: "NoSchedule" Current Gap We do not want to configure this separately in every IaCM pipeline/stage. For CI, customers can configure a default Pod Spec Overlay centrally under: Account Settings → Default Settings → Pod Spec Overlay We would like equivalent functionality for IaCM so that Kubernetes pod configuration can be defined once at the account level and automatically inherited by temporary IaCM execution pods. Requested Enhancement Add an account-level/default Pod Spec Overlay configuration for IaCM, similar to the existing CI capability. Ideally, customers should be able to define an IaCM Pod Spec Overlay under account settings and have it automatically applied to IaCM KubernetesDirect execution pods, while still allowing stage-level configuration/overrides where appropriate.

Description: IACM Workspace Templates currently lack granular override capabilities for key configuration parameters, particularly Git connection details (such as repository URL, branch, and folder/base path). Because these fields cannot be individually overridden during workspace creation or instantiation, a single template is artificially restricted to a single repository, branch, or directory structure. We request the ability to expose and override individual configuration fields—specifically Git settings (repository, branch, path/folder), environment variables, and execution parameters—when instantiating a workspace from a template. This would allow a single, standardized template definition to be reused dynamically across multiple repositories, environments, and team configurations. Business Impact: Scalability & Reusability: Unlocks true template reusability across enterprise teams, drastically reducing the total number of duplicate templates platform engineers must create and maintain. Standardization with Flexibility: Allows central platform teams to enforce workspace governance and pipeline baselines while giving application teams the flexibility to point to their specific repos, branches, and code paths. Lower Maintenance Overhead: Simplifies platform operations by allowing global configuration updates to be managed in one core template rather than spread across dozens of single-use template variants.

In reference to this feature request: https://ideas.harness.io/feature-request/p/output-terraform-plan-init . I would like to see an option for the full terraform plan output and have it posted to a comment on a pull request. Currently we see something like this: ✅ Terraform plan complete! 🏢 Org: <...> 📖 Project: <...> Workspace: <...> Planned Changes 3 Added ~ 0 Changed ~ 0 Deleted ~ 826 Unchanged ~ 0 Imported ~ 0 Removed The table of planned changes can be viewed in Harness. Outputs No outputs present View details in Harness <--- This is a link to terraform I would like the option to enable full output, or at least some portion of the output if it is a very large plan. For small plans, it would take one less step to review the PR.

Today, IaCM Ansible can only authenticate to target hosts using an SSH private key defined as an inventory variable (ansible_ssh_private_key_file), or WinRM for Windows. This forces us to store and rotate SSH keys in Harness secrets, keep port 22 reachable from the delegate and Ansible container, and maintain inbound security-group rules that allow the delegate's IP range. For teams running on AWS, this is exactly the surface area we're trying to eliminate. We'd like IaCM Ansible to support connecting to EC2 instances through AWS Systems Manager Session Manager, using a Harness AWS Connector as the credential source. This maps to Ansible's built-in community.aws.aws _ssm connection plugin. With SSM, there are no SSH keys to manage, no open port 22, and no inbound security-group rules — instances are reached through the SSM agent and IAM, which also means private instances with no public IP and no bastion become reachable. Concretely, we'd want to select an existing AWS Connector on the inventory (or stage) and have Harness wire its credentials into the Ansible run as the SSM connection, instead of requiring an SSH key. Windows targets managed by SSM would benefit as well. This would make IaCM Ansible a much better fit for security-conscious AWS environments where SSH key distribution and open SSH ports are not acceptable, and it keeps credential management consistent with how the rest of the Harness platform already authenticates to AWS.

Enhance the Harness Workspace variable management experience by adding support for descriptions on variables. This will allow users to provide additional context about the purpose, usage, and expected values of workspace variables, improving readability, maintainability, and collaboration across teams. Requirements Add a Description field when creating or editing workspace variables. Display the description alongside variable details in the workspace UI. Support viewing and updating descriptions for existing variables. Ensure descriptions are stored and retrieved through the corresponding backend APIs. Maintain backward compatibility for variables that do not have descriptions.

The entire ansible-playbook invocation collapses into a single ansible_run step in the graph. A 50-task playbook surfaces as one node with one status. Even when we split a 30-minute "wait for AMI" loop into milestone tasks (25/50/75/100%), the pipe sees one Running for 30 minutes. Operations cannot tell whether the build is on Stage 1 or Stage 4. Ask: Per-task callbacks / progress events on the execution graph.