mirror of
https://github.com/opentffoundation/opentf.git
synced 2026-03-27 11:00:18 -04:00
6f35c2847b
We have these funny extra options that date back to before Terraform even had remote state, which we've preserved along the way by most recently incorporating them as special-case overrides for the local backend. The documentation we had for these has grown less accurate over time as the details have shifted, and was in many cases missing the requisite caveats that they are only for the local backend and that backend configuration is the modern, preferred way to deal with the use-cases they were intended for. We always have a bit of a tension with this sort of legacy option because we want to keep them documented just enough to be useful to someone who finds an existing script/etc using them and wants to know what they do, but not to take up so much space that they might distract users from finding the modern alternative they should consider instead. As a compromise in that vein here I've created a new section about these options under the local backend documentation, which then gives us the space to go into some detail about the various behaviors and interactions and also to discuss their history and our recommended alternatives. I then simplified all of the other mentions of these in command documentation to just link to or refer to the local backend documentation. My hope then is that folks who need to know what these do can still find the docs, but that information can be kept out of the direct path of new users so they can focus on learning about remote backends instead. This is certainly not the most ideal thing ever, but it seemed like the best compromise between the competing priorities I described above.
98 lines
4.6 KiB
Markdown
98 lines
4.6 KiB
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
|
|
|
|
> **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.
|
|
|
|
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] [plan]`
|
|
|
|
By default, `apply` scans the current directory for the configuration
|
|
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).
|
|
|
|
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
|
|
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:
|
|
|
|
* `-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.
|
|
|
|
* `-target=resource` - A [Resource
|
|
Address](/docs/cli/state/resource-addressing.html) to target. For more
|
|
information, see
|
|
[the targeting docs from `terraform plan`](/docs/cli/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
|
|
[literal expressions](/docs/language/expressions/types.html) in the
|
|
Terraform language, 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/language/values/variables.html#variable-definitions-tfvars-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.
|
|
|
|
For configurations using
|
|
[the `local` backend](/docs/language/settings/backends/local.html) only,
|
|
`terraform apply` also accepts the legacy options
|
|
[`-state`, `-state-out`, and `-backup`](/docs/language/settings/backends/local.html#command-line-arguments).
|
|
|
|
## 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](/docs/cli/config/environment-variables.html#tf_data_dir)
|
|
to direct Terraform to write the `.terraform` directory to a location other
|
|
than the current working directory.
|