Using Terraform Workspace Prefixes in a Remote Backend

Terraform workspaces are a great feature that helps developers organize their Terraform deployments and ensure isolation between workspaces. In this blog, we’ll talk briefly about what workspaces are as well as how to use the Terraform workspace prefix feature to manage multiple workspaces from a single Terraform configuration.

Workspace Introduction

Workspaces enable you to create separate instances of your infrastructure for different environments (e.g., development, staging, production) or for experimentation. Each workspace maintains its own Terraform state file, allowing you to keep the state of different environments separate. Lastly, all workspaces use the same Terraform configuration files, promoting consistency across environments.

Workspaces can be used with open-source Terraform in local operations or in a remote backend such as Scalr or Terraform Cloud. The concept between the two is similar in that it isolates Terraform state files, but workspaces in a remote operations backend are more advanced as the actual execution of runs happens within Scalr, which then enables more features such as integrations, remote state sharing, RBAC, and more.

Workspace Usage

The terraform workspace command can be used to interact with a workspace locally or in a remote backend. When working with Terraform, a default workspace is automatically created, which cannot be deleted. To create more workspaces, you have the following command line options:

terraform workspace
Usage: terraform [global options] workspace

  new, list, show, select and delete Terraform workspaces.

Subcommands:
    delete    Delete a workspace
    list      List Workspaces
    new       Create a new workspace
    select    Select a workspace
    show      Show the name of the current workspace

Workspace Prefix in a Remote Backend

The workspace prefix option allows you to set the common name across the workspaces so all you have to do is change the appended value. For example, you might have an application, let’s call it “application-a”, which has a dev, stage, and prod workspace associated with it. The actual core Terraform configuration files will remain the same, but some variable values might be different. In this example, we would have the following code set in our Terraform remote backend configuration file:

terraform {
 backend "remote" {
   hostname = "<account-name>.scalr.io"
   organization = "<environment-id>"

   workspaces {
     prefix = "application-a-"
   }
 }
}

After setting the remote backend, a new workspace can be created with the following command:

terraform workspace new prod

Upon running terraform init, a new workspace will be seen in Scalr:

All standard Terraform commands can be executed on this workspace, but it is highly advised to run terraform workspace show  or terraform workspace list to always know which workspace you are operating in, especially if one is for a production environment:

terraform workspace show
prod

terraform workspace list 
* prod

That’s all it takes to start using the Terraform workspace prefix option in a remote backend such as Scalr or Terraform Cloud.

Summary

Whether using a remote or local workspace, Terraform workspaces are a best practice when creating Terraform configuration files as they allow you to isolate the Terraform state file while using the same Terraform code. When using a Terraform remote backend, the prefix option in the backend block will give you more flexibility to quickly switch between the Scalr or Terraform Cloud workspaces when developing your code.