Request access to Scalr IaCP

Scalr IaC Platform Documentation

Welcome to Scalr IaC Platform. The next generation Cloud IaC Platform. Scalr seamlessly integrates the world of Terraform with the enterprise and MSP requirements of scaling usage, governance, collaboration and multi-tenancy.

Scalr IaC Platform Overview

What is Scalr IaC Platform?

Scalr IaC Platform is a remote backend for Terraform that helps your organization adopt Terraform and DevOps practices at scale. It does so by:

  • Centralization of state files and ensuring safe concurrent access to state files
  • Tracking all provisioned resources and the dependencies between them
  • Using Open Policy Agent to ensure a compliant and automated infrastructure as code workflow
  • Forecasting costs prior to deployments
  • Easily deploy infrastructure through a service catalog based on Terraform Templates
  • Implementing multi-tenancy allowing multiple organizations to create and maintain their own workflows while adhering to enterprise standards

Using Scalr IaC Platform

There are three distinct methods for utilising Scalr for all aspects of deploying infrastructure through Terraform

Service Catalog

  • Self service for deployment and operations based on Terraform templates


Scalr as a Remote Backend

  • CLI/API driven runs with Scalr IaC Platform remote back end for DevOps


DevOps Automation

  • Workspaces tied to templates in a VCS for DevOps workflows

    • Automated Deployments (CI/CD)

    • Dry runs triggered by PR’s and Commits in linked VCS repos


Terraform templates can be run through Scalr using any of the above methods without any modification. This includes the following capabilities.

  • Automatic webhook setup for workspaces bound to VCS repos for PR and deployment automation
  • Prompts for mandatory and optional Input Variables during self service
  • Support for Terraform environment variables (TF_VAR_var_name) in workspaces

Scalr Features

Scalr extends the capabilities of Terraform with the following features

Integration with Policies

Scalr integrates with two types of policies to provide both automated policy enforcement (Open Policy Agent) and control & choice over user inputs to Terraform runs (Scalr policies).

Automated Policy Enforcement

  • Automated and mandated policy application to all runs using Open Policy Agent (OPA) policies.

    Example: Policy defined in OPA at account scope and applied to a run.

    package terraform
    import input.tfplan as tfplan
    import input.tfrun as tfrun
    deny[reason] {
        cost_delta = tfrun.cost_estimate.delta_monthly_cost
        cost_delta > 10
        reason := sprintf("Plan is too expensive: $%.2f, while up to $10 is allowed", [cost_delta])

Govern Input through Scalr Policy

  • Control input values during self service by binding input variables to Scalr variables
    • Define lists of allowed values
    • Set REGEX to control input format
  • Control input values during self service by binding input variables to Scalr policy

These bindings are achieved through an additional file in the template. scalr-module.hcl conforms to HCL syntax and defines the input variable bindings.

Example: Binding input variable project_code to Scalr variable billing_code

version = "v1"

variable "project_code" {
  global_variable = "billing_code"

Example: Binding input variable region to policy cloud.locations and then binding input variable networks to policy cloud.networks based on the region variable

version = "v1"

variable "region" {
    policy = "cloud.locations"
    conditions = {
    cloud = "ec2"

variable "networks" {
  policy = "cloud.networks"
  conditions = {
    cloud = "ec2"
    cloud.location = "${var.region}"

Consume Cloud Credentials in Workspaces

  • Automatically inject cloud credentials stored in Scalr into global variables recognized by Terraform

    Example: Cloud Credentials for accessing AWS API’s have been set up in Scalr.

    Variables are automatically declared by Scalr in the workspace where the Terraform run takes place. For example..


    Then your template would simply contain a provider block like this which does not need to explicitly reference credentials.

    provider "aws" {
      region     = var.region