HashiCorp didn’t ship a flashy AI feature in Terraform 1.15 — instead, the team finally addressed three of the most-requested papercuts that have annoyed module authors for years: variables in module sources, a real deprecation workflow, and inline type conversions. For platform teams maintaining internal module registries, this is the most consequential point release in a long time.
The headline features sound mundane on paper, but anyone who has tried to refactor a sprawling module repo or migrate a Terraform Cloud workspace knows exactly why these matter. Here’s what changed and which teams should care.
Why Dynamic Module Sources Change the Refactoring Game
Terraform 1.15 introduces a new const attribute on variables, a boolean flag that signals the variable can be evaluated during terraform init. Once marked, that variable can be interpolated into a module’s source or version field — something practitioners have been requesting on GitHub for the better part of a decade.
Until now, every module call had to hardcode its source path or version, which made A/B testing module versions, parameterizing internal vs. public registry paths, or running parallel module variants in CI a copy-paste nightmare. With const = true, a variable becomes init-time constant, the configuration stays DRY, and Terraform will throw an error during init if you accidentally reference a non-const local. It also explicitly cannot be combined with sensitive or ephemeral, which keeps the security boundary clean.
If you run an internal module registry across dev, staging, and prod tenants, you can now drive the source path from a single var.folder rather than maintaining three near-identical root modules. For teams building multi-tenant SaaS platforms where each customer environment may need a slightly different module variant, this collapses an entire category of glue code.
My take: expect a wave of community modules to be rewritten in the next six months to expose const variables for region, partition, and provider-flavor switching. The ones that don’t will start to feel obsolete fast.
A Real Deprecation Workflow Arrives for Module Authors
The new deprecated attribute on variable and output blocks is one line of syntax with outsized operational reach. Module authors can now mark fields as deprecated with a custom message, and Terraform will emit a warning diagnostic during validation whenever a caller passes a value to that variable, references the deprecated output, or — for root-level variables — sets it via CLI, env var, or Terraform Cloud workspace UI.
Why it matters: until now, the only way module maintainers could signal “stop using this” was a README note and a prayer. Major version bumps were the de facto deprecation tool, which meant every breaking change forced a coordinated migration across every consumer. With per-field deprecated warnings surfacing in normal terraform validate and terraform plan output, maintainers can stage rollouts properly: announce in v1.4, warn in v1.5, remove in v2.0.
One deliberate design choice: deprecated outputs can themselves reference other deprecated values without tripping warnings inside child modules — but the same reference at the root module level becomes an error. That asymmetry lets module authors carry deprecated wiring forward during transitions without leaking warnings to end users who haven’t opted in.
If you maintain a shared module library across a 50-engineer org, you can finally deprecate a variable on Monday and have a measurable signal by Friday for which teams still pass it. Combined with policy-as-code tools like Sentinel or OPA, you can promote those warnings to hard gates once adoption is high enough.
My prediction: within a year, the Terraform Registry’s quality scoring will weight modules that use deprecated correctly, the same way npm and PyPI ecosystems quietly reward maintainers who respect semver.
The convert Function Finally Fixes Empty Collections
The new convert function tackles one of the most frustrating ergonomic issues in HCL: there’s no literal syntax for an empty typed collection. Writing {} gives you an empty object, not an empty map. Writing [] gives you an empty tuple, not an empty list of strings. That distinction has burned anyone who’s tried to default a complex variable to “none” and watched Terraform refuse to merge it with non-empty values later.
convert lets you write inline, explicit type coercions — convert([], list(string)) produces a real empty list of strings — which kills off an entire genre of length(x) > 0 ? x : tolist(["placeholder"]) workarounds. It also makes conditional expressions more predictable, since the two branches of a ternary can now agree on type without fighting Terraform’s inference engine.
Take a module that accepts an optional list of IAM policy ARNs. Today, you either default to a non-empty placeholder and filter it out later, or you wrap every consumer in a try(). With convert, the default becomes a clean, typed empty list, and downstream for_each blocks behave sanely.
My take: the convert function won’t make headlines, but it’ll be the single most-pasted function in the next year of community modules.
The Quiet Wins: Windows ARM64, AWS Login, Output Types
The rest of the release reads like a backlog grooming sprint, and that’s a compliment. Native Windows ARM64 binaries unlock Terraform on Surface Pro, the Windows Dev Kit 2023, and Windows VMs on Apple Silicon via Parallels — relevant for Windows-shop platform teams now standardizing on ARM. The S3 backend gains native support for AWS CLI v2.32.0+‘s aws login, which means developers can finally use Management Console credentials for programmatic access and ditch long-lived access keys.
Output blocks now accept explicit type constraints, bringing them to parity with input variables — a small thing that improves both validation and auto-generated documentation. The Terraform Test framework now allows functions like uuid() and format() inside mock_data and override_resource blocks, which makes testing modules against Azure Resource IDs or AWS ARNs actually feasible without ugly string constants. And Stacks variables gain validation blocks with condition and error_message, pushing input validation upstream of provider calls.
For teams running AI agent infrastructure on Terraform-managed cloud accounts, the AWS login support alone is worth the upgrade — short-lived credentials are table stakes for any serious agent platform that needs to provision resources without baking long-term keys into a vault.
FAQ
Q: What is the const attribute in Terraform 1.15?
A: const = true is a new boolean attribute on variable blocks that marks a variable as evaluable during terraform init. Once marked, the variable can be used inside module source and version fields. It’s mutually exclusive with sensitive and ephemeral.
Q: How does the deprecated attribute work for module authors?
A: Adding deprecated = "message" to a variable or output block causes Terraform to emit a warning diagnostic during validation whenever that field is referenced or assigned. It works for root variables passed via CLI/env/TFC, module call inputs, and references to deprecated outputs or resources.
Q: Do I need to upgrade to Terraform 1.15 right now? A: If you maintain shared modules or run mixed dev/staging/prod tenants from the same root configuration, yes — the dynamic module sources and deprecation workflow alone justify the upgrade. Pure consumer teams running a stable stack can wait, but new module versions will start assuming 1.15+ within the next few releases.
Key Takeaways
- Module authors should plan a deprecation pass on their next minor release and start using the
deprecatedattribute instead of waiting for major version bumps. - Platform teams running internal module registries can collapse environment-specific root modules by adopting
constvariables for source paths. - Replace
tolist([])and similar workarounds with the newconvertfunction in any new module code — reviewers will start flagging the old patterns. - AWS shops should pilot the
aws loginflow in non-prod backends now to retire long-lived access keys before auditors ask. - Expect the Terraform Registry ecosystem to start scoring modules on deprecation hygiene within the next year, the same way package registries reward semver discipline.