Feature Requests

Anonymous

Feature Requests for Harness. Select 'Category' based on the module you are requesting the feature for.
Policy as Code: Run IaCM OPA policy evaluation as its own pipeline step, separate from the plan step
Current behavior In IaCM pipelines, OPA policies are evaluated as a post-plan hook (afterTerraformPlan). They run inside the same step as terraform plan / tofu plan, as soon as the plan finishes. That same step does two jobs: it generates the plan and evaluates it against every policy set in scope. Problems Hard-to-read logs. Plan output and policy evaluation output share one console log. For large plans, reviewers have to scroll through thousands of plan lines to find the policy results, or the plan changes past the policy output. It's hard to review either one. Plan steps sized for the peak. The plan step's container needs enough CPU and memory for both plan generation and OPA evaluation of the full plan JSON. Every plan step has to be sized for that combined peak, even though the two jobs never run at the same time. For workspaces with large plans or many policies, that means raising workspace-wide resource limits, which affects every run of the workspace, not just policy evaluation. Request Make policy evaluation a separate step that runs after the plan step, in its own container. Its own step: in the pipeline graph and execution view, with its own console log, status and duration. Its own resources: configurable separately from the plan step, so each step can be sized for its own work. Same inputs as today: it consumes the plan output (plan JSON) produced by the plan step. Same outcome as today: a deny policy still blocks the pipeline before apply, and warnings are still reported. Ideally, backward compatible: an opt-in setting per pipeline or workspace, or a new step type, so existing pipelines keep working unchanged. Business impact Faster, more reliable reviews. Plan and policy results can be read, linked to and shared on their own, which speeds up change review and incident investigation. Lower resource cost. Plan steps no longer carry OPA's memory and CPU. Resources can be sized per step instead of for the worst case. Clearer failures. A policy failure shows up as a failed policy step, not a failed plan step, so users and automation can tell "the plan failed" from "a policy blocked the change". Scales with policy adoption. As organizations add more policy sets, evaluation cost grows without making every plan step bigger.
0
·
IACM
Support Account-Level Pod Spec Overlay Configuration for IaCM Kubernetes Execution Pods
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.
1
·
IACM
·
under review
Deployment Freeze Windows for IaCM (Infrastructure as Code Management)
Problem IaCM currently has no equivalent of CD's Deployment Freeze Window. Freeze windows today can only be configured for CD modules (services/environments) — there's no option to freeze IaCM workspaces/pipelines. Customer use case Twilio periodically performs maintenance on Harness delegates (destroying and recreating them), during which delegates are unavailable for ~1 hour. Their IaCM pipelines (plan/apply) depend on those delegates, so any pipeline triggered during that window fails. They want a way to prevent IaCM pipelines from being triggered while delegate maintenance is in progress — i.e., a scheduled freeze window scoped to IaCM workspaces/pipelines, matching the capability CD already has. Current workarounds: OPA + Manual Approval gates — requires custom policy authoring per workspace/pipeline; not a first-class scheduled freeze. Queue + Barrier steps with Approvals — same limitation; approval-based, not time-window-based, and puts the onus on manual intervention during the freeze rather than blocking automatically. Manually locking the workspace — only viable if the freeze is workspace-scoped, and requires manual toggling before/after every maintenance window rather than a scheduled window. None of these give a native, scheduled "no pipelines will run in this window" guarantee the way CD's freeze feature does. Ask Add Deployment Freeze Window support for IaCM, scoped at the workspace (and ideally pipeline/org/project) level, consistent with the existing CD freeze window model — so customers doing infra/delegate maintenance can block plan/apply execution for a defined time range without custom OPA policies or manual gating.
0
·
IACM
IACM Workspaces: Support Docker Registry as an Alternative TF/OpenTofu Source (Instead of GitHub Clone)
Description: Infrastructure as Code Management (IACM) workspaces currently source their Terraform/OpenTofu code exclusively via git clone from a GitHub repository, with the working directory determined by the configured base_path. This creates a hard dependency on GitHub access for every plan/apply run. We request support for a Docker registry as an alternative source for a workspace’s TF/OpenTofu code, in place of the GitHub clone step. In this model: The IaC source code is packaged into a Docker image as part of a CI process. The IACM workspace is configured to pull its TF/OpenTofu code from that image in a registry, rather than cloning a git repo — using an image-internal path analogous to today’s base_path. This should be additive: workspaces should be able to choose “Git” or “Docker Image” as their source type, with git-based cloning remaining fully supported and unchanged for existing workspaces. The detection/trigger mechanism for new image pushes (webhook, polling, etc.) is left to Harness to decide. Business Impact: Works in air-gapped / restricted-network environments: Enables IACM to provision infrastructure where the execution runner has no access to GitHub at all, only to an internal/private container registry. Immutable, versioned execution: Running against a pinned image tag rather than a live branch/commit eliminates drift between what was reviewed/built and what actually gets applied. Removes GitHub as a single point of failure: If GitHub is unavailable or unreachable, provisioning can still proceed as long as the registry is reachable.
0
·
IACM
IACM Workspace Templates: Support Granular Field Overrides for Git and Workspace 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.
1
·
IACM
·
under review
IACM Module: Native Support for Platform Git Experience (Git-Backed Entities)
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.
1
·
IACM
·
under review
Load More
→