Component architecture: Terraform root modules, abstract components, component inheritance, versioning, mixins, catalog patterns
Components are the building blocks of infrastructure in Atmos. Each component is an opinionated, reusable unit of infrastructure-as-code -- typically a Terraform root module -- that solves a specific problem. Atmos separates the component implementation (code) from its configuration (stack manifests), enabling one implementation to be deployed many times with different settings.
In Atmos, a component consists of two parts:
components/ directory.components section.This separation is fundamental: you write the Terraform module once, then configure it differently for each environment, region, and account through stack YAML files.
Atmos natively supports three component types:
| Type | Implementation Location | Purpose |
|---|---|---|
| Terraform / OpenTofu | components/terraform/<name>/ | Provision cloud infrastructure resources |
| Helmfile | components/helmfile/<name>/ | Deploy Helm charts to Kubernetes clusters |
| Packer | components/packer/<name>/ | Build machine images (AMIs, VM images) |
Terraform is by far the most common type. Custom commands can extend Atmos to support any tooling.
Components are stored in your project's components/ directory, organized by type:
components/
terraform/
vpc/
main.tf
variables.tf
outputs.tf
versions.tf
eks/
cluster/
main.tf
variables.tf
outputs.tf
s3-bucket/
main.tf
variables.tf
outputs.tf
iam-role/
main.tf
variables.tf
outputs.tf
helmfile/
nginx-ingress/
helmfile.yaml
cert-manager/
helmfile.yaml
packer/
ubuntu-base/
template.pkr.hcl
The base path for Terraform components is configured in atmos.yaml: