> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fastfoundation.nimble.la/llms.txt
> Use this file to discover all available pages before exploring further.

# Terragrunt.hcl template

> Learn the required structure for Terragrunt files in Fast Foundation and best practices for naming resources

## Overview

To integrate smoothly with **Fast Foundation**, each Terragrunt unit requires specific configuration blocks in its `terragrunt.hcl` file. These ensure that parameter management, resource orchestration, and naming conventions remain consistent across environments.

***

## Required Components

Your `terragrunt.hcl` should always include:

1. **Includes blocks**
   * Root include (`root.hcl`): This will include root values plus all [shared configuration files](/introduction-key-concepts/2-terragrunt-guide#shared-config-files) values.

2. **Locals block**
   * Secret management variables (if the Unit makes use of them)
   * Variables from `inputs.hcl` and shared config files can be defined here for improved readability.

3. **Inputs block**
   * Values passed into the Terraform module
   * Typically merged with environment and service variables defined higher in the repo hierarchy

***

## Example terragrunt.hcl

```hcl theme={null}
terraform {
  source = "git::git@github.com:<your-org>/<your-modules-repo>.git//modules/my-module?ref=my-module/v1.5.0"
}

include "root" {
  path   = find_in_parent_folders("root.hcl")
  expose = true
}

locals {
  # Shared Configurations
  region_vars          = include.root.locals.region_vars.locals
  service_vars         = include.root.locals.service_vars.locals
  account_vars         = include.root.locals.account_vars.locals
  environment_vars     = include.root.locals.environment_vars.locals
  
  # Unit Inputs from inputs.hcl
  inputs = try(read_terragrunt_config("${get_terragrunt_dir()}/inputs.hcl").locals, {})
}

inputs = {
  # Resource naming (best practice)
  name = basename(get_terragrunt_dir())
  # Add your module-specific inputs here
}
```

## Naming Best Practice

If possible, use the **folder name as the resource name**. This keeps the repository intuitive: the folder you are working in directly reflects the deployed resource.

It simplifies navigation, debugging, and collaboration across teams.

***

## Want to dive deeper?

Ready to explore these concepts in more detail? Check out our hands-on workshops:

<CardGroup cols={2}>
  <Card title="Deploy an EC2 instance" icon="cube" href="/workshops/1-deploy-ec2-instance">
    Learn step-by-step how to create an EC2 instance with external modules.
  </Card>

  <Card title="Deploy a custom module" icon="cube" href="/workshops/2-deploy-custom-module">
    Learn step-by-step how to create and deploy a custom wrapper module.
  </Card>

  <Card title="Users and Groups Management" icon="users" href="/workshops/3-user-management">
    Dive into AWS SSO, groups, and permission sets,\
    and practice managing users in a safe environment.
  </Card>

  <Card title="Users and Groups Management with External Identity Provider (IdP)" icon="users" href="/workshops/4-user-management-external-idp">
    Dive into AWS SSO, groups, and permission sets,\
    and practice managing users in a safe environment.
  </Card>
</CardGroup>