atmos terraform

Use these subcommands to interact with Terraform and OpenTofu.

atmos terraform --help

Atmos Terraform/OpenTofu commands fall into two categories:

Single-Component: Run Terraform for one component at a time
Multi-Component (Filtered/Bulk): Run Terraform across multiple components using stack names, selectors, or change detection

Atmos supports all Terraform and OpenTofu commands and options described in Terraform CLI Overview and OpenTofu Basic CLI Features.

In addition, for the Single-Component commands, the component argument and stack flag are required to generate variables and backend config for the component in the stack.

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.

Single-Component Commands Usage

Use single-component commands when you want to execute Terraform operations on one component at a time, offering precise control over individual resources.

# Execute `terraform <command>` on a `component` in a `stack`
atmos terraform <command> <component> -s <stack> [options]
atmos terraform <command> <component> --stack <stack> [options]

Multi-Component Commands (Bulk Operations) Usage

Use multi-component commands to run Terraform operations across multiple components simultaneously. You can target components by stack, selector, query, or change detection—often making this approach more efficient than using Atmos workflows for certain use cases.

# Execute `terraform <command>` on all components in the stack `prod`
atmos terraform <command> --stack prod

# Execute `terraform <command>` on components `component-1` and `component-2` in all stacks
atmos terraform <command> --components component-1,component-2

# Execute `terraform <command>` on components `component-1` and `component-2` in the stack `prod`
atmos terraform <command> --stack prod --components component-1,component-2

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

# Execute `terraform <command>` on all components in the stack `prod`
atmos terraform <command> --all --stack prod

# Execute `terraform <command>` on all the directly affected components in all stacks in dependency order
# (if component dependencies are configured)
atmos terraform <command> --affected

# Execute `terraform <command>` on all the directly affected components in the `prod` stack in dependency order
# (if component dependencies are configured)
atmos terraform <command> --affected --stack prod

# Execute `terraform <command>` on all the directly affected components in all stacks in dependency order.
# 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 <command> --affected --include-dependents

# Execute `terraform <command>` on all the directly affected components in the `prod` stack in dependency order.
# For each directly affected component, detect the dependent components and process them in dependency order, recursively.
atmos terraform <command> --affected --include-dependents --stack prod

# Execute `terraform <command>` on all components that have `vars.tags.team == "data"`, in all stacks
atmos terraform <command> --query '.vars.tags.team == "data"'

# Execute `terraform <command>` on all components that have `vars.tags.team == "eks"`, in the stack `prod`
atmos terraform <command> --query '.vars.tags.team == "eks"' --stack prod

# Execute `terraform <command>` on all components that have `settings.context.account_id == 12345`, in all stacks
atmos terraform <command> --query '.settings.context.account_id == 12345'

Additions and differences from native Terraform and OpenTofu

before executing other terraform commands, Atmos runs terraform init
you can skip over atmos calling terraform init if you know your project is already in a good working state by using the --skip-init flag like so atmos terraform <command> <component> -s <stack> --skip-init
atmos terraform deploy command executes terraform apply -auto-approve (sets -auto-approve flag when running terraform apply)
atmos terraform deploy command supports --deploy-run-init=true|false flag to enable/disable running terraform init before executing the command
atmos terraform apply and atmos terraform deploy commands support --from-plan flag. If the flag is specified, the commands will use the planfile previously generated by atmos terraform plan command instead of generating a new planfile, e.g. atmos terraform apply <component> -s <stack> --from-plan. Note that in this case, the planfile name is in the format supported by Atmos and is saved to the component's folder. See Terraform Planfiles for comprehensive planfile documentation
atmos terraform apply and atmos terraform deploy commands support --planfile flag to specify the path to a planfile. The --planfile flag should be used instead of the planfile argument in the native terraform apply <planfile> command. For example, you can execute the command atmos terraform plan <component> -s <stack> -out=<FILE>, which will save the generated plan to a file on disk, and then execute the command atmos terraform apply <component> -s <stack> --planfile <FILE> to apply the previously generated planfile. Learn more in the terraform apply documentation
atmos terraform plan command accepts a --skip-planfile flag to skip writing the plan to a file. If the flag is set to true (e.g., atmos terraform plan <component> -s <stack> --skip-planfile=true), Atmos will not pass the -out flag to Terraform when executing the command. 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. See terraform plan for details
atmos terraform clean command deletes the .terraform folder, .terraform.lock.hcl lock file, and the previously generated planfile and varfile for the specified component and stack. Use the --skip-lock-file flag to skip deleting the .terraform.lock.hcl file. It deletes all local Terraform state files and directories (including terraform.tfstate.d used for local state) for a component in a stack. The --force flag bypasses the safety confirmation prompt and forces the deletion. Use with caution.

