feat: Add deployment-level option to disable Terraform module caching #22834

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Since v2.30 (#21398), Terraform modules are cached at template import time and reused for all subsequent workspace builds. This means that semver version constraints like ~> 1.1.0 are resolved once at import time and then effectively pinned — the constraint is never re-evaluated on workspace builds, even when newer matching versions are available upstream.

This silently overrides Terraform's native version resolution semantics. If a user specifies version = "~> 1.1.0", the intent is "give me the latest patch within this range." The caching behavior changes this to "pin whatever version was latest at import time," which is fundamentally different from what the user declared in their configuration.

Additional context: disable_module_cache toggle not available in v2.30.x

A per-template toggle (disable_module_cache) was added in #21931, which merged to main on Feb 5, 2026. However, this was never cherry-picked to the release/2.30 branch. This means:

• v2.30 introduced module caching as a breaking change (chore!: send modules archive over the proto messages #21398)
• The opt-out toggle (chore: add template toggle to disable module caching #21931) only exists in v2.31+
• Users on v2.30.x have no way to disable module caching — not via UI, API, or CLI
• The breaking behavior change is unmitigable on the v2.30.x release line

Additionally, even in v2.31+ where the per-template toggle exists:

• There is no deployment-level or server-wide flag to disable module caching — administrators with many templates (e.g. ~100) must update each template individually
• The coder/coderd Terraform provider (coderd_template resource) does not expose the disable_module_cache attribute, so templates managed via Terraform cannot use this setting

Background: why caching was introduced

The caching behavior was introduced to solve real problems:

• Disk/memory pressure: Repeated module downloads on every workspace build could cause ever-growing .terraform/modules cache on provisioner nodes, leading to OOM or exit code 1 on coderd instances at scale
• Stability: Upstream module changes could break workspace restarts without any template changes
• Performance: Eliminating repeated downloads speeds up workspace startup

These are valid concerns. However, the current implementation is all-or-nothing with no way to manage it at the deployment level, and it overrides Terraform's native version resolution without the user's consent.

Expected Behavior

1. Terraform semver constraints should be respected as written — if a user specifies ~> 1.1.0, they expect the latest matching version to be fetched on each workspace build, not a cached/pinned version from import time. If explicit pinning is desired, the user would specify an exact version (e.g. version = "1.1.3").
2. Deployment-level configuration option — A global flag (e.g. CODER_DISABLE_TERRAFORM_MODULE_CACHE) to disable module caching across all templates, rather than requiring per-template updates. Per-template settings could still override the deployment default.
3. UI messaging when globally disabled — When caching is disabled at the deployment level, the template settings UI should indicate this clearly, e.g.: "Terraform module caching is disabled at the deployment level. Modules will be re-downloaded on each workspace build. Note: disabling caching means provisioner nodes may accumulate Terraform module files on disk, which can impact stability at scale."
4. Backport — The disable_module_cache toggle should be backported to v2.30.x so that users on that release line have a way to opt out.
5. Terraform provider support — The coder/coderd Terraform provider should expose the disable_module_cache attribute on the coderd_template resource.

Steps to Reproduce

1. Create a template that references a module with a semver constraint:

   module "base_template" {
     version = "~> 1.1.0"
     # ...
   }

2. Push the template version (module resolves to e.g. 1.1.3)

3. A new version 1.1.4 is released upstream

4. Start a workspace — it still uses 1.1.3 from cache, ignoring the available 1.1.4

Environment

• Coder version: v2.30.3+55da992 (confirmed: disable_module_cache toggle is absent)

Created on behalf of @maxbeutel