Terraform Cloud vs Spacelift

Terraform Cloud is the safe default if you run only Terraform, your resource count is modest, and you're happy inside HashiCorp's ecosystem. Spacelift is the pick if you orchestrate Pulumi, CloudFormation, Kubernetes, or Ansible alongside Terraform and want a CI/CD-shaped platform with deep policy hooks. Scalr is the pick if you're mostly Terraform and OpenTofu, want to keep the remote-backend CLI workflow, and would rather be billed per run than per resource or per worker. The rest of this post is the reasoning, dimension by dimension.

The three platforms at a glance

• Terraform Cloud (TFC): HashiCorp's own managed service: remote state, VCS-driven runs, a private module registry, and policy through Sentinel or OPA. Built around Terraform only.
• Spacelift: An orchestration platform for many IaC tools (Terraform, OpenTofu, Pulumi, CloudFormation, Kubernetes, Ansible, Terragrunt) with an OPA policy engine that reaches every phase of the workflow and a lot of customization.
• Scalr: A Terraform Automation and Collaboration (TACO) platform for Terraform and OpenTofu, with a hierarchical account, environment, and workspace model, OPA policy at pre-plan and post-plan, and the choice of any state backend.

Is Spacelift a drop-in replacement for Terraform Cloud, or a re-platforming?

A re-platforming. As of September 2026 Spacelift's docs tell you to "not specify any Terraform backend whatsoever", and that init "will keep failing until you remove it". Its migration tool, liftoff, turns Terraform Cloud organizations and projects into spaces and workspaces into stacks, and records teams, agent pools, policies, and run tasks as audit-only data. A drop-in keeps the cloud/remote backend, CLI, and API and moves state, variables, and workspaces.

