Terraform Provisioning Overview
Provision infrastructure using Terraform in Harness.
Harness supports Terraform as an infrastructure provisioner. You can use Terraform configuration files to provision infrastructure as part of your deployment process.
Harness can provision any resource that is supported by Terraform. You can provision target deployment infrastructure dynamically, run ad hoc provisioning tasks, or integrate with Terraform Cloud and Enterprise workspaces.
What you will learn from this topic
How to choose between ad hoc and dynamic provisioning modes for Terraform in Harness.
How to use Terraform steps to plan, apply, destroy, and rollback infrastructure in your pipelines.
How to install Terraform on delegates for local execution.
How to integrate Terraform Cloud and Enterprise workspaces with Harness.
Before you begin
Harness project access: View, Create/Edit, and Execute permissions on Pipelines, Environments, and Infrastructure Definitions. For more information, refer to RBAC in Harness to configure roles.
Git connector: A Harness Git connector pointing to your repository containing Terraform configuration files. For more information, refer to Git connector settings reference to configure the connector.
Harness Delegate: A delegate installed in an environment that can connect to your infrastructure. For more information, refer to Delegate installation overview to install a delegate.
Terraform installation: Terraform must be installed on the delegate for local execution. For more information, refer to Build custom delegate images with third-party tools to install Terraform.
Terraform configuration files: Terraform
.tffiles that define the resources to provision.
Provisioning modes
Harness supports two Terraform provisioning modes:
Ad hoc provisioning: Provision infrastructure as a standalone task without deploying an application in the same flow.
Dynamic provisioning: Provision the target infrastructure and deploy your application to it in the same stage.
The pipeline steps are configured the same way for both modes. Choose the mode that matches your goal: use ad hoc provisioning to manage infrastructure on its own, and dynamic provisioning to provision and deploy in one stage.
For more information, refer to Provisioning overview to understand Harness provisioning concepts and use cases.
Ad hoc provisioning
Ad hoc provisioning lets you provision infrastructure as a standalone workflow without deploying an application in the same flow. This mode is useful to create test environments, set up shared resources, or make infrastructure changes independently of application deployments.
For ad hoc provisioning, add Terraform steps (Plan, Apply, Destroy, Rollback) to the Execution section of a CD Deploy stage. The steps provision your resources when the stage runs.
Example use cases:
Provision a shared VPC, subnets, and security groups that other pipelines consume.
Stand up a temporary test environment for validation, then destroy it in a later step.
Run a one-time infrastructure change defined in Terraform configuration files.
Dynamic provisioning
Dynamic provisioning lets you provision the target infrastructure and deploy your application to it in the same stage. For dynamic provisioning, add Terraform steps to the Environment section of a CD Deploy stage and map the Terraform outputs to the Infrastructure Definition. Harness then deploys your application to the provisioned infrastructure in the same stage.
Dynamic provisioning uses your Terraform scripts to provision the target deployment infrastructure for the current pipeline stage. Dynamic provisioning with Terraform is supported for most Harness integrations. The steps required for each integration are covered in their documentation.
Example use cases:
Provision a Kubernetes namespace and deploy your application to it in a single pipeline.
Create ephemeral infrastructure per pull request, deploy to it, and tear it down afterward.
Provision cloud infrastructure and deploy your application in one automated flow.
For detailed steps on configuring dynamic provisioning, refer to Provision infrastructure dynamically with Terraform.
Limitations
Infrastructure provisioning is limited to what is available in the target environment.
For example, the cloud-agnostic Kubernetes infrastructure requires that you have an existing cluster, so you cannot provision a new cluster. But it does let you provision a namespace.
The Google Kubernetes Engine infrastructure option lets you provision a cluster and namespace.
Terraform steps
Harness provides the following Terraform steps for your CD pipelines:
Terraform Plan: Previews infrastructure changes before applying them. For more information, refer to Plan Terraform provisioning with the Terraform Plan step.
Terraform Apply: Creates or updates infrastructure based on Terraform configuration files. For more information, refer to Provision with the Terraform Apply step.
Terraform Destroy: Removes provisioned infrastructure. For more information, refer to Remove infrastructure with the Terraform Destroy step.
Terraform Rollback: Reverts to a previous Terraform state. For more information, refer to Rollback infrastructure with the Terraform Rollback step.
Install Terraform on delegates
Terraform must be installed on the delegate to use local Terraform configuration files in Harness Terraform steps.
You can install Terraform manually or use the INIT_SCRIPT environment variable in the Delegate YAML.
For more information, refer to Build custom delegate images with third-party tools to install Terraform on delegates.
The Harness Delegate uses RedHat Universal Base Image (redhat/ubi8). The following example script installs Terraform 1.9.8 (current stable release as of January 2026):
Terraform Cloud and Enterprise
In addition to running Terraform configuration files locally on the Harness Delegate, Harness supports running Terraform Cloud and Enterprise workspaces.
There are two ways you can run Terraform Cloud and Enterprise workspaces:
API-driven workflow: Use Terraform Cloud or Enterprise as a backend for state management while running Terraform commands on the Harness Delegate. This approach uses standard Terraform steps (Plan, Apply, Destroy, Rollback) and stores state in Terraform Cloud or Enterprise. The delegate runs the Terraform commands and communicates with Terraform Cloud or Enterprise to store and retrieve state.
VCS-driven workflow: Trigger Terraform Cloud or Enterprise workspace runs directly from Harness. This approach uses the Terraform Cloud Run step to trigger runs in your Terraform Cloud or Enterprise workspaces. The workspace is connected to a VCS repository, and Terraform Cloud or Enterprise runs the Terraform commands.
Harness provides dedicated steps for Terraform Cloud and Enterprise workflows:
Terraform Cloud Run: Triggers a run in your Terraform Cloud or Enterprise workspace and monitors the run status.
Terraform Cloud Rollback: Rolls back to a previous run state in your Terraform Cloud or Enterprise workspace.
For more information, refer to Terraform Cloud deployments to integrate with Terraform Cloud and Enterprise workspaces.
Terraform logs
All logs produced by Terraform are printed in Harness step execution logs. Logs from stdout are printed as they are, and logs from stderr are printed in red.
Next steps
Explore these related topics for more details on Terraform provisioning in Harness.
Provision infrastructure dynamically with Terraform: Provision target deployment infrastructure in pipeline stages.
Terraform Cloud deployments: Integrate with Terraform Cloud and Enterprise workspaces.
Provisioning overview: Understand other provisioning options available in Harness.
Last updated
Was this helpful?