dflook/terraform-apply

Apply a Terraform plan

Trust Signals

Scorecard Score: not yet scored
Maintenance Recency: Maintainedlast commit Jan 13, 2026
License: None

Pinned Snippet

workflow.ymlSHA-pinned

uses: dflook/terraform-apply@5489b988934a50bf1489d5b7c5253b46520a7dca # v2.2.3

tags can be moved; commit SHAs can't. why a SHA?

Inputs

name	description	required	default
path	Path to the Terraform root module to apply	no	.
workspace	Terraform workspace to run the apply in	no	default
label	A friendly name for the environment the Terraform configuration is for. This will be used in the PR comment for easy identification. It must be the same as the `label` used in the corresponding [`dflook/terraform-plan`](https://github.com/dflook/terraform-github-actions/tree/main/terraform-plan) action.	no	""
variables	Variables to set for the terraform plan. This should be valid Terraform syntax - like a [variable definition file](https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files). Variables set here override any given in `var_file`s.	no	—
var_file	List of tfvars files to use, one per line. Paths should be relative to the GitHub Actions workspace	no	—
backend_config	List of Terraform backend config values, one per line.	no	""
backend_config_file	List of Terraform backend config files to use, one per line. Paths should be relative to the GitHub Actions workspace	no	""
replace	List of resources to replace, one per line.	no	""
target	List of resources to apply, one per line. The apply operation will be limited to these resources and their dependencies.	no	""
destroy	Set to `true` to destroy all resources. This generates and applies a plan in [destroy mode](https://developer.hashicorp.com/terraform/cli/commands/plan#planning-modes).	no	false
refresh	Set to `false` to skip synchronisation of the Terraform state with actual resources. This will make the plan faster but may be out of date with the actual resources, which can lead to incorrect plans.	no	true
plan_path	Path to a plan file to apply. This would have been generated by a previous [`dflook/terraform-plan`](https://github.com/dflook/terraform-github-actions/tree/main/terraform-plan) action. The default behaviour when this is not set is to generate a plan from the current configuration and compare it to the plan attached to the PR comment. If it is logically the same, the plan will be applied. When this is set to a plan file, the plan will not be generated again. If it is the exact same plan as the one attached to the PR comment, it will be applied. This will be faster than generating a new plan. There are downsides to applying a stored plan: - The plan may contain sensitive information so must be stored securely, possibly outside of GitHub. - It does not account for any changes that have occurred since it was generated, and may no longer be correct. - Plans must be generated and applied in strict order. Multiple open PRs will cause conflicts if they are applied out of order. - Plans are not portable between platforms. - Terraform and provider versions must match between the plan generation and apply. When `auto_approve` is set to `true`, the plan will be applied without checking if it is the same as the one attached to the PR comment.	no	""
auto_approve	When set to `true`, plans are always applied. The default is `false`, which requires plans to have been added to a pull request comment.	no	false
parallelism	Limit the number of concurrent operations	no	0

Outputs

name	description
json_plan_path	This is the path to the generated plan in [JSON Output Format](https://www.terraform.io/docs/internals/json-format.html). The path is relative to the Actions workspace. Terraform plans often contain sensitive information, so this output should be treated with care. This won't be set if the backend type is `remote` - Terraform does not support saving remote plans.
text_plan_path	This is the path to the generated plan in a human-readable format. The path is relative to the Actions workspace. This won't be set if `auto_approve` is true while using a `remote` backend.
failure_reason	When the job outcome is `failure`, this output may be set. The value may be one of: - `apply-failed` - The Terraform apply operation failed. - `plan-changed` - The approved plan is no longer accurate, so the apply will not be attempted. - `state-locked` - The Terraform state lock could not be obtained because it was already locked. If the job fails for any other reason this will not be set. This can be used with the Actions expression syntax to conditionally run steps.
failure-reason	When the job outcome is `failure`, this output may be set. The value may be one of: - `apply-failed` - The Terraform apply operation failed. - `plan-changed` - The approved plan is no longer accurate, so the apply will not be attempted. - `state-locked` - The Terraform state lock could not be obtained because it was already locked. If the job fails for any other reason this will not be set. This can be used with the Actions expression syntax to conditionally run steps.
lock_info	When the job outcome is `failure` and the failure_reason is `state-locked`, this output will be set. It is a json object containing any available state lock information and typically has the form: ```json { "ID": "838fbfde-c5cd-297f-84a4-d7578b4a4880", "Path": "terraform-github-actions/test-unlock-state", "Operation": "OperationTypeApply", "Who": "root@e9d43b0c6478", "Version": "1.3.7", "Created": "2023-01-28 00:16:41.560904373 +0000 UTC", "Info": "" } ```
lock-info	When the job outcome is `failure` and the failure_reason is `state-locked`, this output will be set. It is a json object containing any available state lock information and typically has the form: ```json { "ID": "838fbfde-c5cd-297f-84a4-d7578b4a4880", "Path": "terraform-github-actions/test-unlock-state", "Operation": "OperationTypeApply", "Who": "root@e9d43b0c6478", "Version": "1.3.7", "Created": "2023-01-28 00:16:41.560904373 +0000 UTC", "Info": "" } ```
run_id	If the root module uses the `remote` or `cloud` backend in remote execution mode, this output will be set to the remote run id.
json_output_path	This is the path to all the root module outputs in a JSON file. The path is relative to the Actions workspace. For example, with the Terraform config: ```hcl output "service_hostname" { value = "example.com" } ``` The file pointed to by this output will contain: ```json { "service_hostname": "example.com" } ``` Terraform list, set and tuple types are cast to a JSON array, map and object types are cast to a JSON object.