Use local execution mode for free with Scalr

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>" 
    } 
  } 
}

Ways to Set a Workspace to Local Execution Mode

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

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

Sign Up and get started!