Monorepo vs multi-repo for Terraform - CLI Comparison

Introduction

When managing infrastructure as code with Terraform, you can organize your code in one big repository or split it into many smaller ones. Choosing between a monorepo and multi-repo setup affects how you work on, test, and deploy your infrastructure.

When you want all your infrastructure code in one place for easier sharing and consistency.

When different teams manage separate parts of infrastructure and need isolated codebases.

When you want to deploy all infrastructure changes together to avoid version mismatches.

When you want to limit the blast radius of changes by isolating infrastructure components.

When you want to reuse common Terraform modules across multiple projects.

Commands

Initializes the Terraform working directory by downloading required providers and setting up the backend. Run this first in any Terraform repo.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.0.0...

- Installed hashicorp/aws v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!

Shows the changes Terraform will make to your infrastructure based on your current code. Use this to review before applying.

Terminal

terraform plan

Expected Output

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # aws_instance.example will be created

  + resource "aws_instance" "example" {

      + ami           = "ami-0c55b159cbfafe1f0"

      + instance_type = "t2.micro"

    }



Plan: 1 to add, 0 to change, 0 to destroy.

Applies the planned changes to create or update infrastructure. The -auto-approve flag skips manual confirmation.

Terminal

terraform apply -auto-approve

Expected Output

aws_instance.example: Creating...

aws_instance.example: Still creating... [10s elapsed]

aws_instance.example: Creation complete after 15s [id=i-0abcd1234efgh5678]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approve the apply without prompting

Clones a Terraform monorepo repository containing all infrastructure code in one place.

Terminal

git clone https://github.com/example-org/terraform-infra.git

Expected Output

Cloning into 'terraform-infra'...

remote: Enumerating objects: 100, done.

remote: Counting objects: 100% (100/100), done.

remote: Compressing objects: 100% (80/80), done.

Receiving objects: 100% (100/100), 1.2 MiB | 2.0 MiB/s, done.

Clones a Terraform multi-repo repository focused only on network infrastructure.

Terminal

git clone https://github.com/example-org/terraform-network.git

Expected Output

Cloning into 'terraform-network'...

remote: Enumerating objects: 50, done.

remote: Counting objects: 100% (50/50), done.

remote: Compressing objects: 100% (40/40), done.

Receiving objects: 100% (50/50), 600 KiB | 1.0 MiB/s, done.

Key Concept

If you remember nothing else from this pattern, remember: monorepos keep all infrastructure code together for easier coordination, while multi-repos isolate components for safer, team-specific changes.

Common Mistakes

Trying to apply Terraform changes across multiple repos without coordinating versions

This can cause mismatched infrastructure states and unexpected failures.

Use versioned modules and clear deployment order when using multi-repos.

Putting all infrastructure code in one monorepo without clear folder structure

This makes the repo hard to navigate and increases risk of accidental changes.

Organize monorepos with clear directories per component and use Terraform workspaces or modules.

Summary

terraform init sets up the working directory and downloads providers.

terraform plan previews infrastructure changes before applying.

terraform apply creates or updates infrastructure based on the plan.

Monorepos centralize all Terraform code; multi-repos split code by component or team.

Choose monorepo for easier coordination; choose multi-repo for isolated, safer changes.