TrademarkTrademark
Features
Documentation

An Overview of Scalr's CI/CD Capabilities for Terraform and OpenTofu

This post provides an overview of Scalr's CI/CD capabilities for Terraform and OpenTofu, detailing its GitOps workfl
Sebastian StadilMay 20, 2025
An Overview of Scalr's CI/CD Capabilities for Terraform and OpenTofu
Key takeaways
  • Scalr automates Terraform and OpenTofu operations and supports two GitOps models: Merge-Before-Apply and Apply-Before-Merge.
  • Custom Hooks let teams run scripts at pre-init, pre-plan, post-plan, pre-apply, and post-apply stages, with a hooks registry for centralized management.
  • Run Triggers manage dependencies by chaining workspace runs, creating cross-workspace dependencies, federating environments, and reacting to VCS events.
  • Self-hosted agents provide private network access, custom execution environments, and keep code and credentials within a controlled network perimeter.
  • Scalr's cross-workspace run triggering is comparable to features in platforms like Terraform Cloud and Spacelift.

Infrastructure as Code lets you manage and provision infrastructure through code. Terraform and its open-source fork, OpenTofu, are two of the common tools for it. As more teams adopt IaC, they need a way to automate runs, collaborate on changes, and keep some governance over what gets applied. Scalr is a platform built around Terraform and OpenTofu operations.

This post walks through Scalr's CI/CD features: GitOps workflows, custom hooks, run triggers, and ways to customize the execution environment.

Core CI/CD Functionality

Scalr automates Terraform and OpenTofu operations. It integrates with Version Control Systems (VCS) like Git, supporting GitOps workflows. Scalr supports two primary models:

  1. Merge-Before-Apply: Changes are proposed via a pull/merge request. Scalr can automatically run a plan and report the output. After review and merge into the main branch, Scalr proceeds with the apply operation. This model ensures that only approved code is applied to the infrastructure.
  2. Apply-Before-Merge (or Plan-and-Apply on PR): This model lets teams see the impact of changes and apply them from a feature branch or pull request before merging. It's useful for iterating in development environments, or for checking changes before they hit the mainline.

Scalr's CI/CD automates standard Terraform/OpenTofu commands (init, plan, apply), reducing manual intervention and potential errors.

Custom Hooks for Workflow Extension

Most IaC workflows need a few steps that go beyond an automated plan and apply. Scalr's Custom Hooks let you run your own scripts and tools at different stages of a run, so you can shape the CI/CD process to fit how your team works.

Available hook points include:

  • Pre-init: Scripts that run before Terraform/OpenTofu initializes the backend and providers. Handy for setting up dynamic configurations or fetching credentials.
  • Pre-plan: Scripts that run before the plan operation. People use this point for static code analysis (e.g., tfsec, tflint), compliance checks, or generating dynamic input variables.
  • Post-plan: Scripts that run once a plan has been generated, which is where custom plan analysis, cost estimation checks, or notifications about planned changes tend to live.
  • Pre-apply: Scripts that run before the apply operation, for final validation, integration with external approval systems, or security checks.
  • Post-apply: Scripts that run after changes have been applied. Teams use this stage to send deployment notifications, update CMDBs, run integration tests, or clean up temporary resources.

Hook scripts can come from a VCS repository or be downloaded from an external location. Scalr also has a "hooks registry" for managing hooks in one place. A platform team can define standard hooks there and hand them to development teams, which keeps usage consistent across an organization.

Run Triggers for Dependency Management

Infrastructure components often depend on each other, so a change in one place needs to roll through to another. Scalr's Run Triggers handle those dependencies.

Run Triggers offer the following capabilities:

  • Chaining Workspace Runs: A workspace run can be configured to automatically trigger a run in another workspace upon successful completion, creating deployment pipelines (e.g., a network infrastructure update triggering an application deployment).
  • Creating Dependencies Between Workspaces: Run triggers define explicit dependencies. If Workspace B depends on an output from Workspace A, a successful apply in Workspace A can trigger Workspace B to re-plan and apply, incorporating the latest outputs.
  • Federate Environments: This lets you create dependencies between workspaces in different Scalr environments. That's handy when you're promoting infrastructure changes from staging to production, or when different teams manage interconnected components in separate environments.
  • VCS Event-Based Triggers: Run triggers can be initiated based on VCS events, such as a push to a specific branch or the creation of a tag. This integrates IaC automation with Git workflows.

Scalr's cross-workspace run triggering is comparable to features in other platforms like Terraform Cloud (TFC) or Spacelift for managing infrastructure dependencies.

Customizable Execution Environments: Self-Hosted Agents

Not every team can run their workloads on shared, managed infrastructure. Scalr supports both managed execution and self-hosted agents (runners).

Self-hosted agents provide the following benefits:

  • Network Access: Agents can be deployed within a private network, enabling access to non-publicly exposed resources like internal artifact repositories, secret management systems, or private cloud APIs.
  • Custom Execution Environment: You have full control over the agent's environment. You can install specific versions of Terraform, OpenTofu, providers, or other CLI tools and dependencies that your custom hooks or IaC modules need. You can customize the agent's operating system too, and define your own execution image.
  • Compliance and Security: For organizations with specific security or compliance requirements, self-hosted agents ensure that code and credentials remain within the controlled network perimeter during execution.

With that control, Scalr can fit into setups that managed execution alone would not reach.

A Scalr workspace runs Terraform or OpenTofu. Its hooks, run triggers, and agent execution are all built around that engine, so the CI/CD workflow maps directly to Terraform and OpenTofu commands and run stages. As a drop-in Terraform Cloud alternative, Scalr gives teams a workflow purpose-built for Terraform and OpenTofu end to end.

Where this leaves you

Scalr automates and governs Terraform and OpenTofu workflows. GitOps support, custom hooks, run triggers, and customizable execution environments each cover a different part of that work, and together they give teams room to manage infrastructure as their automation needs grow more involved.

The Scalr documentation covers each of these features in more depth, and you can request a demo to see them running.

About the author
Sebastian StadilCEO at Scalr
Sebastian Stadil is the CEO at Scalr. He has over 15 years of devops experience, and started his career with AWS in 2004.