# atmos terraform

Use these subcommands to interact with Terraform and OpenTofu.

Atmos supports all Terraform and OpenTofu commands and options described in
[Terraform CLI Overview](https://developer.hashicorp.com/terraform/cli/commands)
and [OpenTofu Basic CLI Features](https://opentofu.org/docs/cli/commands/).

:::note Disambiguation
The term "Terraform" is used in this documentation to refer to generic concepts such as providers, modules, stacks, the
HCL-based domain-specific language and its interpreter. Atmos works with [OpenTofu](/components/terraform).
:::

## Command Modes

Atmos Terraform commands operate in two modes:

- **Single-Component**: Execute Terraform for one component at a time with precise control
- **Multi-Component**: Execute Terraform across multiple components using filters (`--all`, `--affected`, `--components`, `--query`)

## Single-Component Usage

Use single-component commands when you want to execute Terraform operations on one component at a time.

```shell
atmos terraform <command> <component> -s <stack> [options]
```

The `component` argument and `--stack` flag are required to generate variables and backend config for the component in the stack.

See individual command pages for detailed options: [plan](/cli/commands/terraform/plan), [apply](/cli/commands/terraform/apply), [deploy](/cli/commands/terraform/deploy), [destroy](/cli/commands/terraform/destroy).

### Path-Based Component Resolution

Atmos supports using filesystem paths instead of component names for convenience. This allows you to navigate to a component directory and use `.` to reference it:

```shell
# Navigate to component directory
cd components/terraform/vpc

# Use . to reference current directory
atmos terraform plan . -s dev
atmos terraform apply . -s dev
```

This automatically resolves the path to the component name configured in your stack, eliminating the need to remember exact component names.

**Supported path formats:**

- `.` - Current directory
- `./component` - Relative path from current directory
- `../other-component` - Relative path to sibling directory
- `/absolute/path/to/component` - Absolute path

**Requirements:**

- Must be inside a component directory under the configured base path
- Must specify `--stack` flag
- Component must exist in the specified stack configuration

:::tip Interactive Component Selection
When a component path matches multiple components in the stack, Atmos prompts you to select which one to use in interactive terminals.

For example, if both `station/1` and `station/2` reference `components/terraform/weather`:

```bash
cd components/terraform/weather
atmos terraform plan . --stack dev
# Atmos displays: "Component path '.' matches multiple instances in stack 'dev'"
# Select which component instance to use: station/1, station/2
```

In non-interactive mode (CI/CD), use the explicit component name to avoid ambiguity:

```bash
atmos terraform plan station/1 --stack dev  # Explicit and unambiguous
atmos terraform plan station/2 --stack dev  # Explicit and unambiguous
```

:::

## Multi-Component Usage

Use multi-component commands to run Terraform operations across multiple components simultaneously. You can target components by stack, selector, query, or change detection.

```shell
# Execute on all components in all stacks
atmos terraform <command> --all

# Execute on all components in a specific stack
atmos terraform <command> --stack prod

# Execute on specific components
atmos terraform <command> --components vpc,eks

# Execute on affected components (based on git changes)
atmos terraform <command> --affected

# Execute on components matching a query
atmos terraform <command> --query '.vars.tags.team == "eks"'
```

All multi-component flags can be combined with `--dry-run` to preview what would be executed without making changes.

See individual command pages for detailed multi-component examples and flags: [plan](/cli/commands/terraform/plan#multi-component-operations), [apply](/cli/commands/terraform/apply#multi-component-operations), [deploy](/cli/commands/terraform/deploy#multi-component-operations).

## Differences from Native Terraform

Atmos enhances the standard Terraform CLI with several conveniences:

- **Automatic initialization**: Atmos runs `terraform init` before executing other commands. Use `--skip-init` to skip this step.

- **Deploy command**: `atmos terraform deploy` executes `terraform apply -auto-approve` for automated deployments.

- **Planfile support**: The `--from-plan` and `--planfile` flags enable two-stage plan/apply workflows. See [Terraform Planfiles](/components/terraform/planfiles).

- **Terraform Cloud compatibility**: Use `--skip-planfile` with `terraform plan` when using Terraform Cloud, which doesn't support local plan files.

- **Native flag passthrough**: Use `--` to pass flags directly to Terraform:
  ```shell
  atmos terraform plan vpc -s dev -- -refresh=false
  atmos terraform apply vpc -s dev -- -lock=false
  ```

:::tip
Run `atmos terraform --help` to see all available options.
:::

## Examples

### Component Name Examples

```shell
atmos terraform plan test/test-component-override-3 -s tenant1-ue2-dev
atmos terraform plan test/test-component-override-3 -s tenant1-ue2-dev --skip-lock-file
atmos terraform plan test/test-component-override-2 -s tenant1-ue2-dev --redirect-stderr /dev/stdout
atmos terraform plan test/test-component-override -s tenant1-ue2-dev --redirect-stderr ./errors.txt

atmos terraform apply test/test-component-override-3 -s tenant1-ue2-dev
atmos terraform apply test/test-component-override-2 -s tenant1-ue2-dev --redirect-stderr /dev/stdout
atmos terraform apply test/test-component-override -s tenant1-ue2-dev --redirect-stderr ./errors.txt

atmos terraform destroy test/test-component-override-3 -s tenant1-ue2-dev
atmos terraform destroy test/test-component-override-2 -s tenant1-ue2-dev --redirect-stderr /dev/stdout
atmos terraform destroy test/test-component-override -s tenant1-ue2-dev --redirect-stderr /dev/null

atmos terraform init test/test-component-override-3 -s tenant1-ue2-dev
```

### Path-Based Examples

```shell
# Navigate to component directory and use current directory
cd components/terraform/vpc
atmos terraform plan . -s dev
atmos terraform apply . -s dev

# Use relative path from components/terraform directory
cd components/terraform
atmos terraform plan ./vpc -s dev
atmos terraform apply ./infra/security-group -s prod

# Use from project root with relative path
atmos terraform plan components/terraform/vpc -s dev

# Combine with other flags
cd components/terraform/vpc
atmos terraform plan . -s dev --skip-init
atmos terraform apply . -s dev -- -auto-approve
atmos terraform destroy . -s dev --dry-run
```

### Clean Examples

```shell
# Clean all components (with confirmation)
atmos terraform clean

# Clean a specific component
atmos terraform clean vpc

# Clean a specific component in a stack
atmos terraform clean vpc --stack dev

# Clean without confirmation prompt
atmos terraform clean --force
atmos terraform clean test/test-component-override-3 -s tenant1-ue2-dev
```

### Workspace Examples

```shell
atmos terraform workspace test/test-component-override-3 -s tenant1-ue2-dev
atmos terraform workspace test/test-component-override-3 -s tenant1-ue2-dev --redirect-stderr /dev/null
atmos terraform workspace test/test-component-override-3 -s tenant1-ue2-dev --redirect-stderr /dev/stdout
atmos terraform workspace test/test-component-override-3 -s tenant1-ue2-dev --redirect-stderr ./errors.txt
```

### Additional Flag Examples

```shell
atmos terraform plan test/test-component -s tenant1-ue2-dev -- -refresh=false -lock=false

atmos terraform plan test/test-component -s tenant1-ue2-dev --append-user-agent "Acme/1.0 (Build 1234; arm64)"
```

## Arguments

- **`component` (required for Single-Component commands)**

  Atmos Terraform/OpenTofu component name or filesystem path.
  Supports both:

  Component names: vpc, infra/vpc, test/test-component
  Filesystem paths: . (current directory), ./vpc, components/terraform/vpc

  When using paths, Atmos automatically resolves the path to the component name based on your stack configuration.
  See Path-Based Component Resolution above.

## Flags

- **`--stack` (alias `-s`) (required for Single-Component commands)**

  Atmos stack.
  ```shell
  atmos terraform plan <component> --stack <stack>
  atmos terraform apply --all -s <stack>
  ```
- **`--dry-run` (optional)**

  Dry run.
  Simulate the command without making any changes.
  ```shell
  atmos terraform <command> <component> -s <stack> --dry-run
  atmos terraform <command> --all --dry-run
  atmos terraform <command> --affected --dry-run
  ```
- **`--redirect-stderr` (optional)**

  File descriptor to redirect `stderr` to.

  Errors can be redirected to any file or any standard file descriptor (including `/dev/null`).
- **`--append-user-agent` (optional)**

  Append a custom User-Agent to Terraform requests.

  Can also be set using the `ATMOS_COMPONENTS_TERRAFORM_APPEND_USER_AGENT` environment variable.
- **`--skip-init` (optional)**

  Skip running `terraform init` before executing terraform commands.
  ```shell
  atmos terraform apply <component> -s <stack> --skip-init
  ```
- **`--skip-planfile` (optional)**

  Skip writing the plan to a file.
  If the flag is set to `true`, Atmos will not pass the `-out` flag to Terraform
  when executing `terraform plan` commands. Set it to `true` when using Terraform Cloud since the `-out` flag is not supported.
  Terraform Cloud automatically stores plans in its backend and can't store it in a local file
  ```shell
  atmos terraform plan <component> -s <stack> --skip-planfile=true
  ```
- **`--process-templates` (optional)**

  Enable/disable Go template processing in Atmos stack manifests when executing terraform commands.

  If the flag is not passed, template processing is enabled by default.
  ```shell
  atmos terraform plan <component> -s <stack> --process-templates=false
  ```
- **`--process-functions` (optional)**

  Enable/disable YAML functions processing in Atmos stack manifestswhen executing terraform commands.

  If the flag is not passed, YAML function processing is enabled by default.
  ```shell
  atmos terraform plan <component> -s <stack> --process-functions=false
  ```
- **`--skip` (optional)**

  Skip processing a specific Atmos YAML function in Atmos stacks manifests when executing terraform commands.

  To specify more than one function, use multiple `--skip` flags, or separate the functions with a comma.
  ```shell
  atmos terraform plan <component> -s <stack> --skip=eval --skip=include
  atmos terraform apply <component> -s <stack> --skip=terraform.output,include
  ```
- **`--components` (optional)**

  Execute the command on the specified components in all stacks or in a specific stack.
  ```shell
  atmos terraform plan --components <component-1>
  atmos terraform plan --components <component-1>,<component-2>
  atmos terraform apply --components <component-1> --components <component-2>
  atmos terraform apply --components <component-1>,<component-2> --stack <stack> --logs-level=Debug
  ```
- **`--all` (optional)**

  Execute the command on all components in all stacks or in a specific stack.
  ```shell
  atmos terraform plan --all
  atmos terraform apply --all --stack <stack>
  atmos terraform apply --all --dry-run
  atmos terraform deploy --all --logs-level=Debug
  ```
- **`--query` (optional)**

  Execute the command on the components filtered by a [YQ](https://mikefarah.gitbook.io/yq) expression, in all stacks or in a specific stack.

  **NOTE**: All Atmos sections are available in the expression, e.g. `vars`, `locals`, `settings`, `env`, `metadata`, `backend`, etc.
  ```shell
  atmos terraform plan --query '.vars.tags.team == "data"'
  atmos terraform apply --query '.vars.tags.team == "eks"' --stack <stack>
  atmos terraform apply --query '.settings.context.account_id == 12345'
  atmos terraform deploy --query '.vars.tags.team == "data"' --dry-run --logs-level=Debug
  ```
- **`--affected` (optional)**

  Execute the command on all the directly affected components, in all stacks or in a specific stack,
  in dependency order (if [component dependencies](/stacks/settings/depends_on) are configured).

  **NOTE**: When using the `--affected` flag, Atmos supports all the flags from the [`atmos describe affected`](/cli/commands/describe/affected) CLI command.
  ```shell
  atmos terraform plan --affected
  atmos terraform apply --affected --stack <stack>
  atmos terraform apply --affected --dry-run
  atmos terraform apply --affected --clone-target-ref=true
  atmos terraform deploy --affected --include-dependents
  atmos terraform apply --affected --include-dependents --dry-run --logs-level=Debug
  ```
- **`--include-dependents` (optional; can only be used in conjunction with the `--affected` flag)**

  For each directly affected component, detect the dependent components and process them in dependency order, recursively.
  Dependents are components that are indirectly affected, meaning that nothing in the current branch modifies their code
  or configs, but they are configured as [dependencies](/stacks/settings/depends_on) of the components that are modified.
  ```shell
  atmos terraform plan --affected --include-dependents --logs-level=Debug
  atmos terraform apply --affected --include-dependents --dry-run
  atmos terraform apply --affected --include-dependents --stack prod --dry-run
  ```
- **`--ref` (optional; can only be used in conjunction with the `--affected` flag)**

  [Git Reference](https://git-scm.com/book/en/v2/Git-Internals-Git-References) with which to compare the current working branch.

  If the reference is a branch, the command will compare the current working branch with the branch.

  If the reference is a tag, the command will compare the current working branch with the tag.

  If the flags are not provided, the ref will be set automatically to the head to the default branch (`refs/remotes/origin/HEAD` Git ref, usually the `main` branch)
- **`--sha` (optional; can only be used in conjunction with the `--affected` flag)**

  Git commit SHA with which to compare the current working branch
- **`--ssh-key` (optional; can only be used in conjunction with the `--affected` flag)**

  Path to PEM-encoded private key to clone private repos using SSH
- **`--ssh-key-password` (optional; can only be used in conjunction with the `--affected` flag)**

  Encryption password for the PEM-encoded private key if the key contains a password-encrypted PEM block
- **`--repo-path` (optional; can only be used in conjunction with the `--affected` flag)**

  Path to the already cloned target repository with which to compare the current branch. Conflicts with `--ref`, `--sha`, `--ssh-key` and `--ssh-key-password`
- **`--clone-target-ref` (optional; can only be used in conjunction with the `--affected` flag)**

  Clone the target reference with which to compare the current branch.
  ```shell
  atmos terraform plan --affected --clone-target-ref=true
  atmos terraform deploy --affected --clone-target-ref=true --dry-run
  atmos terraform apply --affected --clone-target-ref=true --dry-run --logs-level=Debug
  ```
  If the flag is not passed or set to `false` (default), the target reference will be checked out instead.
  This requires that the target reference is already cloned by Git, and the information about it exists in the `.git` directory
- **`--identity` (alias `-i`) (optional)**

  Specify the identity to authenticate before running Terraform commands. This flag has four modes:
  - **With identity name** (`--identity admin` or `--identity=admin`): Use the specified identity
  - **Without value** (`--identity`): Show interactive selector to choose identity
  - **With `false`** (`--identity=false`): Disable Atmos authentication and use AWS SDK defaults
  - **Omitted**: Use the default identity configured in `atmos.yaml`, or prompt if no default is set
  ```shell
  # Use specific identity (equals syntax recommended)
  atmos terraform plan <component> -s <stack> --identity=admin

  # Use specific identity (space syntax)
  atmos terraform plan <component> -s <stack> --identity admin

  # Interactively select identity
  atmos terraform apply <component> -s <stack> --identity

  # Disable authentication (use AWS SDK defaults)
  atmos terraform plan <component> -s <stack> --identity=false

  # Use default identity (or prompt if none configured)
  atmos terraform plan <component> -s <stack>
  ```
  :::tip Flag Placement Best Practice
  When using `--identity` with a value, place it **after the stack flag** and **before the `--` separator** (if passing Terraform-native flags):
  ```shell
  # Recommended: --identity before -- separator
  atmos terraform plan <component> -s <stack> --identity=admin -- -var-file=extra.tfvars

  # The equals syntax (--identity=admin) is unambiguous and works in all contexts
  ```
  :::

  When set to `false` (or `0`, `no`, `off`), Atmos skips identity authentication entirely and uses standard cloud provider SDK credential resolution (e.g., environment variables, shared credentials file, instance metadata, OIDC). This is useful in CI/CD environments using external authentication mechanisms.

  See [Disabling Authentication](/cli/configuration/auth#disabling-authentication) for more details.

  **Environment variables:** `ATMOS_IDENTITY` or `IDENTITY` (checked in that order)

:::note

All native Terraform/OpenTofu flags are supported.

:::

## Multi-Component Commands (Bulk Operations) Examples

Let's assume that we have the following Atmos stack manifests in the `prod` and `nonprod` stacks,
with [dependencies between the components](/stacks/settings/depends_on):

**File:** `` `prod` and `nonprod` stacks ``

```
components:
  terraform:
    vpc:
      vars:
        tags:
          # Team `network` manages the `vpc` component
          team: network
    eks/cluster:
      vars:
        tags:
          # Team `eks` manages the `eks/cluster` component
          team: eks
      settings:
        depends_on:
          # `eks/cluster` depends on the `vpc` component
          1:
            component: vpc
    eks/external-dns:
      vars:
        tags:
          # Team `eks` manages the `eks/external-dns` component
          team: eks
      settings:
        depends_on:
          # `eks/external-dns` depends on the `eks/cluster` component
          1:
            component: eks/cluster
    eks/karpenter:
      vars:
        tags:
          # Team `eks` manages the `eks/karpenter` component
          team: eks
      settings:
        depends_on:
          # `eks/karpenter` depends on the `eks/cluster` component
          1:
            component: eks/cluster
    eks/karpenter-node-pool:
      vars:
        tags:
          # Team `eks` manages the `eks/karpenter-node-pool` component
          team: eks
      settings:
        # `eks/karpenter-node-pool` depends on the `eks/cluster` and `eks/karpenter` components
        depends_on:
          1:
            component: eks/cluster
          2:
            component: eks/karpenter
    eks/istio/base:
      vars:
        tags:
          # Team `istio` manages the `eks/istio/base` component
          team: istio
      settings:
        # `eks/istio/base` depends on the `eks/cluster` component
        depends_on:
          1:
            component: eks/cluster
    eks/istio/istiod:
      vars:
        tags:
          # Team `istio` manages the `eks/istio/istiod` component
          team: istio
      settings:
        # `eks/istio/istiod` depends on the `eks/cluster` and `eks/istio/base` components
        depends_on:
          1:
            component: eks/cluster
          2:
            component: eks/istio/base
    eks/istio/test-app:
      vars:
        tags:
          # Team `istio` manages the `eks/istio/test-app` component
          team: istio
      settings:
        # `eks/istio/test-app` depends on the `eks/cluster`, `eks/istio/istiod` and `eks/istio/base` components
        depends_on:
          1:
            component: eks/cluster
          2:
            component: eks/istio/istiod
          3:
            component: eks/istio/base
```

Let's run the following Multi-Component commands in `dry-run` mode and review the output to understand what each command executes:

```shell
# Execute the `terraform apply` command on all components in all stacks

> atmos terraform apply --all --dry-run

Executing command="atmos terraform apply vpc -s nonprod"
Executing command="atmos terraform apply eks/cluster -s nonprod"
Executing command="atmos terraform apply eks/external-dns -s nonprod"
Executing command="atmos terraform apply eks/istio/base -s nonprod"
Executing command="atmos terraform apply eks/istio/istiod -s nonprod"
Executing command="atmos terraform apply eks/istio/test-app -s nonprod"
Executing command="atmos terraform apply eks/karpenter -s nonprod"
Executing command="atmos terraform apply eks/karpenter-node-pool -s nonprod"

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod"
Executing command="atmos terraform apply eks/external-dns -s prod"
Executing command="atmos terraform apply eks/istio/base -s prod"
Executing command="atmos terraform apply eks/istio/istiod -s prod"
Executing command="atmos terraform apply eks/istio/test-app -s prod"
Executing command="atmos terraform apply eks/karpenter -s prod"
Executing command="atmos terraform apply eks/karpenter-node-pool -s prod"
```

```shell
# Execute the `terraform apply` command on all components in the `prod` stack

> atmos terraform apply --all --stack prod --dry-run

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod"
Executing command="atmos terraform apply eks/external-dns -s prod"
Executing command="atmos terraform apply eks/istio/base -s prod"
Executing command="atmos terraform apply eks/istio/istiod -s prod"
Executing command="atmos terraform apply eks/istio/test-app -s prod"
Executing command="atmos terraform apply eks/karpenter -s prod"
Executing command="atmos terraform apply eks/karpenter-node-pool -s prod"
```

```shell
# Execute the `terraform apply` command on all components in the `prod` stack

> atmos terraform apply --stack prod --dry-run

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod"
Executing command="atmos terraform apply eks/external-dns -s prod"
Executing command="atmos terraform apply eks/istio/base -s prod"
Executing command="atmos terraform apply eks/istio/istiod -s prod"
Executing command="atmos terraform apply eks/istio/test-app -s prod"
Executing command="atmos terraform apply eks/karpenter -s prod"
Executing command="atmos terraform apply eks/karpenter-node-pool -s prod"
```

```shell
# Execute the `terraform apply` command on the `vpc` and `eks/cluster` components
# in all stacks.

> atmos terraform apply --components vpc,eks/cluster --dry-run

Executing command="atmos terraform apply vpc -s nonprod"
Executing command="atmos terraform apply eks/cluster -s nonprod"

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod"
```

```shell
# Execute the `terraform apply` command on the `vpc` and `eks/cluster` components
# in the `prod` stack.

> atmos terraform apply --stack prod --components vpc,eks/cluster --dry-run

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod"
```

```shell
# Execute the `terraform apply` command on the components filtered by the query expression,
# in all stacks.

> atmos terraform apply --query '.vars.tags.team == "eks"' --dry-run

Skipping the component because the query criteria not satisfied command="atmos terraform apply vpc -s nonprod" query=".vars.tags.team == \"eks\""
Executing command="atmos terraform apply eks/cluster -s nonprod"
Executing command="atmos terraform apply eks/external-dns -s nonprod"
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/base -s nonprod" query=".vars.tags.team == \"eks\""
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/istiod -s nonprod" query=".vars.tags.team == \"eks\""
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/test-app -s nonprod" query=".vars.tags.team == \"eks\""
Executing command="atmos terraform apply eks/karpenter -s nonprod"
Executing command="atmos terraform apply eks/karpenter-node-pool -s nonprod"

Skipping the component because the query criteria not satisfied command="atmos terraform apply vpc -s prod" query=".vars.tags.team == \"eks\""
Executing command="atmos terraform apply eks/cluster -s prod"
Executing command="atmos terraform apply eks/external-dns -s prod"
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/base -s prod" query=".vars.tags.team == \"eks\""
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/istiod -s prod" query=".vars.tags.team == \"eks\""
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/test-app -s prod" query=".vars.tags.team == \"eks\""
Executing command="atmos terraform apply eks/karpenter -s prod"
Executing command="atmos terraform apply eks/karpenter-node-pool -s prod"
```

```shell
# Execute the `terraform apply` command on the components filtered by the query expression,
# in the `prod` stack.

> atmos terraform apply --query '.vars.tags.team == "eks"' --stack prod --dry-run

Skipping the component because the query criteria not satisfied command="atmos terraform apply vpc -s prod" query=".vars.tags.team == \"eks\""
Executing command="atmos terraform apply eks/cluster -s prod"
Executing command="atmos terraform apply eks/external-dns -s prod"
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/base -s prod" query=".vars.tags.team == \"eks\""
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/istiod -s prod" query=".vars.tags.team == \"eks\""
Skipping the component because the query criteria not satisfied command="atmos terraform apply eks/istio/test-app -s prod" query=".vars.tags.team == \"eks\""
Executing command="atmos terraform apply eks/karpenter -s prod"
Executing command="atmos terraform apply eks/karpenter-node-pool -s prod"
```

```shell
# Execute the `terraform apply` command on all components affected by the changes
# in the current branch, in all stacks, in dependency order.
# Assume that the components `vpc` and `eks/cluster` in all stacks are affected (e.g. just added).

> atmos terraform apply --affected --dry-run

Executing command="atmos terraform apply vpc -s nonprod"
Executing command="atmos terraform apply eks/cluster -s nonprod"

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod"
```

```shell
# Execute the `terraform apply` command on all components affected by the changes
# in the current branch, in the `prod` stack, in dependency order.
# Assume that the components `vpc` and `eks/cluster` in the `prod` stack are affected (e.g. just added).

> atmos terraform apply --affected --stack prod --dry-run

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod"
```

```shell
# Execute the `terraform apply` command on all the components affected by the changes
# in the current branch, in all stacks.
# For each directly affected component, detect the dependent components and process
# them in dependency order, recursively.
# Dependents are components that are indirectly affected, meaning that nothing in the
# current branch modifies their code or configs, but they are configured as
# dependencies of the components that are modified.

> atmos terraform apply --affected --include-dependents --dry-run

Executing command="atmos terraform apply vpc -s nonprod"
Executing command="atmos terraform apply eks/cluster -s nonprod" dependency of component=vpc in stack=nonprod
Executing command="atmos terraform apply eks/karpenter -s nonprod" dependency of component=eks/cluster in stack=nonprod
Executing command="atmos terraform apply eks/karpenter-node-pool -s nonprod" dependency of component=eks/karpenter in stack=nonprod
Executing command="atmos terraform apply eks/external-dns -s nonprod" dependency of component=eks/cluster in stack=nonprod
Executing command="atmos terraform apply eks/istio/base -s nonprod" dependency of component=eks/cluster in stack=nonprod
Executing command="atmos terraform apply eks/istio/istiod -s nonprod" dependency of component=eks/istio/base in stack=nonprod
Executing command="atmos terraform apply eks/istio/test-app -s nonprod" dependency of component=eks/istio/istiod in stack=nonprod

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod" dependency of component=vpc in stack=prod
Executing command="atmos terraform apply eks/external-dns -s prod" dependency of component=eks/cluster in stack=prod
Executing command="atmos terraform apply eks/istio/base -s prod" dependency of component=eks/cluster in stack=prod
Executing command="atmos terraform apply eks/istio/istiod -s prod" dependency of component=eks/istio/base in stack=prod
Executing command="atmos terraform apply eks/istio/test-app -s prod" dependency of component=eks/istio/istiod in stack=prod
Executing command="atmos terraform apply eks/karpenter -s prod" dependency of component=eks/cluster in stack=prod
Executing command="atmos terraform apply eks/karpenter-node-pool -s prod" dependency of component=eks/karpenter in stack=prod
```

```shell
# Execute the `terraform apply` command on all the components affected by the changes
# in the current branch, in the `prod` stack.
# For each directly affected component, detect the dependent components and process
# them in dependency order, recursively.
# Dependents are components that are indirectly affected, meaning that nothing in the
# current branch modifies their code or configs, but they are configured as
# dependencies of the components that are modified.

> atmos terraform apply --affected --stack prod --include-dependents --dry-run

Executing command="atmos terraform apply vpc -s prod"
Executing command="atmos terraform apply eks/cluster -s prod" dependency of component=vpc in stack=prod
Executing command="atmos terraform apply eks/external-dns -s prod" dependency of component=eks/cluster in stack=prod
Executing command="atmos terraform apply eks/istio/base -s prod" dependency of component=eks/cluster in stack=prod
Executing command="atmos terraform apply eks/istio/istiod -s prod" dependency of component=eks/istio/base in stack=prod
Executing command="atmos terraform apply eks/istio/test-app -s prod" dependency of component=eks/istio/istiod in stack=prod
Executing command="atmos terraform apply eks/karpenter -s prod" dependency of component=eks/cluster in stack=prod
Executing command="atmos terraform apply eks/karpenter-node-pool -s prod" dependency of component=eks/karpenter in stack=prod
```

**Configure Terraform**

Learn how to configure Terraform components in your `atmos.yaml`, including backends, workspaces, and provider generation.

## Subcommands