One Kingdom, Two Needs
The kingdom had one set of blueprints: the official design of the entire infrastructure. But the kingdom had two needs: a real running infrastructure that served citizens, and a testing ground where builders could try changes without risk. For months, Pariksha the tester had been making changes directly in the real kingdom, then rolling back when something broke. Three times she had accidentally disrupted the water supply to the eastern quarter while testing a new well design. The citizens did not appreciate experimental wells. Pariksha needed her own kingdom — an identical copy she could experiment in freely, knowing any disaster there would not reach the citizens.
“Testing in production is not testing. It is gambling with other people's stability.”
The Second World
Loka the world-maker showed Pariksha a command: create a new workspace called "testing." In the testing workspace, the same blueprints produced a parallel kingdom — same design, different name, different state. Changes in the testing workspace did not touch the production workspace. Pariksha ran terraform workspace new testing and terraform apply. A second kingdom appeared: testing-eastern-well, testing-water-supply, testing-granary. The real kingdom still had eastern-well, water-supply, granary. Two separate state files, two sets of resources, one set of blueprints. Pariksha could now experiment freely.
“A workspace is a namespace for state. Same blueprints, different state, different resources.”
The Workspace-Aware Blueprint
The blueprints needed to produce different-sized kingdoms for different purposes. The testing kingdom needed one well; the production kingdom needed ten. Loka showed Pariksha how blueprints could ask: "Which workspace am I in?" If the blueprint was in the testing workspace, it used a small configuration. If it was in the production workspace, it used a large one. Loka wrote: locals { well_count = terraform.workspace == "production" ? 10 : 1 }. The same blueprint, running in two workspaces, produced two appropriately-sized kingdoms. One blueprint governed both. The difference was in the workspace's configuration, not in two separate blueprints.
“Workspace-aware blueprints enforce consistency of design while allowing variation of scale.”
When Workspaces Are Not Enough
The kingdom grew. The testing world was satisfying, but a new problem emerged: the kingdom had three real environments — development, staging, and production — each needing different access controls, different billing accounts, different teams, and different change approval processes. Viveka the judge examined the situation: "Workspaces share the same backend, the same state file location, the same provider credentials. They are namespaces within a single configuration. Your three environments need true isolation: separate backends, separate credentials, separate blast radii. A workspace experiment that corrupts the backend corrupts all three environments." The guild moved the three environments to three separate directories, each with its own backend configuration.
“Workspaces provide namespace isolation. True environment isolation requires separate backends.”
The Ephemeral World
Pariksha discovered a new use for workspaces: temporary environments for pull request testing. Each pull request created a new workspace named after the request. The CI system ran terraform workspace new pr-${requestNumber}, then terraform apply. The testing kingdom existed for the life of the pull request. Reviewers could test against a real environment, not a mock. When the pull request was merged or closed, the CI system ran terraform destroy and terraform workspace delete. The ephemeral world appeared for a test, proved its worth, and vanished. No permanent cost, no cleanup debt, no lingering environments from forgotten pull requests.
“An ephemeral world created for a purpose and destroyed when the purpose is served is the ideal testing environment.”
The Right World for the Right Work
Viveka the judge summarized the lesson for new builders: Use workspaces when you need the same infrastructure at different scales with the same configuration, credentials, and blast radius — feature flags, ephemeral PR environments, developer sandbox variants. Use separate directories with separate backends when you need true environmental isolation, separate access controls, separate billing, or protection against one environment's state corruption affecting another. "The question," Viveka said, "is not which is better. The question is what kind of isolation do you need?" Workspaces are a tool. Directory-per-environment is a tool. Each is correct in its context.
“Choose isolation level to match the consequence of failure. Not every environment deserves the same boundary.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Terraform workspaces create separate state files for the same configuration — run terraform workspace new [name] to create one, terraform workspace select [name] to switch. All workspaces share the same backend configuration and provider credentials. Use terraform.workspace in expressions to vary resource counts, sizes, or names by workspace. Workspaces suit: ephemeral PR environments, developer sandboxes, same-configuration multiple-scale deployments. They do NOT suit: full environment isolation (prod/staging/dev with separate credentials or billing) — use directory-per-environment with separate backends for that. Terraform Cloud workspaces add team-based access control and remote execution, making them more suitable for organization-level environment separation.