Getting Started - Scalr Provider

In this tutorial, we are going to focus on some of the basics to get started with the Scalr provider. Before using the provider, we do suggest familiarizing yourself with the various concepts in Scalr as that will then make it easier to automate the management of Scalr with the provider.

One of the widely agreed upon best practices in using Scalr is that Scalr should be managed through the Scalr Terraform Provider. Most customers have an onboarding process which involves using the Scalr provider to “vend” environments to onboard teams.

Getting Started

To start, we recommend identifying an environment that will be used for Scalr administration. There isn’t an “admin environment” designation in Scalr itself, this is just using a specific environment to then manage all other objects in Scalr. First, we’ll create a service account, pull the SCALR_TOKEN, and assign that to the admin environment. By default, every run has it’s own unique SCALR_TOKEN which has enough permissions to execute a run, but not to manage other objects in Scalr, which is why we need to override this.

Create a Service Account

A service account can only be used to access the Scalr API, it cannot be used to access the UI. We strongly recommend against the use of personal tokens for Scalr administration. If the person associated with a personal token leaves the company, all of your automation is now broken. Service accounts can be created by going to the account scope and then IAM:

Click on the account name in the environment switcher, in this case it is scalr-demo:


Select service accounts:


Create the service account and click on the gear to generate the SCALR_TOKEN for the service account:


Save the token for use in a later step.

Now, you must provide access for the service account to be able to access Scalr. To do this, go to IAM, then access policies, and add an access policy with the admin role assigned at the account scope:


Create a Management Environment

There are different structures when it comes to automating your objects in Scalr. Some customers prefer having a centralized approach and all Scalr objects are managed in workspaces in one environment or some prefer to be more decentralized and leave it up to app teams to automate objects in their own environments. For this tutorial, we will stick with a centralized approach and create a management environment.

To create a management environment, either rename an existing one or go to the account scope and create a new one in the environments page:


Set the Service Account Token

Lastly, you will need to need to override the default SCALR_TOKEN in the Scalr runner by adding the service account token as a shell variable at the environment scope. The default Scalr runner token has just enough permissions to execute the run, but being that we want to manage Scalr objects using the provider we must override the runner token with the elevated service account token. For now, we’ll do this at the environment scope by adding a shell variable. All workspaces within an environment will now inherit this variable and it will be set during the run.

Grab the token that was created earlier for your service account, create a SCALR_TOKEN variable, and add the token as the value. Ensure you set the value as sensitive and final so end users cannot see it or override it.


The prerequisites are now done and we can start automating with the Scalr provider!

Provider Tutorials

Below are some use case specific tutorials with the provider: