Terraform Simple Project Structure

When setting up a terraform simple project structure, there are multiple ways to name Terraform files and organize folders. For a simple

  • you’re learning the workflow (init → plan → apply)
  • there is only one or two resources
  • you don’t have variables, outputs, or environments yet
terraform simple project structure diagram showing single file example and better approach

Simple example (single file)

hello_world/
  hello_world.tf.

That said, Terraform doesn’t care whether you write everything in one file or ten files. Terraform loads all *.tf files in the same directory and treats them as one combined configuration. So this also works:

hello_world/
  resource_one.tf
  resource_two.tf

Why resource_one.tf and resource_two.tf is a “bad” pattern

It’s not “wrong” technically, but it becomes hard to maintain as your infra grows:

  • No meaning in the name: “resource_one” doesn’t tell what it creates.
  • Harder to review: code reviewers can’t quickly understand intent.
  • Harder to find things: “Where is VPC defined?” becomes a search problem.
  • Poor scaling: once you have 30+ resources, numbered files turn into chaos.

Best terraform simple project structure: split files by purpose

A clean approach is: each file represents a clear purpose either grouped by resource type (networking, compute, database) or by feature/domain (app stack, observability, security).

Here’s a very common, clean structure for a single stack:

my_infra/
  main.tf
  providers.tf
  versions.tf
  variables.tf
  outputs.tf
  networking.tf
  compute.tf
  database.tf
  iam.tf

What each file typically contains

  • versions.tf → required Terraform version + provider versions
  • providers.tf → provider config (region, auth, aliases, etc.)
  • variables.tf → input variables
  • outputs.tf → outputs to expose important values
  • networking.tf → VPC/VNet, subnets, routing, security groups
  • compute.tf → VM/EC2/ECS/EKS/AKS related resources
  • database.tf → RDS/SQL, Mongo, cache, etc.
  • iam.tf → roles/policies/service accounts (security related)

There is one more advanced way to go about it which we will discuss in the upcoming posts.For more DevOps best practices, check out our guide on infrastructure as code.

A well-organized project structure makes collaboration easier and helps teams maintain infrastructure code more effectively over time. Following these naming conventions will save you hours of debugging and make your Terraform configurations much more maintainable. Start with this simple structure and scale it as your infrastructure grows.

srnyapathi
srnyapathi
Articles: 41