Which bucket a platform sits in tells you what the migration is, not which product is better. Spacelift is the stronger pick if you also run Pulumi, CloudFormation, or Ansible, if you need a self-hosted or air-gapped control plane (Scalr's control plane is SaaS-only, with self-hosted agents that keep runs inside your network), or if you orchestrate dependency chains across stacks. If you're standardized on Terraform or OpenTofu and your pipelines call the Terraform CLI or API, a drop-in keeps them running. Scalr is that kind of platform, and a pure-play one, so a team running several IaC tools should still shortlist a multi-IaC platform.

Terraform Configuration: Beyond the Basics

Terraform configuration is HCL code that describes the infrastructure you want: providers, resources, input variables, and outputs. How a platform helps you manage that code affects how maintainable things stay as you scale.

All three platforms assist in managing Terraform configurations, but with different approaches:

• State Management: The Terraform state file is critical. TFC provides secure remote state storage and locking. Spacelift also offers a managed state backend with extra security features, or lets you use your own. Scalr is the most flexible here, letting you use its managed backend or any backend Terraform supports (like S3, Azure Blob, GCS), which is a huge plus for data residency or existing infrastructure.
• Modularity: Reusing code through modules is a Terraform best practice. All platforms support private module registries, allowing teams to share and version their custom modules.
• Variables: Parameterizing configurations with variables is essential. TFC uses variable sets. Spacelift uses "Contexts" and per-stack variables, with unique per-stage exposure options (ro_, wo_ prefixes) for enhanced security. Scalr employs a hierarchical variable system (Account > Environment > Workspace) with inheritance and override capabilities, including a "final" keyword to prevent changes at lower levels.

When you weigh terraform configuration management, look at how sensitive data is handled and how state is secured and accessed. How easily configs can be reused and standardized across teams matters too.

Terraform Cloud Workspaces: Organizing Your Infrastructure

Terraform Cloud uses Workspaces as the fundamental organizational unit. Each workspace encapsulates a specific Terraform configuration, its state file, variables, and its link to a Version Control System (VCS) repository. You might have workspaces for different environments (dev, staging, prod), different applications, or different infrastructure components (e.g., networking, Kubernetes cluster, database).

• Purpose: Workspaces help isolate state, manage access control, and trigger runs based on changes to specific parts of your infrastructure code.
• Grouping: TFC allows grouping workspaces into "Projects," primarily for access control and organizational clarity.
• Best Practices: Common advice includes scoping workspaces by component volatility and separating stateful from stateless resources to limit the potential impact of changes (blast radius).

TFC Workspaces are a solid foundation, but the structure can feel rigid once things get more complex or you're managing dependencies between many infrastructure components.

Spacelift Stacks: Flexible Orchestration Units

Spacelift introduces the concept of Stacks, which are analogous to TFC Workspaces but offer significantly broader functionality and flexibility.

• Multi-IaC Support: A single Spacelift Stack can manage not just Terraform, but also OpenTofu, Pulumi, CloudFormation, Kubernetes manifests, Ansible playbooks, and more. This is a major advantage for teams using a diverse toolset.
• Customization: Stacks allow for greater customization, including the use of private worker pools (even on-premises or air-gapped), custom runner images (Docker images), and administrative stack capabilities for managing Spacelift itself.
• Organizational Structure: Spacelift uses "Spaces" as logical containers for Stacks, Contexts (shared configurations), and Policies. This facilitates Role-Based Access Control (RBAC) and allows for delegating partial administrative rights.
• Dependencies: A powerful feature is Stack Dependencies. You can define a directed acyclic graph (DAG) of your infrastructure components, allowing outputs from one Stack to be used as inputs in another. This automates the orchestration of complex, multi-layered infrastructure.
• Blueprints: Spacelift offers Blueprints (YAML templates) to enable self-service infrastructure. Teams can define standardized templates for common infrastructure patterns, allowing developers to provision resources quickly within established guardrails.

Spacelift Stacks are built for more dynamic, complex environments. They give you more control and automation over the IaC lifecycle than the more traditional TFC Workspaces do.

That breadth is a real benefit if you run several IaC tools. It also shapes the product in ways a Terraform-only team should think about. Spacelift lets you pick among about six IaC vendors when you create a stack, and its policy model is vendor-namespaced to match. The Plan policy input carries a terraform field that is swapped for a pulumi field on Pulumi stacks, per Spacelift's docs, so reusable policy code branches per engine. Maturity also varies per engine: as of September 2026 Spacelift's Pulumi integration is a labeled feature preview, while its Terraform, OpenTofu, and Ansible support is first-class. This is the shape of a multi-IaC platform versus a pure-play Terraform and OpenTofu one, and it only matters if you stay on Terraform.

Environment Variables: Secure and Contextual Management

Securely managing environment variables and secrets (API keys, database passwords, etc.) matters a lot in any IaC setup. Leaked credentials can lead to catastrophic security breaches.

• Terraform Cloud: Uses "Variable Sets" that can be applied to multiple workspaces. Variables can be marked as "sensitive," which encrypts them at rest and makes them write-only in the UI. Standard Terraform environment variables (e.g., TF_VAR_name) are used to pass values.
• Spacelift: Offers fine-grained control through "Contexts" (reusable collections of environment variables, mounted files, and hooks) and per-Stack environment variables. Variables can be plain text or secret (encrypted at rest and in transit). A standout security feature is per-stage environment variable exposure using ro_ (read-only for plan/init) and wo_ (write-only for apply) prefixes. This limits credential exposure to only the necessary phases of a run, adhering to the principle of least privilege.
• Scalr: Provides multi-scope shell and Terraform variables within a clear hierarchy: Account > Environments > Workspaces. Variables set at higher scopes are inherited by lower scopes and can be overridden unless marked "final." Variables can be marked "sensitive," masking them in the UI, API, and logs. Values can be set in the UI or via .tfvars files (with .tfvars taking precedence unless a UI variable is "final").

Spacelift's per-stage exposure and Scalr's hierarchical model with "final" attributes give you more precise control over secrets than TFC's approach does. Both let you decide how and when sensitive values are accessible during a run.

Drift Detection: Keeping Your State and Reality Aligned

Drift detection is the process of identifying discrepancies between the desired state of your infrastructure (as defined in your Terraform configuration and state file) and its actual, real-world state. Unmanaged drift can lead to inconsistencies, security vulnerabilities, and unexpected behavior.

• Terraform Cloud: Detects drift by running terraform plan. When that plan shows changes you didn't write into code, you've got drift, and remediation is usually manual: a terraform apply brings the infrastructure back in line with the configuration. You can schedule automated plan runs via CI/CD to check for drift proactively, and health assessments can schedule these checks as well.
• Spacelift: Offers built-in, scheduled drift detection. It also provides optional automated remediation. Spacelift can be configured to automatically apply changes to correct detected drift, ensuring infrastructure integrity without manual intervention. Provides visibility into the drift status of resources.
• Scalr: Provides drift detection that can be enabled per environment with a configurable schedule. When drift is detected, workspace owners are notified (e.g., via Slack). Offers three resolution options: Ignore Drift: Acknowledge but take no action. Sync State: Run a refresh-only operation to update the Terraform state file to match reality. Revert Infrastructure: Initiate a plan and apply to roll back the drifted changes to match the configuration. Scalr's approach often anchors to Git as the source of truth, comparing the live environment (via terraform plan -refresh=true) against the committed code.

Spacelift and Scalr both go past detection and into remediation, automated or guided, which saves real operational work. Scalr's multiple resolution options and per-environment scheduling give you more ways to handle drift once it shows up.

CD Pipelines: Automating Your IaC Lifecycle

Continuous Delivery (CD) pipelines are how you automate testing and deploying your infrastructure code. Well-built CD pipelines for IaC keep things consistent, fast, and reliable.

• Terraform Cloud: Integrates with VCS (GitHub, GitLab, etc.) to automate Terraform runs (plan/apply) based on commits and pull requests. Supports CLI-driven and API-driven workflows. "Run Tasks" allow limited integration of third-party tools (like security scanners or cost estimators) into the run lifecycle at specific points.
• Spacelift: Is effectively a CI/CD platform specifically designed for IaC. It replaces the need for manually configured CI/CD pipelines for infrastructure with its automated Stacks. Offers native GitOps support, automatic IaC deployments for PRs, and self-service infrastructure provisioning via Blueprints. Provides extensive customization through: Lifecycle Hooks: Inject custom scripts/commands before and after various runner phases (e.g., before_init, after_plan, before_apply, after_apply). Custom Runner Images: Bring your own Docker image to have full control over the execution environment.
• Scalr: Supports GitOps workflows (merge-before-apply, apply-before-merge) and direct CLI execution. Custom Hooks: Allows injecting commands or scripts at various stages (pre-init, pre-plan, post-plan, pre-apply, post-apply). This makes it straightforward to integrate external tools like security scanners (e.g., Checkov before terraform init), linters, cost estimators (e.g., Infracost), or configuration management tools (e.g., Ansible post-apply). Run Triggers: Allows chaining workspace executions. A successful run in one workspace can automatically trigger a run in a dependent workspace.

TFC covers the basics of CI/CD for Terraform, but Spacelift and Scalr go further. Spacelift works as a CI/CD orchestrator across many IaC tools, while Scalr gives you deep customization inside the Terraform and OpenTofu workflow through its hook system and run triggers. Being able to inject custom logic at several points in the pipeline is what lets you wire security, compliance, and cost checks directly into the IaC lifecycle.

For instance, with Spacelift, you might have a .spacelift/config.yml defining:

version: "1"
stack_defaults:
  before_init:
    - tflint --recursive
  after_plan:
    - checkov -d . --framework terraform
    - infracost breakdown --path . --format table
  before_apply:
    - echo "Applying $(git rev-parse --short HEAD) to ${TF_VAR_environment}"

With Scalr, you could configure a pre-plan hook in the UI:

# pre-plan hook
tflint --recursive
checkov -d . --framework terraform --soft-fail

And a post-plan hook:

# post-plan hook: cost estimate against the plan Scalr just produced
terraform show -json tfplan.binary > plan.json
infracost breakdown --path plan.json --format table

These examples show how custom validation, security scanning, and cost analysis can become a built-in part of your automated IaC deployment process.

Terraform Cloud Alternative: Why and What to Consider

While Terraform Cloud is a natural starting point for many, several factors might lead you to search for a Terraform Cloud alternative:

• Pricing Model: TFC's Resource Under Management (RUM) pricing can become unpredictable and expensive as your infrastructure grows. Even small resources add to the RUM count, and they add up fast.
• IaC Tool Support: TFC is primarily for Terraform. If your organization uses or plans to use other IaC tools like Pulumi, CloudFormation, Ansible, or Kubernetes YAML directly, TFC won't provide a unified management plane.
• Workflow Customization: TFC's run lifecycle is relatively fixed. Teams needing more control to inject custom scripts, security tools, or complex approval workflows at various stages might find TFC restrictive.
• Policy Engine: While TFC supports Sentinel (proprietary) and OPA (typically post-plan), alternatives might offer more flexible or deeply integrated OPA capabilities across more stages of the workflow.
• State Backend Flexibility: TFC mandates using its own state backend. Organizations with existing backend infrastructure or specific data residency/compliance requirements for state files might need more options.
• Advanced Orchestration: Features like complex dependency management between infrastructure components, sophisticated inventory management, or advanced self-service capabilities might be more mature in alternative platforms.

What to Look for in an Alternative:

• Spacelift: Multi-IaC: Its biggest draw if you use more than Terraform. Concurrency-metered pricing: Flat invoice for the contract period, with the structural trade-offs discussed below. You pay for parallel run slots, not work performed. Deep OPA Integration: Policies for login, plan, approval, push, triggers, notifications. Full Workflow Control: Lifecycle hooks, custom runners. Advanced Features: Stack dependencies, Blueprints, inventory management.
• Scalr: Backend Flexibility: Use Scalr's or any Terraform-supported backend. Hierarchical Governance: Account > Environment > Workspace model for sharing and standards. Proactive OPA: Pre-plan and post-plan OPA checks, plus Checkov via custom hook. Transparent Pricing: Run-based model (many operational runs are free). Developer Experience: Detailed PR comments, apply-from-PR, global module registry. OpenTofu/Terragrunt Focus: Strong support for these tools.

Choosing an alternative involves weighing these factors against your specific pain points with TFC or your anticipated future needs.

Which platform fits which team?

Start from whichever driver dominates for you: multi-tool support, granular policy control, cost predictability, or backend flexibility. That answer usually points straight at the platform.

A Note on Concurrency-Based Pricing

Spacelift's pricing is concurrency-metered: plans are sized by private worker count, and because a worker "processes a single run at a time", Spacelift's own docs say "your number of workers is equal to your maximum concurrency" (as of September 2026). The bill scales with the parallel run slots you hold. It's tempting to call this "predictable" because the invoice is flat once the slot count is fixed. What stays predictable is the bill. The productivity impact doesn't, and the structural trade-offs are worth understanding before you commit.

You're always paying the wrong amount. Concurrency-based pricing sells a fixed number of parallel run slots. Buy too few and engineers queue during releases. Buy too many and you're renting idle slots. There is no setting that's right, only different flavors of wrong. Usage-based pricing, by contrast, has no dial to mis-set: the customer pays for runs that actually executed.

Capacity planning is offloaded to the buyer. The customer forecasts peak concurrency, watches utilization, and goes back to procurement to buy more slots as needs grow. That's work the vendor should be doing on its side. Since no forecast is perfect, the customer is left with either queueing (when slots are under-provisioned) or idle capacity (when over-provisioned).

It fails hardest exactly when you need it most. During an incident, parallel fixes across many workspaces queue behind the slot cap. New workers can be provisioned quickly, but additional slots must be purchased, so the bottleneck during recovery is procurement, run under pressure with the incident still active.

The price jumps are discontinuous. Needing one more concurrent run can push the customer into the next slot bracket and a much larger bill. Usage-based pricing scales smoothly, where one more run costs one more run.

None of this says concurrency-based pricing is uniformly worse than RUM-based or seat-based models. Each has its own failure modes. The point is narrower: "predictable" describes the invoice, not the productivity outcome. Usage-based, per-run pricing avoids these structural failure modes because what the customer pays tracks the work the platform actually performed. How to evaluate IaC platform pricing models walks through the trade-offs of each model across six evaluation dimensions.

For how Spacelift compares beyond Terraform Cloud, against Scalr, env0, and Atlantis, see our Spacelift alternatives comparison guide.

How to pick between the three

• Spacelift stands out for multi-IaC orchestration, OPA policy integration across the lifecycle, and its CI/CD-native design. It suits complex, mixed-tool environments that want a lot of programmatic control and workflow customization.
• Scalr leans on flexible state backend choices, a hierarchical model for enterprise-wide governance, pre-plan policy enforcement (with Checkov available via custom hook), and a bill that tracks activity rather than resource count. It's a good fit for organizations mostly on Terraform/OpenTofu that need structured control and want to keep operations efficient.

Weigh your IaC toolset, governance needs, scale, team maturity, and budget against what each platform does well. The right choice is the one that lets your team ship infrastructure safely without slowing down. Use the free tiers and trials to test that on your own workflows before you commit. Scalr offers free migration periods to some teams leaving Terraform Cloud. Ask when you talk to us.