Terraform manages dependencies between resources within a single state. The moment your infrastructure outgrows one state file — slow plans, wide blast radius, team contention — you need to split. But the pieces still depend on each other: compute needs the VPC ID from networking, application infrastructure needs the cluster endpoint from compute.
The usual approaches — terraform_remote_state, parameter stores, wrapper scripts, Terragrunt — each solve part of the problem but leave gaps in change detection, ordering enforcement, and visibility. For a walkthrough of these approaches and how to perform the split itself, see Splitting a Terraform Monolith.
Snap CD's module system was built specifically for what comes after the split: declaring the dependency graph as code, enforcing apply ordering, and cascading changes automatically.
Managing Snap CD with Terraform
The HCL examples throughout this guide use the Snap CD Terraform provider. This is the canonical way to configure Snap CD — you use Terraform to manage the system that manages your Terraform modules. Everything you see in the examples below — the hierarchy, the dependency wiring, the secret bindings — is declared as standard Terraform resources via this provider.
