Learn Terraform - Managed IaC Platforms (Terraform Cloud / Spacelift)

#Introduction

After building our own CI/CD pipeline in episode 13 — writing GitHub Actions and GitLab CI workflows for fmt, lint, security scan, plan, all the way to apply with an approval gate — in this episode we'll discuss an alternative that's increasingly popular in large organizations: managed IaC platforms such as Terraform Cloud (now called HCP Terraform), Spacelift, env0, and Scalr.

In episode 13, you may have realized that building a correct IaC pipeline requires many components: OIDC configuration, separate plan/apply workflows, environment protection, plan artifacts, and a state backend with locking. All of that is infrastructure work your own team has to maintain. The question now is: do we need to build and maintain all of that, or is there something that can manage it for us?

Managed IaC platforms answer that question by taking over those components as a managed service: remote execution runners, built-in VCS integration, state management with encryption & locking, a private module registry, and policy enforcement. Why is this topic important in the real world? Because once an organization has many teams and many Terraform stacks, the cost of maintaining self-managed pipelines becomes larger than the cost of a platform subscription — and those platforms also add a safety net (RBAC, audit log, policy) that's hard to build yourself at the same quality.

#Main Discussion

#What Do Managed IaC Platforms Solve?

Let's be honest for a moment: everything built in episode 13 is correct and works. But if you work in an organization with 10 teams each managing 5 infrastructure stacks, that's 50 pipelines to maintain. Each pipeline needs configuration, versioning, monitoring, and a responsible person. At that point, platform engineering teams start asking: "why are we rebuilding the same wheel 50 times?"

A comparison of three Terraform execution models:

#Core Managed Platform Features

Even though each platform has its own uniqueness, the following five features are the backbone shared by almost all managed IaC platforms:

Each of these features is essentially something we built manually in the previous episodes, packaged into an integrated built-in feature. That's why adopting these platforms is often called "buying back time" for platform teams.

#Managed IaC Platform Comparison

Here's a comparison of the four main platforms you should know:

These four platforms compete along three main axes: depth of the Terraform ecosystem (HCP Terraform excels because it's made by the same vendor), multi-tool flexibility (Spacelift and env0 support more than just Terraform), and enterprise cost control (Scalr and env0 stand out). None is "best" in absolute terms — it all depends on organizational needs, which we'll discuss in the adoption scenarios section.

#The VCS-Driven Workflow in HCP Terraform

To understand how these platforms work, let's break down the most common workflow: the VCS-driven workflow in HCP Terraform. The concept is the same across all platforms.

Once you connect a repository (e.g. GitHub) to a workspace, each of the following events triggers a run:

1. Developer pushes commit / opens PR   → "Plan" run runs automatically on a remote runner
2. Plan finishes                        → the result is posted on the PR (status + diff)
3. Reviewer approves the PR             → PR is merged to main
4. Merge to main                        → "Plan" run for main, then waits
5. Engineer clicks "Confirm & Apply"    → "Apply" run is executed on a remote runner
6. State updated + audit log            → the whole history is stored on the platform

Each run has stages that look like a mini pipeline:

#The cloud Block Configuration

How does Terraform know it should run on the platform instead of locally? The answer is the cloud block in the configuration:

terraform {
  cloud {
    organization = "mycompany-infra"
 
    workspaces {
      project = "platform"
      name    = "prod-vpc"
    }
  }
}

Once this block exists, running terraform init changes Terraform's behavior:

• State is no longer stored locally — Terraform pulls the state from the prod-vpc workspace in the cloud.
• terraform plan and terraform apply run from the CLI will delegate execution to a remote runner on the platform.
• terraform plan can even be triggered from a laptop without any cloud credentials — the result is sent back as logs.

$ terraform init
 
Initializing HCP Terraform...
 
Initializing provider plugins...
- Finding latest version of hashicorp/aws...
 
Successfully configured the backend "cloud"! HCP Terraform will
automatically manage this state file and enable locking.

#Policy Enforcement: The Final Safety Net

One of the most valuable features of managed platforms is policy enforcement — the application of Policy as Code, which we'll dive deep into in episode 16. Imagine the flow:

# (simple example, policy language simplified)
policy "no_public_s3" {
  source = <<-EOF
    deny[msg] {
      resource := terraform.resources[s3_bucket]
      resource.config.acl == "public-read"
      msg := "S3 bucket must not be public-read"
    }
  EOF
}

When a run produces a resource that violates a policy, the platform automatically blocks the apply — before the change reaches the cloud. This is a security layer that's usually the most expensive to build yourself at high quality, because policies are evaluated on every run and can't be skipped by engineers.

#Real-World Adoption Scenario

So it doesn't stay abstract, let's look at a realistic adoption scenario.

Case study: PT Maju Teknologi, 8 teams, 40 Terraform stacks.

1. Initial condition. Every team has its own repo and GitHub Actions pipeline. There are 3 incidents in a year because developers applied from laptops, and 2 stacks broke because of state conflicts. The platform team spends ~30% of its time maintaining pipelines instead of writing infrastructure.
2. Decision. After evaluating, they choose HCP Terraform because it's 100% Terraform (no syntax migration), Sentinel policies can be shared across teams, and Vault integration for secrets is built-in.
3. Migration. All backend "s3" blocks are replaced with cloud blocks (leaving only a few for regulated data). The 40 stacks are migrated into 40 workspaces organized in per-team projects. GitHub Actions pipelines are trimmed — only bootstrap and non-Terraform tasks remain.
4. Result. No more applying from laptops (SSO login to the platform is required). Central policies block public S3 and untagged resources across all teams. A central audit log satisfies compliance needs. The platform team shifts from "maintaining pipelines" to "writing policies & improving architecture".

#When Should You Use a Managed Platform? (Pros & Considerations)

So your decision is well-informed, let's summarize the advantages and the things to consider:

#Common Managed Platform Pitfalls

#Conclusion

In this episode 14 we discussed how managed IaC platforms — HCP Terraform, Spacelift, env0, and Scalr — take over the components we built manually in episode 13: remote execution, VCS integration, managed state management, private module registry, and policy enforcement. We also saw that the VCS-driven flow on these platforms is actually a ready-made implementation of the "no applying from laptops" principle with an approval gate, which we previously had to assemble ourselves in YAML workflows.

Key takeaways to bring home:

• Managed platforms are a management layer on top of Terraform, not a replacement for it.
• Five core features: remote runner, VCS integration, managed state, private module registry, policy enforcement.
• The cloud block moves state and execution to the platform; understand its implications for data security.
• Policy engines (Sentinel/OPA) are runtime guards that complement static scans like Checkov.
• Adoption makes the most sense when the organization has many teams & stacks, where the cost of maintaining pipelines exceeds the subscription cost.

In the next episode 15, we'll dive into a topic that's been touched on over the last few episodes — Secret Management & State Security — discussing why state files store secrets in plaintext, how to secure them with encryption & IAM, and how to pull secrets from HashiCorp Vault, AWS Secrets Manager, or SOPS with sensitive = true. Stay excited!