When working with Terraform Stacks, one of the first things you’ll notice — especially if you’re relying on community samples — is the variety of file extensions used in different configurations. Traditionally, examples have included filenames like *.tfdeploy.hcl and *.tfstack.hcl. These have served as the foundational configuration files for defining deployment behaviors and stack structure. However, there’s a quiet but notable shift happening: Terraform Stacks appears to be moving toward the use of *.tfcomponent.hcl in place of *.tfstack.hcl.

This shift is more than a simple renaming convention. It reflects a conceptual evolution in how components are defined and managed within a Terraform Stacks architecture. As the tooling continues to mature, expect *.tfcomponent.hcl to become the preferred standard for new configurations.

Alt

File Structure: What to Expect With this change, your file structure will likely look something like this:

my-terraform-project/
│
├── deployments.tfdeploy.hcl
├── components.tfcomponent.hcl
├── providers.tfcomponent.hcl
├── variables.tfcomponent.hcl
├── .terraform.lock.hcl
├── .terraform-version
└── ...

Alt

It’s important to clarify that not all of these files are created by hand. Some are automatically generated when you initialize your stack using terraform-stacks init, while others, like your component or deploy files, are manually authored. One standout in this structure is .terraform.lock.hcl, which is entirely tool-generated—and for good reason.

The Lock File

The .terraform.lock.hcl is 100% tool generated and trust me, you are glad that it is. At first glance, the lock might seem like one of those obscure artifacts that just appears when you run commands, quietly occupying space in your repo. You might even question its necessity. But rest assured, it’s doing more than just sitting there.

Alt

The lock file is a critical part of Terraform’s effort to ensure software supply chain security. It locks the specific versions and cryptographic hashes of every Terraform provider your stack uses. This mechanism guarantees that when you run Terraform Cloud, it pulls down exactly the same provider binaries every time.

This predictability is not only about stability — it’s a defense against supply chain attacks. By verifying provider integrity against known hashes, Terraform prevents tampered or unexpected binaries from entering your infrastructure provisioning process.

Still, as a user, it’s fair to wonder whether this could be handled more transparently. Why does the lock file have to be visible at all? Couldn’t Terraform abstract this step entirely, like how many package managers manage lock files behind the scenes? While transparency is often valuable, perhaps there’s room for improving the developer experience here — especially for those new to the ecosystem.

A Small Shift with Larger Implications

The move from *.tfstack.hcl to *.tfcomponent.hcl might seem like a minor detail, but it’s part of a broader pattern in Terraform Stacks: increased clarity, stronger modularity, and better support for secure and reproducible infrastructure management. As conventions evolve, keeping pace with these changes ensures not only compatibility but also a deeper understanding of the tool’s design philosophy.

At the same time, features like the .terraform.lock.hcl file remind us that infrastructure-as-code isn’t just about automation—it’s about trust. Even if parts of the experience feel a bit arcane, they often exist to protect us from very real risks in the software supply chain.