Conditional Component Dependencies
Infrastructure graphs often include dependencies that are useful when present but should not block an environment when a component is intentionally absent or disabled. Treating every dependency as mandatory forces stack-specific workarounds and makes reusable manifests harder to share.
The Problem
A component dependency previously meant that the target had to exist and be available. That is correct for core infrastructure, but too strict for optional integrations such as observability, auxiliary services, or environment-specific components. Teams had to duplicate manifests or maintain separate dependency lists just to handle those differences.
The Fix
Component dependencies can now declare required: false:
dependencies:
components:
- name: observability
required: false
Required dependencies remain the default, preserving existing behavior. Optional dependencies are included normally when their target is present, enabled, and concrete. Missing, disabled, or abstract targets simply omit that edge. Invalid dependency configuration still fails instead of being hidden by optionality.
The required value can also be rendered from a template. Atmos applies the configured template delimiters before parsing the result as a boolean:
required: "[[ .vars.enable_monitoring ]]"
This allows one manifest to use environment-specific optionality without assuming the default {{ and }} delimiters.
How to Use It
Use required: false for a dependency that should participate in ordering when available but should not prevent the declaring component from running when unavailable:
components:
terraform:
application:
dependencies:
components:
- name: network
- name: monitoring
stack: "{{ .vars.environment }}-observability"
required: false
Omit required when the target must be present, enabled, and concrete. Optionality only suppresses missing, disabled, or abstract targets; malformed entries remain errors.
Get Involved
Try conditional dependencies in your stack manifests and share feedback through GitHub.
