# atmos terraform apply

Use this command to apply Terraform changes for an Atmos component in a stack. Supports both direct applies and applying from previously generated planfiles.

## Usage

Execute the `terraform apply` command like this:

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

This command applies Terraform changes to your infrastructure. You can:

- Apply changes directly (generates a new plan and prompts for approval)
- Apply a previously generated planfile using `--from-plan`
- Apply a specific planfile using `--planfile <path>`
- Auto-approve changes using `-auto-approve`

:::tip
For automated deployments, consider using `atmos terraform deploy` which automatically includes `-auto-approve`.
:::

## Examples

### Interactive Apply

Apply changes interactively (you'll be prompted to approve):

```shell
atmos terraform apply vpc -s dev
```

### Apply from Previous Plan

Apply using the planfile generated by a previous `atmos terraform plan`:

```shell
# First generate a plan
atmos terraform plan vpc -s dev

# Then apply using that plan
atmos terraform apply vpc -s dev --from-plan
```

### Apply Specific Planfile

Apply a specific planfile:

```shell
# Using a custom planfile created earlier
atmos terraform apply vpc -s dev --planfile /tmp/my-plan.tfplan

# Or relative to component directory
atmos terraform apply vpc -s dev --planfile plans/vpc.tfplan
```

### Auto-Approved Apply

Apply changes without manual approval (use with caution):

```shell
atmos terraform apply vpc -s dev -auto-approve
```

### Targeted Apply

Apply changes only to specific resources:

```shell
atmos terraform apply vpc -s dev -target=aws_subnet.private
```

## Planfile Usage

### Using Atmos-Generated Planfiles

When you run `atmos terraform plan`, Atmos automatically generates a planfile with a standardized name. You can apply this planfile using the `--from-plan` flag:

```shell
# Generate the plan
atmos terraform plan vpc -s dev

# Review the plan output...

# Apply the exact plan that was generated
atmos terraform apply vpc -s dev --from-plan
```

This ensures that only the changes you reviewed will be applied, with no risk of configuration drift between planning and applying.

### Using Custom Planfiles

If you generated a plan with a custom output path, use the `--planfile` flag:

```shell
# Generate plan to custom location
atmos terraform plan vpc -s dev -out=/tmp/vpc-dev.tfplan

# Apply that specific planfile
atmos terraform apply vpc -s dev --planfile /tmp/vpc-dev.tfplan
```

### Direct Apply (No Planfile)

When neither `--from-plan` nor `--planfile` is specified, Atmos will:

1. Generate a new plan
2. Show the planned changes
3. Prompt for approval (unless `-auto-approve` is used)
4. Apply the changes if approved

```shell
atmos terraform apply vpc -s dev
```

## Arguments

- **`component` (required)**

  Atmos component name to apply.

## Flags

- **`--stack` / `-s` (required)**

  Atmos stack name where the component is defined.
- **`--from-plan` (optional)**

  Apply the planfile previously generated by `atmos terraform plan`.

  The planfile must exist in the component directory with the standard Atmos naming convention.
  ```shell
  atmos terraform apply vpc -s dev --from-plan
  ```
- **`--planfile` (optional)**

  Apply a specific planfile at the given path.

  Use this instead of the native Terraform planfile argument.
  ```shell
  atmos terraform apply vpc -s dev --planfile /path/to/plan.tfplan
  ```
- **`--affected` (optional)**

  Apply only affected components based on changes in the repository.
  ```shell
  atmos terraform apply --affected
  ```
- **`--all` (optional)**

  Apply all components in all stacks (use with extreme caution).
  ```shell
  atmos terraform apply --all
  ```
- **`--dry-run` (optional)**

  Show what would be executed without actually running the apply.
  ```shell
  atmos terraform apply vpc -s dev --dry-run
  ```
- **`--skip-init` (optional)**

  Skip running `terraform init` before applying.
  ```shell
  atmos terraform apply vpc -s dev --skip-init
  ```
- **`--process-templates` (optional)**

  Enable/disable Go template processing in Atmos stack manifests.

  Default: `true`
  ```shell
  atmos terraform apply vpc -s dev --process-templates=false
  ```
- **`--ci` (optional)**

  Enable CI mode for automated pipelines. When enabled, Atmos writes job summaries, CI output variables, and status checks based on the [`ci` configuration](/cli/configuration/ci) in `atmos.yaml`.

  CI mode is auto-detected when `CI=true` or `GITHUB_ACTIONS=true` environment variables are set.

  **Environment variables:** `ATMOS_CI`, `CI`
  ```shell
  atmos terraform apply vpc -s dev --ci
  ```

## Native Terraform Flags

The `atmos terraform apply` command supports all native `terraform apply` flags. To pass native Terraform flags, you have two options:

1. **Direct flags** - Pass Terraform flags directly if they don't conflict with Atmos flags
2. **Double-dash separator** - Use `--` to explicitly separate Atmos flags from Terraform flags

:::tip Using the Double-Dash Separator
The `--` separator is a common Unix convention that indicates "end of options". Everything after `--` is passed directly to Terraform without interpretation by Atmos. This is useful when:

- You want to ensure a flag is passed to Terraform, not Atmos
- You're using flags that might conflict with Atmos flags
- You want to be explicit about which tool receives which flags

**Example:**

```shell
atmos terraform apply vpc -s dev -- -auto-approve -parallelism=20
```

:::

Some commonly used native flags include:

- **`-auto-approve`**

  Apply changes without manual approval prompt.
  ```shell
  atmos terraform apply vpc -s dev -auto-approve
  ```
  :::warning
  Use `-auto-approve` with caution, especially in production environments.
  :::
- **`-target=RESOURCE`**

  Apply changes only to specific resources. Can be specified multiple times.
  ```shell
  atmos terraform apply vpc -s dev -target=aws_subnet.private -target=aws_route_table.private
  ```
- **`-var 'NAME=VALUE'`**

  Set a variable value. Can be specified multiple times.
  ```shell
  atmos terraform apply vpc -s dev -var="instance_count=3"
  ```
- **`-refresh-only`**

  Only update the state to match remote systems.
  ```shell
  atmos terraform apply vpc -s dev -refresh-only
  ```
- **`-replace=RESOURCE`**

  Force replacement of a specific resource.
  ```shell
  atmos terraform apply vpc -s dev -replace=aws_instance.web
  ```

## Best Practices

### Two-Stage Apply Process

For production environments, we recommend a two-stage apply process:

```shell
# Stage 1: Generate and review the plan
atmos terraform plan vpc -s prod

# Review the plan output carefully...

# Stage 2: Apply the exact reviewed plan
atmos terraform apply vpc -s prod --from-plan
```

This ensures that:

- Changes are reviewed before applying
- No configuration drift occurs between plan and apply
- The exact reviewed changes are applied

### Automated Deployments

For CI/CD pipelines, you can:

1. Generate a plan in one job:
   ```shell
   atmos terraform plan vpc -s prod -out=plan.tfplan
   ```

2. Apply the plan in another job (after approval):
   ```shell
   atmos terraform apply vpc -s prod --planfile plan.tfplan
   ```

Or use `atmos terraform deploy` for fully automated deployments:

```shell
atmos terraform deploy vpc -s prod
```

## Multi-Component Operations

Execute `terraform apply` across multiple components using filtering flags. All flags can be combined with `--dry-run` to preview what would be executed.

:::warning
Multi-component apply operations can make significant infrastructure changes. Always use `--dry-run` first to verify which components will be affected.
:::

### Apply All Components

```shell
# Apply all components in all stacks
atmos terraform apply --all

# Apply all components in a specific stack
atmos terraform apply --all --stack prod
atmos terraform apply --stack prod
```

### Apply Affected Components

Apply only components affected by changes in the current branch (requires git). Components are processed in dependency order:

```shell
# Apply affected components in all stacks
atmos terraform apply --affected

# Apply affected components in a specific stack
atmos terraform apply --affected --stack prod

# Include dependent components (components that depend on affected components)
atmos terraform apply --affected --include-dependents

# Clone the target reference instead of checking it out
atmos terraform apply --affected --clone-target-ref=true
```

### Apply Specific Components

```shell
# Apply specific components in all stacks
atmos terraform apply --components vpc,eks

# Apply specific components in a specific stack
atmos terraform apply --components vpc,eks --stack prod
```

### Apply Components by Query

Filter components using [YQ](https://mikefarah.gitbook.io/yq) expressions against component configuration:

```shell
# Apply components where team tag equals "eks"
atmos terraform apply --query '.vars.tags.team == "eks"'

# Apply components in a specific account
atmos terraform apply --query '.settings.context.account_id == 12345'

# Combine with stack filter
atmos terraform apply --query '.vars.tags.team == "eks"' --stack prod
```

### Multi-Component Flags

- **`--all`**
  Apply all components in all stacks (or specified stack with 
  `--stack`
  ).
- **`--affected`**
  Apply components affected by git changes in dependency order. Supports all flags from 
  [`atmos describe affected`](/cli/commands/describe/affected)
  .
- **`--components`**
  Apply specific components by name (comma-separated or repeated flag).
- **`--query`**
  Apply components matching a YQ expression. All Atmos sections are available: 
  `vars`
  , 
  `settings`
  , 
  `env`
  , 
  `metadata`
  , etc.
- **`--include-dependents`**
  With 
  `--affected`
  , also apply components that depend on affected components, recursively.
- **`--ref`**
  Git reference to compare against (branch or tag). Default: 
  `refs/remotes/origin/HEAD`
  .
- **`--sha`**
  Git commit SHA to compare against.
- **`--clone-target-ref`**
  Clone the target reference instead of checking it out locally.

## CI Integration

> ⚠️ Experimental

When running in CI mode (`--ci` flag or auto-detected), Atmos produces rich CI artifacts:

- **Job summaries** with resource counts, apply results, and terraform outputs written to `$GITHUB_STEP_SUMMARY`
- **Output variables** (`success`, `has_changes`, `exit_code`, etc.) written to `$GITHUB_OUTPUT`
- **Status checks** showing apply progress and results (requires `ci.checks.enabled: true`)

```shell
# In GitHub Actions (auto-detected)
atmos terraform apply vpc -s dev

# Explicit CI mode
atmos terraform apply vpc -s dev --ci
```

:::info
See [CI Configuration](/cli/configuration/ci) for full configuration options including custom templates, status checks, and output variables.
:::

## Related Commands

- [`atmos terraform plan`](/cli/commands/terraform/plan) - Generate an execution plan
- [`atmos terraform deploy`](/cli/commands/terraform/deploy) - Apply with auto-approval
- [`atmos terraform destroy`](/cli/commands/terraform/destroy) - Destroy infrastructure
- [`atmos terraform plan-diff`](/cli/commands/terraform/plan-diff) - Compare plan files

## Configuration

Configure default behavior for `terraform apply` in your `atmos.yaml`:

```yaml
components:
  terraform:
    # Auto-approve all applies (use with caution)
    apply_auto_approve: false

    # Auto-generate backend configuration
    auto_generate_backend_file: true
```

:::info
See [Terraform Planfiles](/components/terraform/planfiles) for a comprehensive guide on working with planfiles in Atmos.
:::

:::note
The `atmos terraform apply` command supports all native `terraform apply` options described in [Terraform apply options](https://developer.hashicorp.com/terraform/cli/commands/apply#apply-options), except that planfile arguments should use `--from-plan` or `--planfile` flags instead of being passed directly.
:::