Answers: <p>As the docs state, <a href="https://www.terraform.io/docs/language/state/workspaces.html#when-to-use-multiple-workspaces" rel="nofollow noreferrer">workspaces are for <em>distinct</em> resources</a>:</p>
  <blockquote>
  <p>Named workspaces allow conveniently switching between multiple instances of a single configuration within its single backend. They are convenient in a number of situations, but cannot solve all problems.</p>
  </blockquote>
  <blockquote>
  <p>A common use for multiple workspaces is to create a parallel, distinct copy of a set of infrastructure in order to test a set of changes before modifying the main production infrastructure. For example, a developer working on a complex set of infrastructure changes might create a new temporary workspace in order to freely experiment with changes without affecting the default workspace.</p>
  </blockquote>
  <p>If you would like all developers to see the same state, they have to use the same
  workspace. If you want this to be the case for <em>arbitrary</em> workspaces, then it seems that this is an abuse of the concept of the workspace. It is possible, but I would strongly advise against it, to import resources from non-default workspaces into the default one, in some kind of automated way. You could also use the default workspace state as the non-default's <a href="https://www.terraform.io/docs/language/state/remote-state-data.html" rel="nofollow noreferrer">remote state</a>, but again, I would strongly advise against this, arguing that it introduces unnecessary complexity and fragility to your process.</p>
  <p>If you want all developers to see the same resources in the state, then they should simply all use the same workspace. If they are not seeing the correct state, it is because the workspace or the remote state location that they are using is different.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-01-23T09:55:13.073Z
Answers: 2021-01-23T09:55:13.073Z
Answers: Bruce Becker
Body: <p>I'm having a bit of trouble with Terraform.  I have a Terraform project which is shared by a few developers and uses non-default workspaces (i.e. named workspaces, not the default one).  I would like all the developers to share access to the Terraform state of this shared workspace the same way as if it was the default workspace.  I have set up remote state with S3, so the state file is singleton, but for some reason I can't get the remote state file to be recognized on each developer's machine.</p>
  <p>Basically the workflow I would like is, when developer A pushes a change to Terraform (using <code>terraform apply</code>) then any other developer who runs <code>terraform state list</code> should see that change reflected in the deployed infra, and that this workflow should work for any workspace, not only the default workspace.</p>
  <p>How do I accomplish this?</p>
  
Tags: <terraform><infrastructure-as-code>
Title: Importing non-default workspaces in Terraform
UserDisplayName: Ertai87
ThreadText: # Importing non-default workspaces in Terraform
  
  (Asked by: username_0 on 2020-01-03)
  
  I'm having a bit of trouble with Terraform. I have a Terraform project which is shared by a few developers and uses non-default workspaces (i.e. named workspaces, not the default one). I would like all the developers to share access to the Terraform state of this shared workspace the same way as if it was the default workspace. I have set up remote state with S3, so the state file is singleton, but for some reason I can't get the remote state file to be recognized on each developer's machine.
  
  Basically the workflow I would like is, when developer A pushes a change to Terraform (using `terraform apply`) then any other developer who runs `terraform state list` should see that change reflected in the deployed infra, and that this workflow should work for any workspace, not only the default workspace.
  
  How do I accomplish this?
  
  **Tags:** terraform, infrastructure-as-code
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-01-23. Score: 1
  
  As the docs state, [workspaces are for *distinct* resources](https://www.terraform.io/docs/language/state/workspaces.html#when-to-use-multiple-workspaces):
  
  > Named workspaces allow conveniently switching between multiple instances of a single configuration within its single backend. They are convenient in a number of situations, but cannot solve all problems.
  
  > A common use for multiple workspaces is to create a parallel, distinct copy of a set of infrastructure in order to test a set of changes before modifying the main production infrastructure. For example, a developer working on a complex set of infrastructure changes might create a new temporary workspace in order to freely experiment with changes without affecting the default workspace.
  
  If you would like all developers to see the same state, they have to use the same
  workspace. If you want this to be the case for *arbitrary* workspaces, then it seems that this is an abuse of the concept of the workspace. It is possible, but I would strongly advise against it, to import resources from non-default workspaces into the default one, in some kind of automated way. You could also use the default workspace state as the non-default's [remote state](https://www.terraform.io/docs/language/state/remote-state-data.html), but again, I would strongly advise against this, arguing that it introduces unnecessary complexity and fragility to your process.
  
  If you want all developers to see the same resources in the state, then they should simply all use the same workspace. If they are not seeing the correct state, it is because the workspace or the remote state location that they are using is different.
  
  
  ---
  
  