instruction: How do you manage multiple environments with Terraform?
output: State: Workspaces | Terraform | HashiCorp Developer HashiConf The full conference agenda&#x27;s now LIVE. Buy your pass and plan your schedule. Register Dismiss alert HashiCorp Cloud Platform Get started in minutes with our cloud products All HCP Products Infrastructure Lifecycle Management Terraform Manage infrastructure as code Packer Build machine images Nomad Orchestrate workloads Waypoint Standardize application patterns Vagrant Build developer environments Security Lifecycle Management Vault Centrally manage secrets Boundary Secure remote access HCP Vault Radar Scan for embedded secrets Consul Secure network services Learn Certifications Get HashiCorp certified Tutorials Learn HashiCorp products Validated Patterns Field-tested patterns for using HashiCorp products Well-Architected Framework Adopt HashiCorp best practices Terraform Install Tutorials Documentation Documentation Intro to Terraform Configuration Language Terraform CLI HCP Terraform Terraform Enterprise Terraform Migrate CDK for Terraform Provider Use Plugin Development Registry Publishing Integration Program Registry (opens in new tab) Try Cloud (opens in new tab) Search Command or control key K key Sign in Sign up Theme Terraform Home Configuration Language Configuration Language Style Guide Stacks BETA BETA Files and Directories Syntax Resources Data Sources Ephemeral block Providers Variables and Outputs Modules Moved block Terraform block Backend block Checks Import Expressions Functions State Overview Purpose The terraform_remote_state Data Source Backends: State Storage and Locking Import Existing Resources Refactor state Locking Workspaces Remote State Sensitive Data Tests Upgrading to Terraform v1.12 v1.x Compatibility Promises Terraform Internals Resources Tutorial Library Certifications Community Forum (opens in new tab) Support (opens in new tab) GitHub (opens in new tab) Terraform Registry (opens in new tab) Developer Terraform Configuration Language State Workspaces v1.12.x (latest) Terraform v1.13.x (rc) v1.11.x v1.10.x v1.9.x v1.8.x v1.7.x v1.6.x v1.5.x v1.4.x v1.3.x v1.2.x v1.1.x Workspaces Each Terraform configuration has an associated backend that defines how Terraform executes operations and where Terraform stores persistent data, like state . The persistent data stored in the backend belongs to a workspace. The backend initially has only one workspace containing one Terraform state associated with that configuration. Some backends support multiple named workspaces, allowing multiple states to be associated with a single configuration. The configuration still has only one backend, but you can deploy multiple distinct instances of that configuration without configuring a new backend or changing authentication credentials. Note : The Terraform CLI workspaces are different from workspaces in HCP Terraform . Refer to Connect to HCP Terraform for details about migrating a configuration with multiple workspaces to HCP Terraform. Backends Supporting Multiple Workspaces You can use multiple workspaces with the following backends: AzureRM Consul COS GCS Kubernetes Local OSS Postgres Remote S3 Using Workspaces Important: Workspaces are not appropriate for system decomposition or deployments requiring separate credentials and access controls. Refer to Use Cases in the Terraform CLI documentation for details and recommended alternatives. Terraform starts with a single, default workspace named default that you cannot delete. If you have not created a new workspace, you are using the default workspace in your Terraform working directory. When you run terraform plan in a new workspace, Terraform does not access existing resources in other workspaces. These resources still physically exist, but you must switch workspaces to manage them. Refer to the Terraform CLI workspaces documentation for full details about how to create and use workspaces. Current Workspace Interpolation Within your Terraform configuration, you may include the name of the current workspace using the ${terraform.workspace} interpolation sequence. This can be used anywhere interpolations are allowed. Referencing the current workspace is useful for changing behavior based on the workspace. For example, for non-default workspaces, it may be useful to spin up smaller cluster sizes. For example: resource &quot;aws_instance&quot; &quot;example&quot; { count = terraform.workspace == &quot;default&quot; ? 5 : 1 # ... other arguments } Another popular use case is using the workspace name as part of naming or tagging behavior: resource &quot;aws_instance&quot; &quot;example&quot; { tags = { Name = &quot;web - ${ terraform . workspace } &quot; } # ... other arguments } Edit this page on GitHub On this page: Workspaces Backends Supporting Multiple Workspaces Using Workspaces Current Workspace Interpolation Theme Certifications System Status Cookie Manager Terms of Use Security Privacy Trademark Policy Trade Controls Accessibility Give Feedback (opens in new tab)