Feature Requests

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.

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: The Harness IACM Module Registry provides an automated Onboarding Pipeline capability, which allows platform teams to automatically generate testing, validation, and publishing pipelines when adding new IaC modules. However, the Provider Registry currently lacks this functionality, requiring engineers to manually build, configure, and maintain individual pipeline definitions to publish and validate custom or private IaC providers. We request native support for Default Onboarding Pipelines within the IACM Provider Registry. Adding a new cloud or infrastructure provider should trigger or allow auto-generation of a standard onboarding pipeline to handle security scanning, binary validation, documentation compilation, and version publishing. Business Impact: Operational Efficiency: Streamlines the onboarding process for custom and private providers, eliminating repetitive manual pipeline construction by platform engineers. Standardized Security & Compliance: Guarantees that every provider published to the internal registry undergoes automated security checks, signature verifications, and compliance scans before availability. Feature Parity: Delivers consistency across registry workflows in the IACM platform by aligning Provider Registry governance directly with existing Module Registry capabilities.

Description: Harness Platform provides a native Git Experience (GitX) across key modules (such as CD, Continuous Integration, Internal Developer Portal, and OPA Policies), allowing configuration entities like Pipelines, Input Sets, Services, and Templates to be defined remotely and stored in Git repositories as code. However, IACM module entities—specifically Workspaces—currently lack native Git Experience support and must be defined inline within the Harness UI/API. We request full Git Experience integration for IACM resources, enabling IACM Workspaces (and related entities like Variable Sets) to be declared and maintained as remote YAML files stored directly in Git repositories. This includes bi-directional synchronization, branch management, and support for automated pull request workflows for workspace creation and updates. Business Impact: GitOps Alignment & Everything-as-Code: Enables platform teams to manage Harness IACM workspace definitions alongside application and pipeline code using standard Git workflows (pull requests, peer reviews, versioning). Automated & Programmatic Onboarding: Eliminates manual UI-based workspace provisioning, allowing platform engineers to generate and update workspace configurations dynamically via standard CI/CD and templating tools. Auditability & Drift Control: Provides a clear, historical version history in Git for all workspace modifications, governance settings, and state configurations.

Description: Currently, IACM workspaces and Harness projects are bound to the specific parent structure in which they were created. As enterprise organizational structures evolve, teams restructure, or governance models shift, there is no direct mechanism to migrate an existing workspace to a different project, or to move an entire project (and its underlying resources) to a different organization within the platform. Building upon planned architecture updates to support multi-level project hierarchies (such as flexible parent_id properties for projects), we request the ability to: Dynamically update a project's parent_id (or target organization identifier) to migrate a project and its nested entities between organizations. Dynamically re-assign or migrate an IACM workspace from one project to another without destroying state, execution history, or resource mappings. Business Impact: Operational Agility: Allows platform and DevOps teams to align Harness project structures with shifting company org charts, acquisitions, or team realignments without costly rebuilds. Reduced Risk & Downtime: Replaces complex, manual recreate-and-migrate workarounds (which risk state file corruption or lost execution history) with safe, native administrative operations. Administrative Efficiency: Drastically lowers the administrative overhead required to maintain clean resource governance and access control models across large-scale enterprise deployments.

Description: Infrastructure as Code Management (IACM) workspaces currently trigger auto-execution pipelines based on changes within the defined base_path. However, modern IaC architecture frequently relies on external, shared dependencies located outside the primary workspace directory—such as centralized module templates, global variables, shared policy definitions, or cross-environment YAML configurations. We request the ability to specify a list of "Watched Directories" or "Additional Trigger Paths" for an IACM workspace alongside the base_path. When a commit modifies files within any of these specified paths, the workspace should automatically detect the change and trigger the execution pipeline (e.g., plan/apply). Business Impact: Risk Mitigation: Eliminates the risk of configuration drift or undetected failures caused by unapplied changes to shared configurations and modules. Operational Efficiency: Removes the need for manual, error-prone pipeline triggers or complex custom webhook workarounds whenever common modules or shared configs are updated. Scalability: Enables standardized, DRY (Don't Repeat Yourself) infrastructure repository layouts across enterprise teams without sacrificing automated continuous integration and delivery.

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.