---
page_title: Upgrading to Terraform 0.10
description: Upgrading to Terraform v0.10
---

# Upgrading to Terraform v0.10

Terraform v0.10 is a major release and thus includes some changes that
you'll need to consider when upgrading. This guide is intended to help with
that process.

The goal of this guide is to cover the most common upgrade concerns and
issues that would benefit from more explanation and background. The exhaustive
list of changes will always be the
[Terraform Changelog](https://github.com/hashicorp/terraform/blob/main/CHANGELOG.md).
After reviewing this guide, we recommend reviewing the Changelog to check on
specific notes about the resources and providers you use.

This guide focuses on changes from v0.9 to v0.10. Each previous major release
has its own upgrade guide, so please consult the other guides (available
in the navigation) if you are upgrading directly from an earlier version.

## Separated Provider Plugins

As of v0.10, provider plugins are no longer included in the main Terraform
distribution. Instead, they are distributed separately and installed
automatically by
[the `terraform init` command](/cli/commands/init).

In the long run, this new approach should be beneficial to anyone who wishes
to upgrade a specific provider to get new functionality without also
upgrading another provider that may have introduced incompatible changes.
In the short term, it just means a smaller distribution package and thus
avoiding the need to download tens of providers that may never be used.

Provider plugins are now also versioned separately from Terraform itself.
[Version constraints](/language/providers/configuration#provider-versions)
can be specified in configuration to ensure that new major releases
(which may have breaking changes) are not automatically installed.

**Action:** After upgrading, run `terraform init` in each Terraform
configuration working directory to install the necessary provider plugins.
If running Terraform in automation, this command should be run as the first
step after a Terraform configuration is cloned from version control, and
will also install any necessary modules and configure any remote backend.

**Action:** For "production" configurations, consider adding
[provider version constraints](/language/providers/configuration#provider-versions),
as suggested by the `terraform init` output, to prevent new major versions
of plugins from being automatically installed in future.

### Third-party Provider Plugins

This initial release of separated provider plugins applies only to the
providers that are packaged and released by Hashicorp. The goal is to
eventually support a similar approach for third-party plugins, but we wish
to ensure the robustness of the installation and versioning mechanisms before
generalizing this feature.

-> **Note:** As of Terraform 0.13, Terraform can automatically install
third-party providers released on the Terraform Registry.

In the mean time, third-party providers can be installed by placing them in the
user plugins directory:

| Operating system  | User plugins directory          |
| ----------------- | ------------------------------- |
| Windows           | `%APPDATA%\terraform.d\plugins` |
| All other systems | `~/.terraform.d/plugins`        |

Maintainers of third-party providers may optionally
make use of the new versioning mechanism by naming provider binaries
using the scheme `terraform-provider-NAME_v0.0.1`, where "0.0.1" is an
example version. Terraform expects providers to follow the
[semantic versioning](http://semver.org/) methodology.

Although third-party providers with versions cannot currently be automatically
installed, Terraform 0.10 _will_ verify that the installed version matches the
constraints in configuration and produce an error if an acceptable version
is unavailable.

**Action:** No immediate action required, but third-party plugin maintainers
may optionally begin using version numbers in their binary distributions to
help users deal with changes over time.

## Recursive Module Targeting with `-target`

It is possible to target all of the resources in a particular module by passing
a module address to the `-target` argument:

```
$ terraform plan -out=tfplan -target=module.example
```

Prior to 0.10, this command would target only the resources _directly_ in
the given module. As of 0.10, this behavior has changed such that the above
command also targets resources in _descendent_ modules.

For example, if `module.example` contains a module itself, called
`module.examplechild`, the above command will target resources in both
`module.example` _and_ `module.example.module.examplechild`.

This also applies to other Terraform features that use
[resource addressing](/cli/state/resource-addressing) syntax.
This includes some of the subcommands of
[`terraform state`](/cli/commands/state).

**Action:** If running Terraform with `-target` in automation, review usage
to ensure that selecting additional resources in child modules will not have
ill effects. Be sure to review plan output when `-target` is used to verify
that only the desired resources have been targeted for operations. Please
note that it is not recommended to routinely use `-target`; it is provided for
exceptional uses and manual intervention.

## Interactive Approval in `terraform apply`

Starting with Terraform 0.10 `terraform apply` has a new mode where it will
present the plan, pause for interactive confirmation, and then apply the
plan only if confirmed. This is intended to get similar benefits to separately
running `terraform plan`, but to streamline the workflow for interactive
command-line use.

For 0.10 this feature is disabled by default, to avoid breaking any wrapper
scripts that are expecting the old behavior. To opt-in to this behavior,
pass `-auto-approve=false` when running `terraform apply` without an explicit
plan file.

It is planned that a future version of Terraform will make this behavior the
default. Although no immediate action is required, we strongly recommend
adjusting any Terraform automation or wrapper scripts to prepare for this
upcoming change in behavior, in the following ways:

* Non-interative automation around production systems should _always_
  separately run `terraform plan -out=tfplan` and then (after approval)
  `terraform apply tfplan`, to ensure operators have a chance to review
  the plan before applying it.

* If running `terraform apply` _without_ a plan file in automation for
  a _non-production_ system, add `-auto-approve=true` to the command line
  soon, to preserve the current 0.10 behavior once auto-approval is no longer
  enabled by default.

We are using a staged deprecation for this change because we are aware that
many teams use Terraform in wrapper scripts and automation, and we wish to
ensure that such teams have an opportunity to update those tools in preparation
for the future change in behavior.

**Action:** 0.10 preserves the previous behavior as the default, so no
immediate action is required. However, maintainers of tools that wrap
Terraform, either in automation or in alternative command-line UI, should
consider which behavior is appropriate for their use-case and explicitly
set the `-auto-approve=...` flag to ensure that behavior in future versions.