warning
The clean command performs destructive operations that can lead to permanent state loss, if not using remote backends. Always ensure you have remote state configured in your components before proceeding.
atmos terraform workspace command first runs terraform init -reconfigure, then terraform workspace select, and if the workspace was not created before, it then runs terraform workspace new
atmos terraform import command searches for region in the variables for the specified component and stack, and if it finds it, sets AWS_REGION=<region> ENV var before executing the command
atmos terraform generate backend command generates a backend config file for an Atmos component in a stack
atmos terraform generate backends command generates backend config files for all Atmos components in all stacks
atmos terraform generate varfile command generates a varfile for an Atmos component in a stack
atmos terraform generate varfiles command generates varfiles for all Atmos components in all stacks
atmos terraform plan-diff command compares two Terraform plans and shows the differences between them. It takes an original plan file (--orig) and optionally a new plan file (--new). If the new plan file is not provided, it will generate one by running terraform plan with the current configuration.
atmos terraform shell command configures an environment for an Atmos component in a stack and starts a new shell allowing executing all native terraform commands inside the shell
double-dash -- can be used to signify the end of the options for Atmos and the start of the additional native arguments and flags for the terraform commands. For example:
- atmos terraform plan <component> -s <stack> -- -refresh=false
- atmos terraform apply <component> -s <stack> -- -lock=false

tip

Run atmos terraform --help to see all the available options

Examples

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

# 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

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

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.

Flags

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

Atmos stack.

atmos terraform plan <component> --stack <stack>
atmos terraform apply --all -s <stack>

--dry-run (optional)

Dry run. Simulate the command without making any changes.

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.

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

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.

atmos terraform plan <component> -s <stack> --process-templates=false

--process-functions (optional)

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

If the flag is not passed, YAML function processing is enabled by default.

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.

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.

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.

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 expression, in all stacks or in a specific stack.

NOTE: All Atmos sections are available in the expression, e.g. vars, settings, env, metadata, backend, etc.

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 are configured).

NOTE: When using the --affected flag, Atmos supports all the flags from the atmos describe affected CLI command.

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 of the components that are modified.

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 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.

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): 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

# Use specific identity
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>

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 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:

`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:

atmos terraform apply --all --dry-run

# 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"

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

# 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"

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

# 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"

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

# 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"

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

# 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"

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

# 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"

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

# 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"

atmos terraform apply --affected --dry-run

# 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"

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

# 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"

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

# 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

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

# 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.

Learn More

Subcommands

📄️ 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.

📄️ clean

Use this command to clean up Terraform files for an Atmos component in a stack. This removes .terraform folder, .terraform.lock.hcl file, and Atmos-generated varfiles and planfiles.

📄️ console

Use this command to open an interactive Terraform console for an Atmos component in a stack, with all component variables and configuration pre-loaded.

📄️ deploy

Use this command to deploy Terraform changes for an Atmos component in a stack with auto-approval. This combines plan and apply operations in a single command.

📄️ destroy

Use this command to destroy Terraform-managed infrastructure for an Atmos component in a stack. This operation removes all resources managed by the component.

📄️ fmt

Use this command to format Terraform HCL configuration files for an Atmos component to canonical format and style.

📄️ force-unlock

Use this command to manually unlock the Terraform state for an Atmos component in a stack when automatic unlocking fails.

📄️ generate backend

Use this command to generate a Terraform backend config file for an Atmos terraform component in a stack.

📄️ generate backends

Use this command to generate the Terraform backend config files for all Atmos terraform components in all stacks.

📄️ generate planfile

Use this command to generate a Terraform planfile for an Atmos component in a stack and convert it to JSON or YAML format for review.

📄️ generate varfile

Use this command to generate a .tfvar.json variable file for an Atmos component in a stack with all configured values.

📄️ generate varfiles

Use this command to generate the Terraform varfiles (`.tfvar`) for all Atmos terraform components in all stacks.

📄️ get

Use this command to download and update Terraform modules for an Atmos component. This ensures all module dependencies are available locally.

📄️ graph

Use this command to generate a visual dependency graph for an Atmos component's Terraform resources in a specific stack.

📄️ import

Use this command to import existing infrastructure resources into the Terraform state for an Atmos component in a stack.

📄️ init

Use this command to initialize the Terraform working directory for an Atmos component in a stack. This prepares the component for other Terraform operations.

📄️ login

Use this command to authenticate with Terraform Cloud or Terraform Enterprise for an Atmos component in a stack.

📄️ logout

Use this command to remove Terraform Cloud or Terraform Enterprise credentials for an Atmos component in a stack.

📄️ metadata

Use this command to retrieve Terraform metadata functions for an Atmos component in a stack.

📄️ modules

Use this command to list all Terraform modules used by an Atmos component in a stack.

📄️ output

Use this command to read Terraform output values for an Atmos component in a stack from the state file.

📄️ plan-diff

The atmos terraform plan-diff command compares two Terraform plans and shows the differences between them.

📄️ plan

Use this command to generate a Terraform execution plan for an Atmos component in a stack, showing what changes would be made to your infrastructure.

📄️ providers

Use this command to display provider requirements and configurations for an Atmos component's Terraform configuration in a stack.

📄️ refresh

Use this command to refresh the Terraform state for an Atmos component in a stack, updating it to match the current remote infrastructure.

📄️ shell

This command starts a new `SHELL` configured with the environment for an Atmos component in a stack to allow execution of all native terraform commands inside the shell without using any atmos-specific arguments and flags. This may by helpful to debug a component without going through Atmos.