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

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 allows teams to view the impact of changes and apply them from a feature branch or pull request before merging. This can be utilized for iteration in development environments or for validating changes prior to mainline integration.

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: Execute scripts before Terraform/OpenTofu initializes the backend and providers. This can be used for setting up dynamic configurations or fetching credentials.
• Pre-plan: Run scripts before the plan operation. Used for static code analysis (e.g., tfsec, tflint), compliance checks, or generating dynamic input variables.
• Post-plan: Execute scripts after a plan has been generated. This can be used for custom plan analysis, cost estimation checks, or sending notifications about planned changes.
• Pre-apply: Run scripts before the apply operation. Used for final validation, integration with external approval systems, or security checks.
• Post-apply: Execute scripts after changes have been applied. Used for sending deployment notifications, updating CMDBs, running integration tests, or cleaning 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 feature allows the creation of dependencies between workspaces in different Scalr environments. This is applicable for scenarios such as promoting infrastructure changes between staging and production environments, 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: Users have full control over the agent's environment. This allows for the installation of specific versions of Terraform, OpenTofu, providers, or other CLI tools and dependencies required by custom hooks or IaC modules. The agent's operating system can be customized, allowing users to define their 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.

Conclusion

Scalr automates and governs Terraform and OpenTofu workflows. The CI/CD pieces covered here (GitOps support, custom hooks, run triggers, and customizable execution environments) give teams a way to manage infrastructure as their automation needs grow more involved.

Further information is available in the Scalr documentation. A demo can be requested to view these features.