Request access to Scalr IaCP

Concepts and Terminology

Scalr IaC Platform Environments


Scalr environments allow you to organize Terraform Workspaces and Terraform based service catalog offerings into logical groupings. Each Scalr IaC Platform environment is linked to one of more sets of cloud credentials in different cloud providers, allowing you to integrate these credentials into your Terraform templates. You can also link Scalr policies and define global variables to help ensure the required levels of governance and compliance are applied to all Terraform based deployments that run through the environment.

Environments can be created for any purpose that suits the way you work. Some common examples are as follows:

  • SDLC based, e.g. Dev, Staging, Prod.
  • Application specific
  • Team or individual

Regardless of how you organize environments you will need to create cloud credentials and teams before creating your Scalr environments. Please see initial_configuration.

VCS Providers


VCS (Version Control System) Providers are the mechanism for registering credentials of source code repositories in Scalr. Service catalog offerings and workspaces in Scalr environments are linked to a specific repository in a VCS Provider, and the Terraform templates are pulled into Scalr from the repo for execution. The VCS provider configuration is only the access credentials. Each VCS provider configuration will potentially provide access to multiple Terraform template repositories as specified in either the service catalog or Workspace configuration.

Currently supported VCS’s:

  • github Github SaaS
  • gitlab Gitlab SaaS
  • gitlab Gitlab CE/EE

Service Catalog


The Scalr service catalog allows DevOps to publish Terraform templates as user enabled service offerings. A service catalog offering is a link to a specific repository, branch and optional sub-directory within a VCS provider. Upon creation of an offering Scalr will fetch the Terraform template files in order to be able to analyse and execute them when required.

The service catalog offerings automatically convert Terraform input variables to user prompts in the UI. The Terraform variables can be bound to Scalr policy and Scalr global variables in order to provide governance and control of allowed input values, such as restrictions on cloud deployment parameters (Location, Instance type etc), and to offer input drop down lists.

Service catalog offerings can be configured to be automatically updated when new code versions are committed to the associated repository, thus enabling the final step in complete CI/CD pipelines that publish service offerings to end users.

When a user requests a Service from an offering a new Workspace is created to run the service and the end user is given access to a Service object to allow them to manage the lifecycle of their service request. Once a Service has been created from an offering it will be fixed at the commit level from which it was created and will NOT automatically be updated by future commits to the repo it was created from.



In Scalr environments A “Service” represents a single deployment from a service catalog offering. The Service allows a user to control the running deployment by offering options such as destroy, launch etc.

There can be any number of Services launched from the same service catalog offering.



A workspace in Scalr environments is analogous to a Terraform Workspace. A Workspace is where a Terraform template will be run and will provide configuration information, visibility of deployed resources, details of all runs, variable configuration and drift management.

Workspaces can be created directly and linked to a repository in a VCS Provider, or they are created as a result of a service request from a service catalog offering.


When a workspace is created from a service catalog it is NOT linked to the VCS Repo. A service catalog workspace will only ever use the last committed version in the repo at the time the request was made. Manually created workspaces can be configured to pull from the repo after each commit.

Policy Application

Scalr provides two separate policy mechanisms to allow developers and administrators to implement standards and governance across all cloud deployments through Terraform.

Scalr Policy and Variable Binding in Service Catalog

As mention under Service Catalog Scalr uses Terraform Input Variables to create user input prompts for service catalog requests. By default these variables allow the user to input any response as there is no validation or control. Scalr can apply controls over the allowed input values and formats by binding the Terraform Input Variables to Scalr Policies and/or Scalr Variables.

Policy Binding:

Binding a Terraform Input Variable to a Policy will limit the range of allowed values to those that are specified by the policy, e.g. for options such as cloud_location, instance types etc you can create whitelist or blacklist policies and the service catalog will only showed the permitted values to the end user.

Global Variable Binding:

Binding a Terraform Input Variable to a Scalr Global Variable allows you to control the allowed input values and/or formatting of the input. List type GV’s will populate the drop down in the Service catalog and printf and REGEX formatting on the GV will be enforced.

Open Policy Agent Policy Enforcement

Scalr allows the definition of Open Policy Agent (OPA) policies which are linked to environments. This causes the policies to be applied to ALL runs taking place in every workspace regardless of where they are triggered from. This ensures deployments will meet all required business policies and also applies to Dry Runs triggered from VCS so the PR checks will fail if the template violates policy.

Scalr Remote Backend

To benefit from the capabilities of Scalr when using the Terraform CLI or API, you must configured your local workspace to use Scalr as the remote backend. See IaCP Remote Backend (CLI) Tutorial.

Next Steps

We encourage all users to start with initial_configuration.