Skip to main content
One of the biggest challenges as your Terraform codebase grows is keeping configuration DRY (Don’t Repeat Yourself). Repeated strings, naming conventions, tags, or computed expressions increase maintenance effort and the risk of human error when promoting changes between environments. Terraform locals let you define a value once and reference it everywhere. That reduces duplication, simplifies updates, and makes configurations easier to read and reason about. In this guide you’ll learn what locals are, why and when to use them, and practical patterns for centralizing shared values.

​
Problem: repeated values across resources

Imagine multiple resources referencing the same environment name or prefix. Copy-pasting strings across resource blocks might work at first, but moving from dev to prod forces edits in many places and can introduce inconsistencies. Example of repetitive, error-prone code: 
resource "some_resource" "server_abc" {
  argument      = var.argument
  argument_type = var.argument_type

  tags = {
    Name        = var.app_name
    ManagedBy   = "Terraform"
    Team        = var.team
    Environment = var.environment
    ID          = "server-${var.environment}-${var.server}"
  }
}

resource "some_resource" "server_xyz" {
  argument      = var.argument
  argument_type = var.argument_type

  tags = {
    Name        = "${var.app_name}-${var.server}-xyz"
    ManagedBy   = "Terraform"
    Team        = var.team
    Environment = var.environment
    ID          = "server-${var.environment}-${data.aws_region.current.name}-${var.server[1]}"
  }
}
This structure is repetitive and error-prone: a single shared concept (for example, an environment name or a common tag) gets repeated in multiple places.

​
What locals are and how they help

Local values (locals) are named expressions you define once and reference anywhere in a Terraform configuration with local.<name>. Locals are ideal for:
  • Naming conventions (prefixes, suffixes)
  • Standard tag maps
  • Derived or computed values that combine variables and data sources
  • Hiding complex expressions behind a descriptive name
Define shared values in a locals block and reference them across resources — change the value in one place and Terraform will apply it everywhere it’s used.
The image explains local values in Terraform, describing them as named values for code reference and centralizing frequently used values like names and environments.

​
Defining and referencing locals

A basic locals block is straightforward: 
locals {
  app_name    = "my-app"
  environment = "dev"
}
Use local.app_name or local.environment in resource blocks, outputs, and other expressions. Because locals are evaluated during planning/applying, updating the definition updates every dependent expression.

​
Example: centralizing naming across resources

Move duplicated naming logic into a locals block to build consistent resource names: 
# Define shared values in locals
locals {
  environment = "dev"
  prefix      = "myorg"
}

resource "github_repository" "dev_repo" {
  name        = "${local.prefix}-${local.environment}-repo"
  visibility  = "private"
  description = "Terraform-managed repo for dev environment"
}

resource "github_team" "awesome_people" {
  name        = "${local.prefix}-${local.environment}-team"
  description = "My Awesome Team"
  privacy     = "closed"
}
Now local.prefix and local.environment are the single source of truth for these names. Change them once to propagate updates.

​
Grouping locals and referencing locals from locals

You can have multiple locals blocks for readability. Locals may reference other locals (avoid circular references). Example: group common tags and reference a local inside another locals block: 
locals {
  app_team = "customer-experience"
}

locals {
  # Common tags to be applied to resources
  common_tags = {
    Name      = var.app_name
    Owner     = var.owner
    App       = var.app
    Service   = "${var.team}-${var.app}-${var.environment}"
    AppTeam   = local.app_team
    CreatedBy = data.aws_caller_identity.current.account_id
    Image     = data.aws_ami.ubuntu.name
  }
}
Then apply the local.common_tags map to any resource that supports tags: 
resource "aws_instance" "web_server" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  subnet_id     = var.aws_subnet.public_subnets[0]
  tags          = local.common_tags
}
All resources referencing local.common_tags will receive the same tag set; updating the tags in one place affects every resource.
The image outlines the benefits of using locals in HashiCorp Terraform, highlighting centralized logic, clearer code, and less risk.

​
When to use locals

Locals are particularly useful for:
  • Computed or derived values — combine variables, data sources, or inputs into a consistent format (naming conventions, tag values).
  • Reusing constants — store project prefixes, environment names, or common tag maps so you only update one place.
  • Complex expressions — move long or nested Terraform functions into named locals to keep resource blocks readable.
Use the following table to decide where locals can provide the most value:
Use caseWhy use localsExample
Naming conventionsEnsures consistent names across resourceslocal.prefix = "acme"
Tag standardizationApply consistent tags to many resourceslocal.common_tags = { Owner = var.owner }
Derived valuesCombine multiple inputs into one expressionlocal.service = "${var.team}-${var.app}-${var.environment}"
Complex expressionsShorten resource blocks and improve readabilitylocal.subnet_ids = compact(var.subnets)
Use locals to centralize logic and keep resources focused on resource-specific configuration. Avoid placing heavy computation directly inside resource arguments; compute it once in a local and reference it.

​
Practical considerations and best practices

  • Locals can reference variables, data sources, and other locals — but do not create circular references.
  • Locals are evaluated during plan/apply and are not stored in state.
  • Give locals descriptive names and group related locals together to make them discoverable.
  • Prefer maps or objects (e.g., a common_tags map) for shared sets of attributes rather than repeating keys across resources.
  • Use locals to hide complexity, but don’t overuse them to obscure obvious values.
The image is a presentation slide explaining when to use local values in code, highlighting their role in maintaining readability and consistency, and features a photo of a laptop on a purple background.

​
Summary

Locals reduce repetition, centralize logic, and make complex expressions easier to manage. They serve as a single source of truth for commonly repeated values—change once, and every reference updates. Hands-on exercise: refactor a small module by extracting duplicated names, tag maps, and repeated computed expressions into locals, then run terraform plan to verify the consolidated changes.

Watch Video

Practice Lab