terraform Create workspace with local execution mode from CLI

Could you add an optional argument to the ”terraform workspace new” command to set the execution mode of the new workspace to local?

Use case: when creating a new service, we want to copy a project template that includes terraform files and automated ci/cd-scripts. With ☝️ we would be able to simple commit and the automated pipeline would create new workspaces, provision infrastructure and deploy artifacts. At the moment, we need to first create the workspaces manually.

Nov 02 '19 06:11 erikxiv

I personally would like to see this added to the configuration as well; within the definition of the backend like:

terraform {
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "my-organization"

    workspaces {
      prefix = "myapp-"
      mode = "local" | "remote"
    }
  }
}

Nov 03 '19 04:11 skoblenick

I think we should be able to also set the default mode at the org level in the TF Cloud UI.

Nov 03 '19 23:11 tlvenn

+1

Mar 25 '20 22:03 elijah-roberts

I would also really like to see this. Makes automation more difficult.

Oct 14 '20 17:10 mh-bennett

Still waiting for this

Feb 18 '21 16:02 anagarjunr

I'd like to see this as well. When dealing with ephemeral workspaces created on the fly, it kind of kills the mood when I fire up chrome to click a select button.

Mar 03 '21 21:03 bruceharrison1984

Still waiting for this

May 30 '21 23:05 david-peters-aitch2o

Me too

Sep 07 '21 10:09 jacobythwaites

This limitation is a deal breaker for me.

Alternatively, if Agents is available under the Team plan then this would be the preferred option.

Oct 13 '21 03:10 ctorrisi

sh "terraform workspace new ${rootName}" sh 'curl \ --header "Authorization: Bearer $TF_BACKEND_TOKEN" \ --header "Content-Type: application/vnd.api+json" \ --request PATCH --data \'{"data": {"type": "workspaces", "attributes": {"execution-mode": "local"}}}\' \ https://app.terraform.io/api/v2/organizations/my_company/workspaces/test-workspace-${rootName}' sh "terraform workspace select ${rootName}" sh 'terraform apply -auto-approve'

this is one way around it, just define the TF_BACKEND_TOKEN and workspace name, ${rootName} and you should be ok

Oct 13 '21 08:10 david-peters-aitch2o

Just hit this myself. I'm glad there's an issue at least but when will it be fixed? 🙁 Please?

P.S. here's a formatted version of the workaround above.

P.P.S For those interested I changed the var name to TF_WORKSPACE. I found this on my journey to this issue. Setting it will allow you to avoid all use of terraform workspace new / select. Specifically this will allow you to set the name of new auto-created workspaces before running terraform init. This means you can make full use of the tags in the cloud backend to bring up new workspaces in a non-interactive workflow (i.e. your own CI/CD pipeline). This curl should fit in perfectly to this, so thank you very much @david-peters-aitch2o

TF_WORKSPACE="something"
MY_ORGANISATION="else"
TF_BACKEND_TOKEN="1234567890"
TF_URL="https://app.terraform.io/api/v2/organizations/${MY_ORGANISATION}/workspaces/${TF_WORKSPACE}"
terraform workspace new ${TF_WORKSPACE} && \
curl \
    --header "Authorization: Bearer ${TF_BACKEND_TOKEN}" \
    --header "Content-Type: application/vnd.api+json" \
    --request PATCH --data \
    '{"data": {"type": "workspaces", "attributes": {"execution-mode": "local"}}}' \
    ${TF_URL}
# ... later
terraform workspace select ${TF_WORKSPACE}
terraform apply -auto-approve

Apr 05 '22 12:04 Nuxij

@Nuxij interesting but I think this works only with terraform remove backend and not with new terraform cloud backend. The new cloud backend needs a terraform init before any other operation.
You can have that therraform init reply with "no workspace, give me a name to create one" or "workspace not found, we have these other workspace, select one" both error with exit 1
For this reason in cloud is complicated to autocreate workspace in pipeline with tags.
Also in cloud backed TF_WORKSPACE seems not working, if you set this variable and try terraform init it does not take in consideration the variable.
Terraform devs created really a confused and not linear workflow.

Jun 27 '22 23:06 zopar

Please allow for the following it would make it so there's less clicks needed to swap the execution modes.

terraform {
  cloud {
    hostname     = "app.terraform.io"
    organization = "test"
    workspaces {
      name = "test"
      mode = "local" # or; "remote"
    }
  }
}

Nov 27 '22 14:11 onedr0p

+1

Nov 28 '22 12:11 alvherrey

Any news on this? Thank you folks for providing a way to do this at least @Nuxij @david-peters-aitch2o

Apr 12 '23 14:04 sergio-toro

I'm waiting for this great feature as well!

Apr 18 '23 11:04 kaybeudeker

What about TF_FORCE_LOCAL_BACKEND=1? In our case, it solved our problem.

Apr 19 '23 07:04 kochanowski

This does not work as we are using terraform cloud to store the state to run actions on CI. Our use case is preview environments:

Create temporary workspace to store the state on terraform cloud on PR open
Delete the temporary workspace once the PR is closed

We've added the hack of using the API to modify the workspace execution mode, but it's ugly to have that as part of the script...

El mié, 19 abr 2023 a las 9:54, kochanowski @.***>) escribió:

What about TF_FORCE_LOCAL_BACKEND=1? In our case, it solved our problem.

— Reply to this email directly, view it on GitHub https://github.com/hashicorp/terraform/issues/23261#issuecomment-1514296372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFJXDGE5IAOLNQOXEFLWODXB6K4NANCNFSM4JIDHVLQ . You are receiving this because you commented.Message ID: @.***>

-- Sergio Toro Email: @.*** Teléfono: 69 72 86 134

Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

Apr 19 '23 08:04 sergio-toro

Please can a fix for this be implemented. Making terraform unusable in our automation.

Apr 25 '23 12:04 tgbgb

+1

Aug 03 '23 12:08 fernandomullerjr

We also have a need for this option. We use terraform cloud but our agentpool and vault server are within protected networks. Please give us either:

A default execution mode in a TFC org that points to a specific agentpool (i.e. NOT local)
An option under the terraform-cloud-workspaces block (preferred)
A cli flag
An envar

For now we'll have to wrap this in something else that runs terraform init, (RESTful way to add project and mode settings), terraform plan/apply. While this works for established pipelines, it is hard for dev teams to quickly setup TFC-based automation for their stuff. This option will allow full automation between TFC+vault+agentpool for customers that do not put everything out on the Internet.

The project setting has now been fixed (thank you). Please now fix this requirement.

Aug 16 '23 21:08 ghazanhaider

We are expecting the same from our org side as well. If we have an option to manage it temporarily via cli or via environment variable, it would be a great feature.

Nov 27 '24 12:11 milandlg

What about TF_FORCE_LOCAL_BACKEND=1? In our case, it solved our problem.

In a simple learning environment setting this environmental variable also solved the problem settings in app.terraform.io -> Execution mode: Remote config in the code:

terraform {
  cloud {
    organization = "org"
    hostname     = "app.terraform.io"

    workspaces {
      name = "workspace"
    }
  }
}

Result: remote state is being saved in app.terraform.io but terraform runs locally (my machine or github actions runner)

Feb 03 '25 19:02 kzwolenik95