Every real application needs multiple environments: one for development to test, another for staging (pre-production) to validate, and production where the real users are. In this chapter, we’ll see how to manage those environments with Terraform. We’ll start with a tool that Terraform itself provides: workspaces. But beware, we’ll also see why they have important limitations.

You should never test changes directly in production: it would be like experimenting with real customers watching. That’s why environments are separated:

Each environment usually has the same infrastructure structure (a VPC, some servers, a database...), but with differences: production is bigger and more robust, development is smaller and cheaper. The challenge is: how do I manage the same code for multiple environments without duplicating everything?

Remember Terraform’s state (Chapter 11): the file that records which resources exist. A workspace is, essentially, a separate state within the same code. By switching workspaces, Terraform uses a different state, allowing you to have multiple copies of the same infrastructure without mixing them.

The basic commands:

Within the code, you can know which workspace you’re in with terraform.workspace, and adapt values accordingly:

Analogy: workspaces are like having multiple saved games of the same video game. The game (the code) is the same, but each save (workspace) has its own independent progress (state). You switch saves and work on a different reality without affecting the others.

Workspaces seem like the perfect solution, but they have serious problems you should know about before adopting them to manage environments. In fact, the community does not recommend using workspaces to separate dev/stg/prod. Let’s see why.

All workspaces share the same code and the same backend (the same state bucket). This means the separation between production and development is fragile: a mistake can affect multiple environments, and there’s no strong barrier between them.

Since you switch environments with a simple workspace select, it’s easy to forget which one you’re in and apply a change in the wrong place. Imagine running an apply thinking you’re in dev when you’re actually in prod. ⚠️ This mistake has caused real incidents.

If your environments are very different (not just in size, but in structure: production has components that development doesn’t), forcing everything into the same code with conditionals (terraform.workspace == ...) becomes convoluted and hard to read.

It’s not obvious, looking at the code, what’s in each environment. Everything is mixed and depends on which workspace you’re in, making it hard to understand and audit the infrastructure.

Workspaces have their place in simple cases:

• When environments are almost identical and only minor details change (a size, a name).
• To create temporary test copies (for example, one environment per development branch, which you create and destroy quickly).
• In small projects where strong separation is not critical.

To manage serious environments (dev/stg/prod in a company), the general recommendation is not to use workspaces, but rather a strategy of directories separated by environment, which we’ll see in the next subchapter (19.2). That strategy gives a much clearer, safer, and more visible separation.

Key Conclusion: workspaces exist and are useful for simple cases, but they are not the best tool to separate production from development in real projects. Know them, but be aware of their limits.

• Every real application needs multiple environments (dev, staging, production) to never experiment directly on real users.
• A Terraform workspace is a separate state within the same code, allowing multiple copies of the infrastructure (like “saved games” of the same game). Managed with terraform workspace new/select/list.
• Important limitations: they share code and backend (weak separation), it’s easy to use the wrong environment (dangerous), things get complicated if environments are very different, and they offer poor visibility.
• Use them for simple cases (almost identical environments, temporary copies), but not as the main way to separate dev/stg/prod in serious projects.
• The recommended alternative for serious environments is directory separation, which we’ll see next.

In the next subchapter, we’ll see that recommended strategy: organizing your infrastructure in directories per environment.