Multiple Environments Without Falling into Traps

The question always arrives at the same moment: the configuration works, it's applied somewhere, and now you need the same thing elsewhere. Staging, production, a second region, a demo environment for a customer. The solution that comes to mind is the one that costs the most in the long run: a terraform workspace new production, because it's a single command and the word "workspace" suggests exactly the usage you have in mind.

It's a trap, and a particularly well-laid one. Workspaces share the same code, the same provider version, the same backend, and above all they are invisible in the repository: nothing in the files tells you which environment you're working on. The only safeguard against a production apply launched from a machine that thought it was on staging is your memory of a command typed ten minutes earlier. This lesson compares the three real approaches, explains what breaks in each, and gives a default recommendation.

Approach 1: Separate Directories

Each environment is a directory with its own backend, its own variables, and its own state.