October 5, 2023

Use local execution mode for free with Scalr

Ryan Fee

There are two types of execution modes in Scalr, remote and local. The remote execution mode means the Terraform or OpenTofu (OTF) run will execute in a container that is running on the Scalr infrastructure or a self-hosted agent. When using the remote mode, you gain all of the benefits of Scalr. Local execution mode means that the run will execute local to where the Terraform or OTF commands have been executed, but the state is still stored in Scalr. Users are not charged for local runs in Scalr.

Use Cases for Local Execution

We typically see the execution mode being updated to local during early development cycles. During this time, there is more trial and error when developing the Terraform or OTF code and some of the integrations that Scalr provides may not be as critical. Once the development is finished and the code is ready for production, we usually see the execution mode switched back to remote to gain the full benefits of using a remote backend.

The other common use case we see for this is when an organization just needs a little more structure and wants to have a central place for storing state. You might already have a pipeline outside of Scalr and want to have the ability to organize workspaces, restrict who can access state through RBAC, and have centralized state storage. All of this, plus a private module registry is possible when using local execution.

Add the Remote Backend

To take advantage of Scalr for state storage, you will need to to set the remote backend in your code:

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

    workspaces { 
      name = "<your-workspace-name>" 
You will also need to ensure you have Scalr credentials local to where the run is being executed. These can be set by running terraform login <your-scalr-account>.scalr.io

Ways to Set a Workspace to Local Execution Mode

The workspace attribute execution-mode can be updated in Scalr through the Scalr CLI, provider, or API. The ability to update it through the UI is coming soon.

Scalr CLI

The Scalr CLI can be used for quick operational changes that don’t require coding around the API or using the Scalr provider. See the command below to update an existing workspace's execution-mode.

##First set environment variables:
 export SCALR_HOSTNAME=<your-account-name>.scalr.io
 export SCALR_TOKEN=<your-token>
 export SCALR_ACCOUNT=<your-account-id>

##Make the CLI call to update the workspace:

scalr update-workspace -environment-id=<environment-ID> -workspace=<workspace-id> -name=<workspace-name> -execution-mode=local

Scalr Provider

The Scalr provider can also be used to update the workspace settings. We highly recommend managing all Scalr objects through the Scalr Terraform or OTF provider to easily scale your operations. The workspace resource must be used and you simply add the execution_mode attribute:
resource "scalr_workspace" "cli-driven" { 
name = "<workspace-name>" 
environment_id = "<environment-id>"
execution_mode = "local"

Scalr API

To do this in the Scalr API, you’ll want to call the create workspace or update workspace endpoints, depending on the situation. The example below is updating an existing workspace:

curl --request PATCH \
     --url https://<your-account-name>.scalr.io/api/iacp/v3/workspaces/<your-workspace-id> \
     --header 'Prefer: profile=preview' \
     --header 'accept: application/vnd.api+json' \
     --header 'authorization: Bearer <your-token>' \
     --header 'content-type: application/vnd.api+json' \
     --data '
  "data": {
    "attributes": {
      "execution-mode": "local",
      "name": "my-workspace"
    "type": "workspaces"

Pros and Cons of Local Execution Mode

The main pro of using local execution mode is that you are not charged for it in Scalr. As mentioned before, this is helpful during early development cycles when you might be going through a lot of trial and error and don’t need the advantages of a remote backend like Scalr.

That being said, there are a few cons to setting the workspace to local. First, you are not using the Scalr pipeline, so you will not see the run reported anywhere in Scalr. This also means that you will not see the cost estimation or be able to utilize the Open Policy Agent integration. Lastly, the biggest con is that you are not able to use the provider configurations that are stored in Scalr for authentication to an external provider. This is one of the more critical security features in Scalr as the credentials are automatically passed to the runs without the users having to supply them. But, as mentioned, this might be for development environments where some of the security protocols are relaxed.

Wrapping Up

The execution-mode attribute of a workspace gives organizations flexibility on choosing how they want to use Scalr. With this set, you have the ability to use Scalr for free until you decide you want to take advantage of the full feature set, which includes integrations, reporting, and more.

Sign Up and get started!

Note: While this blog references Terraform, everything mentioned in here also applies to OpenTofu. New to OpenTofu? It is a fork of Terraform 1.5.7 as a result of the license change from MPL to BUSL by HashiCorp. OpenTofu is an open-source alternative to Terraform that is governed by the Linux Foundation. All features available in Terraform 1.5.7 or earlier are also available in OpenTofu. Find out the history of OpenTofu here.

Start using the Terraform platform of the future.

A screenshot of the modules page in the Scalr Platform