Skip to main content
In this lesson, we explore how terragrunt init and terragrunt validate work under the hood and in practice. These commands streamline your Terraform workflow when using Terragrunt.

​
terragrunt init

The terragrunt init command sets up your working directory based on terragrunt.hcl, handling:
  • Provider plugin installation and updates
  • Module dependency resolution and download
  • Backend initialization for state management
Terragrunt automatically inherits backend settings from your root terragrunt.hcl. If you modify source or backend blocks, re-run terragrunt init.
The image illustrates the "Terragrunt init" process, highlighting components like Terragrunt.hcl, module dependencies, and provider plugins.
After initialization, your directory is ready for planning and applying infrastructure changes.

​
terragrunt validate

The terragrunt validate command performs a syntax and semantic check on your Terraform configurations:
  • Ensures HCL syntax is correct
  • Verifies required variables and providers are defined
  • Catches common misconfigurations before planning
The image illustrates the purpose of "Terragrunt validate," highlighting its role in verifying syntax and semantics and ensuring structured data.
Run terragrunt validate early to catch errors in development:
The image is an infographic about "Terragrunt validate," highlighting its workflow benefits: running before planning, validating changes during development, and helping catch errors early.
Under the hood, Terragrunt calls Terraform’s terraform validate:
The image features the text "Terragrunt validate" with a Terraform logo and a magnifying glass icon, along with the phrase "Integration With Terraform" at the bottom.

​
Parallel Validation Across Modules

In large, modular projects you can run all validations in parallel: 
terragrunt run-all validate
The image is a diagram highlighting features of "Terragrunt validate," including multiple modules, improved efficiency, and modular structures, with a focus on parallel execution.
Running run-all validate may trigger API rate limits if modules share provider endpoints. Monitor your quotas during parallel execution.

​
Best Practices

Integrate terragrunt validate into your CI/CD pipeline to enforce checks before deployment:
The image is about "Terragrunt validate" and highlights its inclusion in continuous integration pipelines and consistent validation, with a "Best Practices" button at the bottom.

​
Command Reference

CommandPurposeExample Usage
terragrunt initInitialize plugins, modules, backendterragrunt init
terragrunt validateCheck HCL syntax and semanticsterragrunt validate
terragrunt run-all validateValidate all modules in parallelterragrunt run-all validate

​
Example: Using terragrunt init & terragrunt validate

Below is a basic terragrunt.hcl for an AWS VPC module: 
# terragrunt.hcl
terraform {
  source = "tfr://terraform-aws-modules/vpc/aws//?version=5.8.1"
}

inputs = {
  name = "KodeKloud-VPC"
}
Initialize and validate in the same folder: 
$ terragrunt init
Initializing the backend...
Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using previously-installed hashicorp/aws v5.51.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work.

If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.

$ terragrunt validate
Success! The configuration is valid.
That concludes our overview of terragrunt init and terragrunt validate. By initializing early and validating frequently, you ensure reliable, maintainable infrastructure as code.

Watch Video