Apply for invite to IaCP

Template registry

Scalr IaCP Self service is being re-designed into the Template Registry. This will be released very soon. In the mean time we are including the current guide to creating service offerings below.

Guide : Self service with Terraform

Scalr provides the capability to publish parameterised Service offerings based on Terraform templates that are stored in VCS repositories. This enables users without Terraform expertise to deploy their own infrastructure without having to rely on DevOps / Operations to deploy for them.


This page explains how to set up a service offering in Scalr




Account scope

Organisation layer in Scalr. Used to administer environments, policy, provider credentials and access controls

Environment scope

Working environments for teams and users. Multiple per account. Workspaces for running Terraform live at this scope

Provider credentials

Credentials for clouds and other providers set up at account scope and automatically added to workspaces as environment variables


Run time environment and stage storage for Terraform. Includes Terraform and Environment variables

Template registry

Self service deployment backed by Terraform. Gives simplified interface to users so no Terraform knowledge is required.

How it Works

  1. Template registry offering is linked to template in VCS

  2. User requests deployment

  3. IacP pulls template and prompts user to enter values for Input Variables

  4. IacP creates “workspace” and runs the template to deploy infrastructure

  5. User views results in the workspaces


A workspace is a virtual environment inside IaCP that is configured to perform Terraform runs and store the state files.

Scalr uses the input variables in the template to create input fields when requesting a service from the registry. Your Terraform template will work in the Scalr template registry without any modifications.

However Scalr also makes it easy for you to provide drop down lists of allowed values and other controls over the inputs users can provide, with some simple additions to your template.


Most of this tutorial is done at environment scope (blue), but watch out for the bits that are done at account scope (green).

You can switch between Account and Environment scope using environment switcher in the top right corner.


If you need to create an environment, goto account scope -> Environments -> New Environment. Select IaCP and save.

Setup Overview


We will use an example of deploying an AWS instance to show you how to set up and test a template registry offering using the following steps

  1. The Terraform Template - Terraform template in Git Version Control System (VCS)

  2. Link IaCP to VCS - So IacP can pull templates

  3. Provider Credentials - To enable providers to connect

  4. Create Offering - Linked to the template in VCS

  5. Service Request - Make a request to deploy from the offering

  6. Input Parameters - Provide values to template input variables

  7. Workspace - View the run and results in dedicated workspace

We will also show you how you can provide drop down lists and input controls to make it easier to complete a service request.

  1. Input Controls : Policy - Using IaCP policies to control input values and provide drop down lists

  2. Input Controls : Variables - Using IaCP variables to control input formats and values

The Terraform Template

  • The Terraform template must be in a git repo

  • This example initially contains 3 files,, and

  • Create a new repo in your VCS account and add these 3 files with the contents shown below. defines the resources and the provider.

