Feature Requests

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: 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.

Description: When executing IACM pipelines across multiple workspaces (e.g., via matrix, looping, or multi-workspace execution steps), a pipeline failure in one workspace currently requires re-running the entire pipeline for all targeted workspaces. We request the ability to selectively retry/re-run only the failed workspace steps or failed iterations within a multi-workspace pipeline run, while skipping or preserving the successful execution state of the workspaces that passed. Business Impact: Cost & Time Efficiency: Significantly reduces total pipeline execution duration and resource consumption by preventing unnecessary, repetitive executions on workspaces that have already succeeded. Developer Productivity: Enables engineers to quickly fix an issue in a specific failing workspace and re-trigger execution immediately without waiting for long, unchanged multi-workspace plans/applies to complete. Blast Radius Reduction: Decreases unnecessary API calls and state lock operations against cloud providers and external systems by avoiding redundant runs on stable infrastructure.

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: When running IACM pipelines that evaluate Open Policy Agent (OPA) policies across multiple workspaces using matrix runs, loops, or multi-workspace orchestration, the current Policy View interface only retains and displays the OPA evaluation status of the final workspace executed in the sequence. The execution results for preceding workspaces in the same run are not preserved or visible in the UI. We request that the IACM Policy View display historical and granular execution status for every workspace included in a multi-workspace pipeline run. Each workspace's OPA evaluation (Pass, Fail, Warning, or Soft/Hard Mandatory status) should be preserved and accessible independently within the pipeline UI summary. Business Impact: Prevented Security Blind Spots: Ensures policy violations in earlier matrix/loop iterations are not obscured or overwritten by a passing result in the final workspace. Faster Mean Time to Resolution (MTTR): Developers can immediately view policy feedback for all failing workspaces at once, rather than re-running pipelines sequentially to isolate errors. Compliance & Governance: Provides an complete audit trail proving that every targeted workspace—not just the last one processed—successfully met organizational policy standards.

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.

I'd like to be able to set the OpenTofu version of a workspace to be the latest of a given release. For example, if I set the OpenTofu version to ~> 1.11 the workspace should use the latest release of OpenTofu in the 1.11.x releases. This would save me from having to ensure bugfix releases are updated on workspaces while still giving me control over potentially breaking changes.