Use local execution mode for free with Scalr

There are two types of execution modes in Scalr: remote and "State storage only" (the mode is still referred to as local in the API, provider, and HCL). 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. State storage only 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 State storage only runs in Scalr.

Use Cases for State Storage Only Execution

We typically see teams switch a workspace to State storage only during early development. At that stage there's a lot of trial and error in the Terraform or OTF code, and some of the integrations Scalr provides matter less. Once the code is ready for production, they usually switch the workspace back to remote and pick up the full benefits of a remote backend.

The other common case is an organization that just wants a little more structure and a central place to store state. Maybe you already have a pipeline outside of Scalr but still want to organize workspaces and restrict who can read state through RBAC. State storage only covers that, and it gives you a private module registry too.

Add the Remote Backend

To take advantage of Scalr for state storage, you will need 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 State Storage Only Execution Mode

The workspace attribute execution-mode can be updated in Scalr through the UI, Scalr CLI, provider, or API.

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 State Storage Only Execution Mode

The main pro of State storage only execution mode is that you are not charged for it in Scalr. As noted above, that helps during early development, when you're going through a lot of trial and error and don't yet need what a remote backend like Scalr offers.

There are some cons to weigh against that. Since the run doesn't go through the Scalr pipeline, it won't be reported anywhere in Scalr. You also lose cost estimation and the Open Policy Agent integration. Variables stored in Scalr won't apply either, because variable injection happens in the remote run container. The biggest con is that you can't use the provider configurations stored in Scalr for authentication to an external provider. That's one of the more important security features in Scalr: credentials are passed to the runs automatically, so users never have to supply them by hand. For a development environment where some of the security protocols are relaxed, that tradeoff may be fine.

Wrapping Up

A workspace's execution-mode attribute lets you decide how you want to use Scalr. Set it to State storage only and you can use Scalr for free until you're ready for the full feature set, which includes integrations, reporting, and more.

Sign Up and get started!