terraform/website/docs/commands/apply.html.markdown

---
layout: "docs"
page_title: "Command: apply"
sidebar_current: "docs-commands-apply"
description: |-
  The `terraform apply` command is used to apply the changes required to reach the desired state of the configuration, or the pre-determined set of actions generated by a `terraform plan` execution plan.
---

# Command: apply

> For a hands-on tutorial, try the [Get Started](https://learn.hashicorp.com/terraform/getting-started/intro?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) track on HashiCorp Learn.

The `terraform apply` command is used to apply the changes required
to reach the desired state of the configuration, or the pre-determined
set of actions generated by a `terraform plan` execution plan.

## Usage

Usage: `terraform apply [options] [dir-or-plan]`

By default, `apply` scans the current directory for the configuration
and applies the changes appropriately. However, a path to another configuration
or an execution plan can be provided. Explicit execution plan files can be
used to split plan and apply into separate steps within
[automation systems](https://learn.hashicorp.com/terraform/development/running-terraform-in-automation).

If no explicit plan file is given on the command line, `terraform apply` will
create a new plan automatically and prompt for approval to apply it. If the
created plan does not include any changes to resources or to root module
output values then `terraform apply` will exit immediately, without prompting.

The command-line flags are all optional. The list of available flags are:

* `-backup=path` - Path to the backup file. Defaults to `-state-out` with
  the ".backup" extension. Disabled by setting to "-".

* `-compact-warnings` - If Terraform produces any warnings that are not
  accompanied by errors, show them in a more compact form that includes only
  the summary messages.

* `-lock=true` - Lock the state file when locking is supported.

* `-lock-timeout=0s` - Duration to retry a state lock.

* `-input=true` - Ask for input for variables if not directly set.

* `-auto-approve` - Skip interactive approval of plan before applying.

* `-no-color` - Disables output with coloring.

* `-parallelism=n` - Limit the number of concurrent operation as Terraform
  [walks the graph](/docs/internals/graph.html#walking-the-graph). Defaults to
  10.

* `-refresh=true` - Update the state for each resource prior to planning
  and applying. This has no effect if a plan file is given directly to
  apply.

* `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
  Ignored when [remote state](/docs/state/remote.html) is used. This setting
  does not persist and other commands, such as init, may not be aware of the
  alternate statefile. To configure an alternate statefile path which is
  available to all terraform commands, use the [local backend](/docs/state/local.html).

* `-state-out=path` - Path to write updated state file. By default, the
  `-state` path will be used. Ignored when
  [remote state](/docs/state/remote.html) is used.

* `-target=resource` - A [Resource
  Address](/docs/internals/resource-addressing.html) to target. For more
  information, see
  [the targeting docs from `terraform plan`](/docs/commands/plan.html#resource-targeting).

* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
  can be set multiple times. Variable values are interpreted as
  [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be
  specified via this flag.

* `-var-file=foo` - Set variables in the Terraform configuration from
  a [variable file](/docs/configuration/variables.html#variable-files). If
  a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
  directory, they will be automatically loaded. `terraform.tfvars` is loaded
  first and the `.auto.tfvars` files after in alphabetical order. Any files
  specified by `-var-file` override any values set automatically from files in
  the working directory. This flag can be used multiple times.
website: apply docs 2014-07-25 00:53:46 +02:00			`---`
			`layout: "docs"`
			`page_title: "Command: apply"`
			`sidebar_current: "docs-commands-apply"`
Add meta descriptions to all pages 2014-10-22 05:21:56 +02:00			`description: \|-`
			The `terraform apply` command is used to apply the changes required to reach the desired state of the configuration, or the pre-determined set of actions generated by a `terraform plan` execution plan.
website: apply docs 2014-07-25 00:53:46 +02:00			`---`

			`# Command: apply`

website: Add links to relevant Learn guides in several docs pages (#25718) Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com> 2020-07-31 22:16:35 +02:00			`> For a hands-on tutorial, try the [Get Started](https://learn.hashicorp.com/terraform/getting-started/intro?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) track on HashiCorp Learn.`

website: apply docs 2014-07-25 00:53:46 +02:00			The `terraform apply` command is used to apply the changes required
			`to reach the desired state of the configuration, or the pre-determined`
			set of actions generated by a `terraform plan` execution plan.

			`## Usage`

docs: clarify wording around destroy/apply args inspired by #2360 with clarification on args vs flags /cc @catsby 2015-06-17 17:10:23 +02:00			Usage: `terraform apply [options] [dir-or-plan]`
website: apply docs 2014-07-25 00:53:46 +02:00
			By default, `apply` scans the current directory for the configuration
			`and applies the changes appropriately. However, a path to another configuration`
website: Small corrections to the "plan" and "apply" command docs The "apply" documentation contained a simple typo, while the "plan" documentation contained outdated information about using "terraform plan PLANFILE" to view a plan. The latter is now a separate command entirely, since Terraform 0.12: "terraform show PLANFILE". 2020-05-29 00:59:29 +02:00			`or an execution plan can be provided. Explicit execution plan files can be`
command: "terraform apply" uses interactive confirmation by default In the 0.10 release we added an opt-in mode where Terraform would prompt interactively for confirmation during apply. We made this opt-in to give those who wrap Terraform in automation some time to update their scripts to explicitly opt out of this behavior where appropriate. Here we switch the default so that a "terraform apply" with no arguments will -- if it computes a non-empty diff -- display the diff and wait for the user to type "yes" in similar vein to the "terraform destroy" command. This makes the commonly-used "terraform apply" a safe workflow for interactive use, so "terraform plan" is now mainly for use in automation where a separate planning step is used. The apply command remains non-interactive when given an explicit plan file. The previous behavior -- though not recommended -- can be obtained by explicitly setting the -auto-approve option on the apply command line, and indeed that is how all of the tests are updated here so that they can continue to run non-interactively. 2017-10-30 21:33:27 +01:00			`used to split plan and apply into separate steps within`
website: Remove extra copy of "Running Terraform in Automation", update links This document now lives at: - https://learn.hashicorp.com/terraform/development/running-terraform-in-automation ...and terraform.io has been redirecting to there for quite a while. This commit removes the extra copy so that the text of the two versions doesn't drift, and updates existing links to point to the new location. 2018-11-14 02:13:47 +01:00			`[automation systems](https://learn.hashicorp.com/terraform/development/running-terraform-in-automation).`
website: update apply docs 2014-09-30 00:58:45 +02:00
backend/local: treat output changes as side-effects to be applied This is a baby-step towards an intended future where all Terraform actions which have side-effects in either remote objects or the Terraform state can go through the plan+apply workflow. This initial change is focused only on allowing plan+apply for changes to root module output values, so that these can be written into a new state snapshot (for consumption by terraform_remote_state elsewhere) without having to go outside of the primary workflow by running "terraform refresh". This is also better than "terraform refresh" because it gives an opportunity to review the proposed changes before applying them, as we're accustomed to with resource changes. The downside here is that Terraform Core was not designed to produce accurate changesets for root module outputs. Although we added a place for it in the plan model in Terraform 0.12, Terraform Core currently produces inaccurate changesets there which don't properly track the prior values. We're planning to rework Terraform Core's evaluation approach in a forthcoming release so it would itself be able to distinguish between the prior state and the planned new state to produce an accurate changeset, but this commit introduces a temporary stop-gap solution of implementing the logic up in the local backend code, where we can freeze a snapshot of the prior state before we take any other actions and then use that to produce an accurate output changeset to decide whether the plan has externally-visible side-effects and render any changes to output values. This temporary approach should be replaced by a more appropriately-placed solution in Terraform Core in a release, which should then allow further behaviors in similar vein, such as user-visible drift detection for resource instances. 2020-05-27 01:59:06 +02:00			If no explicit plan file is given on the command line, `terraform apply` will
			`create a new plan automatically and prompt for approval to apply it. If the`
			`created plan does not include any changes to resources or to root module`
			output values then `terraform apply` will exit immediately, without prompting.

website: apply docs 2014-07-25 00:53:46 +02:00			`The command-line flags are all optional. The list of available flags are:`

website: Document the -backup flag 2014-07-28 05:40:18 +02:00			* `-backup=path` - Path to the backup file. Defaults to `-state-out` with
Fixed a ton of typos in docs and comments 2014-08-07 09:19:56 +02:00			`the ".backup" extension. Disabled by setting to "-".`
website: Document the -backup flag 2014-07-28 05:40:18 +02:00
command: New -compact-warnings option When warnings appear in isolation (not accompanied by an error) it's reasonable to want to defer resolving them for a while because they are not actually blocking immediate work. However, our warning messages tend to be long by default in order to include all of the necessary context to understand the implications of the warning, and that can make them overwhelming when combined with other output. As a compromise, this adds a new CLI option -compact-warnings which is supported for all the main operation commands and which uses a more compact format to print out warnings as long as they aren't also accompanied by errors. The default remains unchanged except that the threshold for consolidating warning messages is reduced to one so that we'll now only show one of each distinct warning summary. Full warning messages are always shown if there's at least one error included in the diagnostic set too, because in that case the warning message could contain additional context to help understand the error. 2019-12-10 20:06:06 +01:00			* `-compact-warnings` - If Terraform produces any warnings that are not
			`accompanied by errors, show them in a more compact form that includes only`
			`the summary messages.`

update command docs 2017-04-04 19:48:59 +02:00			* `-lock=true` - Lock the state file when locking is supported.

			* `-lock-timeout=0s` - Duration to retry a state lock.

website: Document missing flag 2014-12-06 00:39:49 +01:00			* `-input=true` - Ask for input for variables if not directly set.

command: "terraform apply" uses interactive confirmation by default In the 0.10 release we added an opt-in mode where Terraform would prompt interactively for confirmation during apply. We made this opt-in to give those who wrap Terraform in automation some time to update their scripts to explicitly opt out of this behavior where appropriate. Here we switch the default so that a "terraform apply" with no arguments will -- if it computes a non-empty diff -- display the diff and wait for the user to type "yes" in similar vein to the "terraform destroy" command. This makes the commonly-used "terraform apply" a safe workflow for interactive use, so "terraform plan" is now mainly for use in automation where a separate planning step is used. The apply command remains non-interactive when given an explicit plan file. The previous behavior -- though not recommended -- can be obtained by explicitly setting the -auto-approve option on the apply command line, and indeed that is how all of the tests are updated here so that they can continue to run non-interactively. 2017-10-30 21:33:27 +01:00			* `-auto-approve` - Skip interactive approval of plan before applying.
command: add "apply -auto-approve=false" flag A common reason to want to use `terraform plan` is to have a chance to review and confirm a plan before running it. If in fact that is the only reason you are running plan, this new `terraform apply -auto-approve=false` flag provides an easier alternative to P=$(mktemp -t plan) terraform refresh terraform plan -refresh=false -out=$P terraform apply $P rm $P The flag defaults to true for now, but in a future version of Terraform it will default to false. 2016-06-21 03:06:28 +02:00
website: apply docs 2014-07-25 00:53:46 +02:00			* `-no-color` - Disables output with coloring.

website: docs for parallelism setting /cc @stack72 @knuckolls @mitchellh 2015-10-06 00:18:03 +02:00			* `-parallelism=n` - Limit the number of concurrent operation as Terraform
command: Consistency implement and document parallelism default of 10 References: * https://github.com/hashicorp/terraform/blob/f4da82a023bf6db1fa8da24236882d874ff0a87e/command/command.go#L41 * https://github.com/hashicorp/terraform/blob/b9d8e96e0c7c52487e45eaab1aa6dacc39997b47/terraform/context.go#L149-L155 2019-03-06 15:25:36 +01:00			`[walks the graph](/docs/internals/graph.html#walking-the-graph). Defaults to`
			`10.`
website: docs for parallelism setting /cc @stack72 @knuckolls @mitchellh 2015-10-06 00:18:03 +02:00
website: update docs for apply command 2014-07-27 02:50:53 +02:00			* `-refresh=true` - Update the state for each resource prior to planning
			`and applying. This has no effect if a plan file is given directly to`
			`apply.`

website: apply docs 2014-07-25 00:53:46 +02:00			* `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
website/docs: clarify behavior of -state flag (#25928) * website: clarify behavior of -state option 2020-08-20 16:23:08 +02:00			`Ignored when [remote state](/docs/state/remote.html) is used. This setting`
			`does not persist and other commands, such as init, may not be aware of the`
			`alternate statefile. To configure an alternate statefile path which is`
			`available to all terraform commands, use the [local backend](/docs/state/local.html).`
website: apply docs 2014-07-25 00:53:46 +02:00
			* `-state-out=path` - Path to write updated state file. By default, the
docs/commands: clarify -state w/ remote state (#8015) 2016-08-08 02:59:28 +02:00			`-state` path will be used. Ignored when
docs: fix some broken links related to remote state 2017-03-15 18:20:26 +01:00			`[remote state](/docs/state/remote.html) is used.`
website: apply docs 2014-07-25 00:53:46 +02:00
docs: resource addressing 2015-04-01 01:48:54 +02:00			* `-target=resource` - A [Resource
core: -target option to also select resources in descendant modules Previously the behavior for -target when given a module address was to target only resources directly within that module, ignoring any resources defined in child modules. This behavior turned out to be counter-intuitive, since users expected the -target address to be interpreted hierarchically. We'll now use the new "Contains" function for addresses, which provides a hierarchical "containment" concept that is more consistent with user expectations. In particular, it allows module.foo to match module.foo.module.bar.aws_instance.baz, where before that would not have been true. Since Contains isn't commutative (unlike Equals) this requires some special handling for targeting specific indices. When given an argument like -target=aws_instance.foo[0], the initial graph construction (for both plan and refresh) is for the resource nodes from configuration, which have not yet been expanded to separate indexed instances. Thus we need to do the first pass of TargetsTransformer in mode where indices are ignored, with the work then completed by the DynamicExpand method which re-applies the TargetsTransformer in index-sensitive mode. This is a breaking change for anyone depending on the previous behavior of -target, since it will now select more resources than before. There is no way provided to obtain the previous behavior. Eventually we may support negative targeting, which could then combine with positive targets to regain the previous behavior as an explicit choice. 2017-06-16 03:15:41 +02:00			`Address](/docs/internals/resource-addressing.html) to target. For more`
			`information, see`
			[the targeting docs from `terraform plan`](/docs/commands/plan.html#resource-targeting).
core: docs for targeted operations 2015-03-27 23:24:15 +01:00
website: Docs sweep for lists & maps 2016-07-12 00:37:51 +02:00			* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
			`can be set multiple times. Variable values are interpreted as`
			`[HCL](/docs/configuration/syntax.html#HCL), so list and map values can be`
			`specified via this flag.`
website: apply docs 2014-07-25 00:53:46 +02:00
			* `-var-file=foo` - Set variables in the Terraform configuration from
Autoload only .auto.tfvars files 2017-06-22 03:22:07 +02:00			`a [variable file](/docs/configuration/variables.html#variable-files). If`
			a `terraform.tfvars` or any `.auto.tfvars` files are present in the current
			directory, they will be automatically loaded. `terraform.tfvars` is loaded
			first and the `.auto.tfvars` files after in alphabetical order. Any files
			specified by `-var-file` override any values set automatically from files in
			`the working directory. This flag can be used multiple times.`