provider "aws" {
  region     = var.region

resource "aws_instance" "scalr" {
  ami                    = var.ami
  instance_type          = var.instance_type
  subnet_id              = var.subnet
  vpc_security_group_ids =
  key_name               = var.key
} with all of the values blank to force user input

variable "region" {
description = "Region"

variable "instance_type" {
description = "Instance Type"

variable "subnet" {
description = "Subnet ID"

variable "sg" {
description = "AWS Secruity Group"
type = list(string)

variable "key" {
description = "AWS Key"

variable "vpc_id" {
description = "VPC"

variable "ami" {
description = "AMI"
} to provide the user with the information needed to use the deployed instance.

output "instance_id" {
  description = "Instance ID"
  value       =

output "public_ip" {
  description = "Public IP"
  value       = aws_instance.scalr.public_ip

output "private_ip" {
  description = "Private IP"
  value       = aws_instance.scalr.private_ip

Provider Credentials


All providers in the template need credentials to authenticate with. For cloud providers these are typically access keys. All providers allow the credentials to be supplied via environment variables. IaCP allows you to set up credentials for cloud providers so that the necessary environment variables will automatically be set up in the workspace.

Setting up cloud credentials in is a three step process and is done at the account scope (green).

  1. Set up necessary authentication in the cloud provider (varies from cloud to cloud).

    • In the EC2 console navigate to IAM -> Users -> Select a user -> Security Credentials -> Create Access Key

    • Save the access key and secret key

  1. Create Cloud Credentials in Scalr.

    • In Scalr at account scope navigate to cloud credentials -> add credentials. Select AWS, enter a name and the two keys and save.

      ../../_images/AWS-Keys.png ../../_images/AWS-Keys-Scalr.png
  1. Link Cloud Credentials to the environment.

    • Navigate to environments

    • Select the required environment and click on the clouds tab.

    • Click the link symbol on the right side for the cloud you want to link.

    • Select the credentials and save.


Create Offering

  • Go to “Template Registry”, and click on “Management”:

  • Click on “New Template” and enter the information for the VCS provider, branch and directory where the template is stored

  • Set “Track” as required

  • Click “Save & Fetch”. IaCP will now fetch the template metadata from the VCS provider and the status should go to “Active” within a few seconds.

Service Request

  • Go to “Template Registry”, and click on “Request”:



Input Parameters


Provide values for all required inputs and click “Deploy”.


You will now be redirected to the Workspace page where you can track the progress of the deployment.



Workspace dashboard, including outputs from the last run.


Run details showing plan, cost, policy and apply phases.



You may have noticed how difficult it was to fill in all the values. You had to go to the EC2 console to look up ami’s, security groups etc. Now we will show you how to make that much easier using IaCP policies and global variables.

Input Controls : Policy

IaCP policies (Account scope[green] -> Policy Engine -> Policy Groups) can be used to specify allowed values for a variety of different cloud resources parameters.

These policies can be bound to input variables in the template so that the allowed values are provided in a drop down list

You will need to create an AWS Policy groups and then add 5 policies.

  • cloud.instance_types

  • cloud.locations

  • cloud.security_groups

  • cloud.networks (specify the cloud credentials)

  • cloud.subnets (specify the cloud credentials and network)

  • Click on “New Policy Group” and select “AWS” as the type:

  • Create the above policies “New Policy” and save.

  • Policy group must be linked to the environment. Click on “Environments”, “Policies”, then click on the green link on the right and save:


Now modify the template to bind the policies to the required input variables. A new file scalr-module.hcl must be added to the repository as follows. There are 5 entries, some with multiple conditions, that are required.

version = "v1"

# Bind region to a Policy that restricts to specific cloud locations.
# This acts an automatic look-up. IaCP queries the cloud api to obtain the possible values
variable "region" {
  policy = "cloud.locations"
  conditions = {
  cloud = "ec2"

# Bind vpc_id to a networks policy. Note the policy is region specific so this works in any region
variable "vpc_id" {
  policy = "cloud.networks"
  conditions = {
  cloud = "ec2",
  cloud.location = "${var.region}"

variable "subnet" {
  policy = "cloud.subnets"
  conditions = {
  cloud = "ec2",
  cloud.location = "${var.region}", = "${var.vpc_id}"

variable "instance_type" {
    policy = "cloud.instance.types"
    conditions = {
    cloud = "ec2"

variable "sg" {
  policy = "cloud.security_groups"
  conditions = {
  cloud = "ec2"

Notice how some of the bindings have conditions based on other variables. This enables IaCP to provide context sensitive lists such as the right subnets for the chosen VPC.

We will test this after the next section, but feel free to try it now.


When you commit this new file to the repo the template registry will automatically be updated in IaCP within a few seconds.

Input Controls : Variables

It isnt possible to provide policies for all the inputs, so we can use Global variables to create our own lists of allowed values.

Global variables can be created at either the account or environment scope. If created at the account scope they will be inherited by all environments. Global variable lists are made up of multiple label+value pairs. The label is what the end user will see, the value is what is actually used on the backend.

  • Go to the environment scope:


You need to create two variables called ssh_key and ami.

  • Go to “Global Variables”, and “New Variable”:

    • Set the “Variable Type” as “List”. This will result in a dropdown for the user.

    • Click on the gear icon to enter values and labels.



  • Make sure you save the entire Global Variable page.

Two new entries must be made in scalr-module.hcl

variable "key" {
  global_variable = "ssh_key"

variable "ami" {
  global_variable = "ami"

After setting up these bindings and committing the changes to the repo you can make a new template registry request and see how the request screen has changed. Note the drop down fields and the icons indicating policy and variable bindings.