Terraform 1.15: Dynamic Module Sources Are Here

Terraform 1.15 shipped April 29 with dynamic module sources — the ability to use variables in module.source and module.version attributes. InfoQ notes that OpenTofu users have had this for nearly two years. HashiCorp’s release post calls it a “long-standing community request.” That framing is accurate, if understated.

The const Variable: How Dynamic Sources Work

The feature introduces a new const attribute on variable declarations. Setting const = true signals to Terraform that the variable is resolvable at terraform init time — before full configuration evaluation kicks in. That matters because module source paths must be known before Terraform can fetch the module.

A practical example: a platform team managing staging and production environments pointing at different module registries. Before 1.15, you duplicated the entire module block and hardcoded the source. Now:

variable "module_registry" {
  type    = string
  default = "terraform-aws-modules/vpc/aws"
  const   = true
}

variable "module_version" {
  type    = string
  default = "6.6.0"
  const   = true
}

module "vpc" {
  source  = var.module_registry
  version = var.module_version
}

One constraint worth knowing: const cannot be combined with sensitive or ephemeral. The attributes are mutually exclusive. If you’re nesting modules, every module in the chain that references a dynamic source needs its own input variables marked const = true.

Variable Deprecation: Module Maintainers Get a Clean Exit

The other genuinely useful addition is the deprecated attribute on variable and output blocks. Module maintainers have long relied on README notes to signal that a variable is going away. Now Terraform does it for you — a warning diagnostic fires during terraform validate whenever a caller references a deprecated variable or output.

variable "old_instance_type" {
  type       = string
  deprecated = "Use 'instance_class' instead. This variable will be removed in v3.0."
}

Small feature, but it closes a gap that caused friction every time a module needed to evolve its interface.

What Else Shipped in 1.15

• Output type constraints: Outputs now accept a type attribute. terraform validate enforces it, catching mismatches before apply.
• convert() function: Inline type conversion without relying on implicit coercion. Cleaner HCL, fewer surprises in complex configurations.
• Backend validation: terraform validate now checks the backend block — catches missing required attributes before your CI pipeline hits terraform init.
• Windows ARM64: Native binaries for Surface Pro and Windows Dev Kit 2023.

Where OpenTofu Still Leads

Dynamic module sources, variable deprecation, output type constraints — OpenTofu shipped versions of these features across its 1.7 through 1.11 releases. Terraform 1.15 closes a meaningful slice of that gap, but not all of it. OpenTofu still leads on native state encryption, provider for_each (instantiate a provider across multiple regions without duplication), OCI registry support, and built-in ephemeral resources.

Terraform counters with HCP Terraform integration, Terraform Stacks for managing multi-component infrastructure, and commercial support. They are increasingly distinct products. The question for teams evaluating both is whether your requirements map to Terraform’s HCP roadmap or OpenTofu’s OSS feature velocity.

Should You Upgrade?

Yes. Terraform 1.15 honors the v1.0 compatibility promise — no breaking changes. If you are already on Terraform, upgrade and start using const variables for module sources where it simplifies your configuration. If you are actively evaluating OpenTofu, this release narrows the gap but does not close it: OpenTofu still has material advantages for teams that need state encryption or multi-region provider management without HCP. The full release notes are on the HashiCorp developer blog.