Terraform components allow you to deploy Terraform from a public or connected
repo, to provision infrastructure resources in customer installs.
To configure a Terraform component, specify a repo, the required configuration
values, and the version of Terraform to run it with.
components/<your-component>.toml
public_repo block) or a private GitHub repo (using a connected_repo block).
Read more about VCS configuration here.
You can also put the Terraform source inside of the same repo as your app config, and point to it.
If you include the Terraform source in the app config repo, push the source along with the rest of the repo. A branch run rebuilds a component when its config changes, so a push that changes only the Terraform source does not rebuild it. After that push, run nuon branches trigger --branch-id <branch> --force, or build the component manually in the dashboard or CLI.
components/<your-component>.toml
State Management
All Terraform state is managed by the Nuon data plane through the Nuon
http-based API.
Each execution of a Terraform component in an install is visible in the plan and apply steps in the dashboard.
The Enterprise edition has two additional features including requiring approvals of the plan and apply steps and showing diffs from previous runs.
Execution and Permissions
The runner is responsible for executing Terraform, and is
provisioned as part of the initial Install Stack. e.g., in AWS, the
CloudFormation stack creates a VPC, networking, ASG and an EC2 instance to start
the runner. The runner is separate from the Install’s infrastructure e.g.,
Kubernetes cluster.
To learn more about the runner, read the
Nuon Runner Architecture
blog post.
Per-install variable overrides
To override a Terraform module’s variables for a single install without changing your app config, use
component overrides. 
