Terraform Workspaces Are Not Environments — BigConfig Makes It a Non-Issue

Apr 26, 2026

A thread came across my LinkedIn feed this week. The setup: someone pointed out that Terraform docs themselves say workspaces aren’t meant for environment isolation. The replies were the usual matrix of “well, actually” — separate state files, separate root modules per env, separate provider configs, separate pipelines, the WET-vs-DRY tug of war, the “we migrated 14 workspaces to isolated root modules last year” war stories.

Reading it, I had the same reaction I always have to these threads: the dichotomy itself is the tell.

“Workspaces vs separate root modules.” “WET vs sprawl.” “Shared state vs blast radius.” These aren’t real architectural choices. They’re symptoms of Terraform forcing you to pick your poison at the wrong layer.

Why the debate keeps happening

Terraform fuses two things that should be independent:

The unit of reuse — the module. A module is how you avoid copy-pasting resource definitions.
The unit of deployment — the root module plus its state file. This is what terraform apply actually operates on, and what owns blast radius, IAM, and provider config.

Because these are fused, every “how do I isolate environments?” question becomes a folder-layout question. Do I have one root module with workspaces? One root module per env? A wrapper directory per env that calls a shared module? Each answer trades one form of pain for another:

Workspaces → DRY, but shared backend, shared providers, shared blast radius. The docs themselves warn you off.
One root module per env → strong isolation, but now you’re maintaining N nearly-identical folders. Drift is inevitable. Reviewers can’t tell what actually changed across envs.
Wrapper directories calling a shared module → better, but you’re still hand-rolling the parameterization, the pipeline plumbing, and the promotion story. And count = var.env == "prd" ? 1 : 0 conditionals start showing up.

This is why the same thread gets re-litigated on LinkedIn every few months. There is no right answer inside Terraform’s model.

What BigConfig does differently

In BigConfig, environments are values, not directories.

An environment is a map of inputs passed to a package. The same package — fully reusable, version-pinned, DRY — gets instantiated N times with different inputs. Each instantiation gets its own state, its own provider config, its own IAM boundary, its own pipeline gate. Automatically. By default.

There is no workspace flag. There are no copy-pasted root modules. There are no count = var.env == "prd" ? 1 : 0 conditionals rotting in the corner of a file no one wants to touch.

What that buys you in practice:

DRY without sprawl. One package definition, parameterized. Not 14 root modules to keep in sync.
Strong isolation by default. Separate state and credentials per instance is the default, not a discipline you have to enforce in code review.
Composable. Environments are built from packages the same way packages are built from resources. Promotion = bumping a version, not diffing two folders.
Multi-instance is free. “What about per-tenant, per-region, per-cell?” stops being an architecture decision and becomes a for loop.

The deeper point

The Terraform community keeps having this argument because Terraform’s unit of reuse and its unit of deployment are the same artifact. Every workaround — workspaces, Terragrunt wrappers, generated HCL, monorepos of near-duplicate folders — is an attempt to pry them apart from the outside.

BigConfig pries them apart from the inside. A package describes what you want. An instantiation describes where and with what inputs. State, providers, and IAM follow the instantiation, not the package.

Once you have that separation, “workspaces aren’t environments” stops being a hot take and becomes a non-issue. Same for most of the other recurring DevOps debates — they’re not wrong arguments, they’re just arguments that only exist because the underlying tool conflated two concerns.

To see how your agent can operate a BigConfig package that encapsulates multiple Terraform resources and Ansible playbooks, start at the BigConfig Demo .