Workspace Types

A workspace is created within an environment and there are three types of workspaces to select from:

VCS Driven

Use pull request automation to automatically kick off the Terraform and OpenTofu workflow. By linking a workspace to a specific branch of the repository a webhook is created in the VCS provider that will POST to Scalr for every pull request or commit/merge that affects that branch. Scalr will then automatically perform a “dry run” (terraform plan) for every pull request and a run (terraform apply) for every commit/merge.

When using GitHub, Azure DevOps, or GitLab the plan details are posted back to the pull request as a comment. When using Gitlab or Bitbucket, the checks are sent back to the pull/merge request. Click here for instructions on how to set up a VCS workspace.

See a quick demo on this here:

CLI Driven

Use Terraform or OpenTofu OSS to create runs with Scalr acting as the remote backend. This is the best option for the early development phase of Terraform code or when you want to plug Scalr into an existing workflow that utilizes the CLI, like a Github Action. Click here for instructions on how to set up a CLI workspace.

See a quick demo on this here:

No-Code (Module Driven)

No-code workspaces are those that are deployed from modules in the Scalr module registry. This is great for organizations standardizing on Terraform and OpenTofu, but not all users have the skillset to write Terraform code. In this case, users are able to select from a list of pre-defined modules, fill in missing variables, and deploy the workspace. A no-code workspace can be deployed directly from the module registry or by selecting "module" as the source when creating a workspace. Click here for instructions on how to set up a No-Code workspace.

See a quick demo on this here:

API Driven

Use the Scalr API to create a workspace and upload the Terraform or OpenTofu configuration files. This type of workspace is useful when integrating with an existing pipeline or tooling. By using this method, you are always in control of when the code is pushed to Scalr rather than relying on a VCS webhook. Click here for instructions on setting up an API driven workspace.