What are the pros/cons of using Terragrunt versus Terraform Workspaces when instantiating modules?
What are the pros/cons of using Terragrunt versus Terraform Workspaces when instantiating modules?
# Updated answer (Aug, 2022) I took the original answer below and flushed out the details in a blog post series called [How to manage multiple environments with Terraform](https://blog.gruntwork.io/how-to-manage-multiple-environments-with-terraform-32c7bc5d692) to answer this question. This series walks through how to use [workspaces](https://blog.gruntwork.io/how-to-manage-multiple-environments-with-terraform-using-workspaces-98680d89a03e), [branches](https://blog.gruntwork.io/how-to-manage-multiple-environments-with-terraform-using-branches-875d1a2ee647), and [Terragrunt](https://blog.gruntwork.io/how-to-manage-multiple-environments-with-terraform-using-terragrunt-2c3e32fc60a8) to set up multiple environments, switch between environments, use different configurations, backends, and versions in each environment, and how to work with multiple modules. At the end of each post, you’ll see a list of the advantages and drawbacks of using that option. And for those of you looking for the short version, there's a handy comparison table in that series to help you pick:  # Original answer (Dec, 2021) There are a bunch of trade-offs. The short version is that workspaces are native to Terraform, so they are available out of the box and easy to use, but Terragrunt handles the separation you need between environments (minimizing "blast radius") better. Here is the more in-depth version: ## Advantages of workspaces vs Terragrunt 1. Workspaces are natively built into Terraform, so you don't need to learn/use/maintain/etc an external tool like Terragrunt. 2. Workspaces are natively used by Terraform Cloud (TFC) and Enterprise (TFE). Terragrunt is not natively supported by TFC or TFE (though there are some workarounds to use them together). 3. Workspaces are natively supported in the Terraform code itself: you can get the name of the workspace using `terraform.workspace` and have the code behave differently based on that name (e.g., `instance_type == terraform.workspace === "dev" ? "t2.micro" : "m4.large"`). 4. Workspaces allow you to keep one copy of your code, but to have the state of the infrastructure captured in separate state files. This reduces code duplication. With Terragrunt, you do need to create extra files/folders to define each environment, so you do end up with a bit more duplication. Note that this is _intentional_, as the idea behind Terragrunt is to make those environments _visible_ in your repo (you'll see more about that in the next section), but it does mean having more files/folders to manage. ## Drawbacks of workspaces vs Terragrunt 1. The most common way people try to use workspaces is to define separate environments: e.g., dev, stage, prod. It turns out that even [HashiCorp itself does NOT recommend this](https://www.terraform.io/language/state/workspaces#when-to-use-multiple-workspaces). Workspaces don't have good enough support for the separation of configuration and backends that you need between different environments: > In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario. Terragrunt is specifically designed to help you define and manage multiple environments in a DRY manner, as [explained here](https://terragrunt.gruntwork.io/docs/features/keep-your-terraform-code-dry/#remote-terraform-configurations), and this is an effective way to keep configurations separate across environments and using separate backends (as [explained here](https://terragrunt.gruntwork.io/docs/features/keep-your-remote-state-configuration-dry/)). 2. Terragrunt is natively built to not only support multiple environments, but to use different _versions_ of your Terraform modules in each environment by setting different `source` URLs: e.g., you might use `v0.1.0` of your `vpc` module in the prod environment and `v0.2.0` in the stage environment. This is very useful for immutable infrastructure practices, where you roll out a new version of an immutable artifact from one environment to the next, always knowing exactly what's deployed where, and having the ability to roll back to older versions. With workspaces, there's no native support for this (the `source` URL in Terraform modules doesn't allow any variables or interpolation). 3. To create or switch to a workspace, you run a command: e.g., `terraform workspace new` or `terraform workplace select`. That means the list of workspaces that exist is not visible in the code or on disk. So just by browsing the repo, you can't tell what workspaces or environments actually exist; you'd have to look at state files or run `terraform workspace list` to figure that out. Moreover, workspaces are often created for testing or temporary work (especially in TFC/TFE), so it's very hard to get a picture of what you _intended_ to deploy. With Terragrunt, the idiomatic way to define environments is to define them in files/folders on disk, so just by browsing a repo, you have a really good idea of what's deployed and the intention behind it (e.g., see the example `live` repo layout [here](https://terragrunt.gruntwork.io/docs/features/keep-your-terraform-code-dry/#remote-terraform-configurations)). 4. To create or switch to a workspace, you run a command, which is quite error prone. It's a little too easy to think you're in the dev environment, make some changes, run `destroy`, and only then realize you were actually in prod all along, all because you accidentally forgot to run `terraform workspace select`. With Terragrunt, since environments are defined in files/folders on disk, it's a lot easier to tell that you're in the `dev` or `prod` folder, which minimizes that sort of mistake.