2014-07-25 00:53:46 +02:00
---
layout: "docs"
page_title: "Command: apply"
sidebar_current: "docs-commands-apply"
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.
2014-07-25 00:53:46 +02:00
---
# Command: apply
2020-10-02 20:02:59 +02:00
> **Hands-on:** Try the [Terraform: Get Started](https://learn.hashicorp.com/collections/terraform/aws-get-started?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) collection on HashiCorp Learn.
2020-07-31 22:16:35 +02:00
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
main: new global option -chdir
This new option is intended to address the previous inconsistencies where
some older subcommands supported partially changing the target directory
(where Terraform would use the new directory inconsistently) where newer
commands did not support that override at all.
Instead, now Terraform will accept a -chdir command at the start of the
command line (before the subcommand) and will interpret it as a request
to direct all actions that would normally be taken in the current working
directory into the target directory instead. This is similar to options
offered by some other similar tools, such as the -C option in "make".
The new option is only accepted at the start of the command line (before
the subcommand) as a way to reflect that it is a global command (not
specific to a particular subcommand) and that it takes effect _before_
executing the subcommand. This also means it'll be forced to appear before
any other command-specific arguments that take file paths, which hopefully
communicates that those other arguments are interpreted relative to the
overridden path.
As a measure of pragmatism for existing uses, the path.cwd object in
the Terraform language will continue to return the _original_ working
directory (ignoring -chdir), in case that is important in some exceptional
workflows. The path.root object gives the root module directory, which
will always match the overriden working directory unless the user
simultaneously uses one of the legacy directory override arguments, which
is not a pattern we intend to support in the long run.
As a first step down the deprecation path, this commit adjusts the
documentation to de-emphasize the inconsistent old command line arguments,
including specific guidance on what to use instead for the main three
workflow commands, but all of those options remain supported in the same
way as they were before. In a later commit we'll make those arguments
produce a visible deprecation warning in Terraform's output, and then
in an even later commit we'll remove them entirely so that -chdir is the
single supported way to run Terraform from a directory other than the
one containing the root module configuration.
2020-09-02 00:45:12 +02:00
Usage: `terraform apply [options] [plan]`
2014-07-25 00:53:46 +02:00
By default, `apply` scans the current directory for the configuration
main: new global option -chdir
This new option is intended to address the previous inconsistencies where
some older subcommands supported partially changing the target directory
(where Terraform would use the new directory inconsistently) where newer
commands did not support that override at all.
Instead, now Terraform will accept a -chdir command at the start of the
command line (before the subcommand) and will interpret it as a request
to direct all actions that would normally be taken in the current working
directory into the target directory instead. This is similar to options
offered by some other similar tools, such as the -C option in "make".
The new option is only accepted at the start of the command line (before
the subcommand) as a way to reflect that it is a global command (not
specific to a particular subcommand) and that it takes effect _before_
executing the subcommand. This also means it'll be forced to appear before
any other command-specific arguments that take file paths, which hopefully
communicates that those other arguments are interpreted relative to the
overridden path.
As a measure of pragmatism for existing uses, the path.cwd object in
the Terraform language will continue to return the _original_ working
directory (ignoring -chdir), in case that is important in some exceptional
workflows. The path.root object gives the root module directory, which
will always match the overriden working directory unless the user
simultaneously uses one of the legacy directory override arguments, which
is not a pattern we intend to support in the long run.
As a first step down the deprecation path, this commit adjusts the
documentation to de-emphasize the inconsistent old command line arguments,
including specific guidance on what to use instead for the main three
workflow commands, but all of those options remain supported in the same
way as they were before. In a later commit we'll make those arguments
produce a visible deprecation warning in Terraform's output, and then
in an even later commit we'll remove them entirely so that -chdir is the
single supported way to run Terraform from a directory other than the
one containing the root module configuration.
2020-09-02 00:45:12 +02:00
and applies the changes appropriately. However, you can optionally give the
path to a saved plan file that was previously created with
[`terraform plan` ](plan.html ).
2014-09-30 00:58:45 +02:00
main: new global option -chdir
This new option is intended to address the previous inconsistencies where
some older subcommands supported partially changing the target directory
(where Terraform would use the new directory inconsistently) where newer
commands did not support that override at all.
Instead, now Terraform will accept a -chdir command at the start of the
command line (before the subcommand) and will interpret it as a request
to direct all actions that would normally be taken in the current working
directory into the target directory instead. This is similar to options
offered by some other similar tools, such as the -C option in "make".
The new option is only accepted at the start of the command line (before
the subcommand) as a way to reflect that it is a global command (not
specific to a particular subcommand) and that it takes effect _before_
executing the subcommand. This also means it'll be forced to appear before
any other command-specific arguments that take file paths, which hopefully
communicates that those other arguments are interpreted relative to the
overridden path.
As a measure of pragmatism for existing uses, the path.cwd object in
the Terraform language will continue to return the _original_ working
directory (ignoring -chdir), in case that is important in some exceptional
workflows. The path.root object gives the root module directory, which
will always match the overriden working directory unless the user
simultaneously uses one of the legacy directory override arguments, which
is not a pattern we intend to support in the long run.
As a first step down the deprecation path, this commit adjusts the
documentation to de-emphasize the inconsistent old command line arguments,
including specific guidance on what to use instead for the main three
workflow commands, but all of those options remain supported in the same
way as they were before. In a later commit we'll make those arguments
produce a visible deprecation warning in Terraform's output, and then
in an even later commit we'll remove them entirely so that -chdir is the
single supported way to run Terraform from a directory other than the
one containing the root module configuration.
2020-09-02 00:45:12 +02:00
If you don't give a plan file on the command line, `terraform apply` will
create a new plan automatically and then prompt for approval to apply it. If the
2020-05-27 01:59:06 +02:00
created plan does not include any changes to resources or to root module
output values then `terraform apply` will exit immediately, without prompting.
2014-07-25 00:53:46 +02:00
The command-line flags are all optional. The list of available flags are:
2014-07-28 05:40:18 +02:00
* `-backup=path` - Path to the backup file. Defaults to `-state-out` with
2014-08-07 09:19:56 +02:00
the ".backup" extension. Disabled by setting to "-".
2014-07-28 05:40:18 +02:00
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.
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.
2014-12-06 00:39:49 +01:00
* `-input=true` - Ask for input for variables if not directly set.
2017-10-30 21:33:27 +01:00
* `-auto-approve` - Skip interactive approval of plan before applying.
2016-06-21 03:06:28 +02:00
2014-07-25 00:53:46 +02:00
* `-no-color` - Disables output with coloring.
2015-10-06 00:18:03 +02:00
* `-parallelism=n` - Limit the number of concurrent operation as Terraform
2019-03-06 15:25:36 +01:00
[walks the graph ](/docs/internals/graph.html#walking-the-graph ). Defaults to
10.
2015-10-06 00:18:03 +02:00
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.
2014-07-25 00:53:46 +02:00
* `-state=path` - Path to the state file. Defaults to "terraform.tfstate".
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
2020-09-29 01:09:34 +02:00
available to all terraform commands, use the [local backend ](/docs/backends/types/local.html ).
2014-07-25 00:53:46 +02:00
* `-state-out=path` - Path to write updated state file. By default, the
2016-08-08 02:59:28 +02:00
`-state` path will be used. Ignored when
2017-03-15 18:20:26 +01:00
[remote state ](/docs/state/remote.html ) is used.
2014-07-25 00:53:46 +02:00
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 ).
2015-03-27 23:24:15 +01:00
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.
2014-07-25 00:53:46 +02:00
* `-var-file=foo` - Set variables in the Terraform configuration from
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.
main: new global option -chdir
This new option is intended to address the previous inconsistencies where
some older subcommands supported partially changing the target directory
(where Terraform would use the new directory inconsistently) where newer
commands did not support that override at all.
Instead, now Terraform will accept a -chdir command at the start of the
command line (before the subcommand) and will interpret it as a request
to direct all actions that would normally be taken in the current working
directory into the target directory instead. This is similar to options
offered by some other similar tools, such as the -C option in "make".
The new option is only accepted at the start of the command line (before
the subcommand) as a way to reflect that it is a global command (not
specific to a particular subcommand) and that it takes effect _before_
executing the subcommand. This also means it'll be forced to appear before
any other command-specific arguments that take file paths, which hopefully
communicates that those other arguments are interpreted relative to the
overridden path.
As a measure of pragmatism for existing uses, the path.cwd object in
the Terraform language will continue to return the _original_ working
directory (ignoring -chdir), in case that is important in some exceptional
workflows. The path.root object gives the root module directory, which
will always match the overriden working directory unless the user
simultaneously uses one of the legacy directory override arguments, which
is not a pattern we intend to support in the long run.
As a first step down the deprecation path, this commit adjusts the
documentation to de-emphasize the inconsistent old command line arguments,
including specific guidance on what to use instead for the main three
workflow commands, but all of those options remain supported in the same
way as they were before. In a later commit we'll make those arguments
produce a visible deprecation warning in Terraform's output, and then
in an even later commit we'll remove them entirely so that -chdir is the
single supported way to run Terraform from a directory other than the
one containing the root module configuration.
2020-09-02 00:45:12 +02:00
## Passing a Different Configuration Directory
Terraform v0.13 and earlier also accepted a directory path in place of the
plan file argument to `terraform apply` , in which case Terraform would use
that directory as the root module instead of the current working directory.
That usage is still supported in Terraform v0.14, but is now deprecated and we
plan to remove it in Terraform v0.15. If your workflow relies on overriding
the root module directory, use
[the `-chdir` global option ](./#switching-working-directory-with--chdir )
instead, which works across all commands and makes Terraform consistently look
in the given directory for all files it would normaly read or write in the
current working directory.
If your previous use of this legacy pattern was also relying on Terraform
writing the `.terraform` subdirectory into the current working directory even
though the root module directory was overridden, use
[the `TF_DATA_DIR` environment variable ](environment-variables.html#TF_DATA_DIR )
to direct Terraform to write the `.terraform` directory to a location other
than the current working directory.
