Terraform Cloud Pricing Revealed

Terraform Cloud (TFC) has been the de facto standard for managing Terraform workflows, but three significant market shifts have prompted organizations to reevaluate:

1. The RUM Pricing Model Crisis: Resources Under Management (RUM) based pricing creates unpredictable costs that scale with infrastructure growth, often dramatically increasing bills during peak periods.
2. The BSL License Change: HashiCorp's August 2023 switch from Mozilla Public License (MPL 2.0) to Business Source License (BSL) raised concerns about vendor lock-in and the future of open-source Terraform development.
3. Drastic Price Increases.

These factors, combined with a maturing market, have created a compelling landscape of alternatives. This guide provides a comprehensive evaluation of leading contenders including Spacelift, Scalr, env0, and emerging open-source options.

Key Takeaway

Scalr stands out as the most direct Terraform Cloud replacement, offering:

• Drop-in replacement compatibility (both remote operations backend)
• Predictable run-based pricing
• Native OpenTofu support
• Enterprise-grade security features
• Superior cost efficiency at scale

The IaC Management Landscape

Market Context

The Infrastructure as Code management market (often referred to as "TACO" - Terraform Automation and Collaboration Orchestration) has matured significantly since Terraform Cloud's launch. Key drivers for platform evaluation include:

• Scalability Concerns: As infrastructure scales, per-resource pricing models become increasingly expensive
• Open-Source Commitment: Organizations prefer tools that support both Terraform and OpenTofu
• Cost Predictability: Run-based or environment-based pricing provides better forecasting than resource-based models
• Operational Visibility: Need for dashboards, metrics, and reporting to manage infrastructure at scale
• Security & Compliance: Advanced RBAC, policy-as-code, and audit logging requirements

Platform Categories

The market divides into several categories:

Terraform-Specific Platforms (optimized for Terraform/OpenTofu):

• Terraform Cloud
• Scalr (only other remote operations backend)

Multi-Tool Platforms (support Terraform, OpenTofu, Pulumi, etc.):

• Spacelift
• env0
• Terrateam

General CI/CD with IaC Support:

• GitHub Actions
• GitLab CI
• Jenkins

Open-Source Self-Hosted:

• Atlantis
• Digger
• OpenTofu itself

Platform Overview & Differentiators

Terraform Cloud

Overview: HashiCorp's purpose-built platform for Terraform automation. Now owned by IBM following the acquisition in October 2024.

Architecture: Fully managed SaaS with cloud-based state management and execution.

Ideal For: Teams with straightforward Terraform workflows and moderate resource counts. Organizations already invested in HashiCorp's ecosystem.

Differentiators:

• First-mover advantage and industry standard
• Deep integration with other HashiCorp products (Sentinel, Vault, Consul)
• Managed state with automatic locking
• Strong VCS integration

Known Limitations:

• RUM pricing becomes prohibitively expensive at scale
• Only 3 concurrent runs on Standard tier (often a major bottleneck)
• Only one backend option (TFC backend)
• Limited RBAC (role restrictions hamper team onboarding)
• No native OpenTofu support
• No Terragrunt support
• Limited observability and reporting

Scalr

Overview: Purpose-built as a direct Terraform Cloud alternative with focus on enterprise needs, backend flexibility, and predictable costs.

Architecture: Hybrid SaaS (managed control plane + self-hosted agents). SaaS control plane manages UI, workspace management, and policies. Agents execute runs in your infrastructure.

Ideal For: Enterprise teams, organizations with complex governance needs, teams managing multiple environments, managed service providers requiring multi-tenancy.

Key Differentiators:

1. Backend Sovereignty: Only other remote operations backend besides TFC. Supports ANY backend Terraform supports (S3, Azure Blob, GCS, etc.) with state stored in your environment.
2. OpenTofu & Terragrunt Native Support: Full first-class support for both tools. Scalr is a founding member of the OpenTofu project.
3. Hierarchical Organization Model:
   • Account scope (with shared credentials, modules, policies)
   • Environment scope (similar to TFC organization/project)
   • Workspace scope
   • Enables reuse and scaling without duplication
4. Advanced Observability:
   • Metrics dashboard showing plan/apply durations, slowest workspaces
   • Resource tracking with drill-down capabilities
   • Module and provider usage analytics
   • Workspace staleness detection
   • API token lifecycle management
5. Enterprise RBAC: 120+ granular permissions vs. TFC's limited system roles. Create custom roles following least privilege principle.
6. Operational Excellence:
   • PR comments with plan details and failure logs
   • Execute runs from PR comments
   • Run dashboards across entire account
   • Module registry with namespace-level management
7. Advanced Security:
   • Checkov integration for code scanning
   • OIDC authentication (GitHub, GitLab, AWS, Azure)
   • SCIM protocol for automated user lifecycle
   • VCS Agents (keep code internal, not internet-exposed)
   • Pre and post-plan OPA policy checks
   • OPA impact analysis before merging policies
8. Integrations:
   • AWS EventBridge for event-driven pipelines
   • Slack/Teams with approval capabilities
   • Datadog for monitoring
   • Native Terragrunt support with run-all command
9. Predictable Pricing: Only charges per qualifying run (no per-resource or per-user fees). Drift runs are free.

Spacelift

Overview: Treats IaC as a CI/CD problem, offering tool-agnostic support for multiple IaC frameworks with powerful policy and workflow capabilities.

Architecture: SaaS-based with optional self-hosted workers for internal code execution.

Ideal For: Organizations using multiple IaC tools (Terraform, OpenTofu, Pulumi, Ansible, CloudFormation), teams with complex policy requirements, enterprises prioritizing GitOps workflows.

Key Differentiators:

• Multi-Tool Support: Terraform, OpenTofu, Pulumi, Ansible, CloudFormation, and more
• OPA Policy Engine: Native Open Policy Agent integration with drift detection
• Stack Dependency Management: Define relationships between stacks for orchestrated deployments
• GitOps-First: Pull request driven workflows (does not support Terraform CLI or No-Code provisioning)
• Custom Workflow Integration: Highly flexible CI/CD-style pipeline capabilities
• AI Diagnostics: Saturnhead AI analyzes failures and suggests fixes
• Concurrency-Based Pricing: Pay for concurrent workers (predictable but may require multiple worker purchases)

Limitations:

• More complex to set up and manage than Terraform Cloud
• Steeper learning curve for teams new to CI/CD thinking
• Less suitable for pure Terraform shops focused on simplicity
• Limited drift detection compared to Terraform-specific platforms
• Higher operational overhead due to flexibility

env0

Overview: Focuses on FinOps, developer self-service, and cost visibility alongside IaC automation.

Ideal For: Organizations with strong cost-control requirements, teams needing developer templates and self-service capabilities, enterprises with FinOps teams.

Key Differentiators:

• FinOps Focus: Cost estimation in PR comments, real-time cost tracking
• Developer Self-Service: Template-based infrastructure provisioning for non-experts
• Cost Visibility: Estimated vs. actual infrastructure costs
• Multi-Tool Support: Terraform, OpenTofu, Pulumi, CloudFormation, Ansible
• Unlimited Concurrent Runs: All paid plans allow unlimited parallelism
• Guardrails: Platform teams create templates with built-in constraints
• Policy as Code: OPA policy support with custom integrations

Limitations:

• Pricing model can be complex (per-environment plus additional factors)
• Smaller ecosystem and community than Spacelift or Scalr
• Less suitable for teams without strong FinOps focus

OpenTofu

Overview: Linux Foundation-governed, open-source fork of Terraform (pre-BSL version). Community-driven, truly open alternative.

Ideal For: Organizations prioritizing open-source principles, teams wanting long-term vendor independence, projects requiring permissive licensing.

Key Points:

• Drop-in replacement for Terraform < v1.6
• All major platforms (Spacelift, Scalr, env0) support OpenTofu natively
• Actively developed by diverse community including major IaC vendors
• No commercial lock-in concerns
• Identical HCL syntax to Terraform

Limitations:

• Requires separate management platform (unlike TFC which provides end-to-end solution)
• Smaller ecosystem of third-party integrations than Terraform
• Community-driven roadmap vs. company-driven priorities

Feature Comparison Matrix

Pricing & Cost Analysis

Pricing Model Comparison

Terraform Cloud: Resources Under Management (RUM)

Pricing Structure:

• Free: Up to 500 resources
• Standard: $0.00014 per resource-hour (minimum $29/month for teams)
• Plus: Quote-based
• Business: Quote-based

Cost Behavior:

• Costs scale with infrastructure size, not usage
• Difficult to forecast (costs for test/dev resources count equally)
• State file size also increases costs
• No visibility into final bill until scaled

Real-World Example:

• 1,000 resources: ~$140/month
• 5,000 resources: ~$700/month
• 10,000 resources: ~$1,400/month

Concurrency Costs:

• Free: 1 concurrent run
• Standard: 3 concurrent runs ($29/month minimum)
• Plus: 10 concurrent runs (~$3,000-5,000/month estimated)

Scalr: Pay-Per-Run (Predictable)

Pricing Structure:

• Free: 50 qualifying runs/month (unlimited stacks, users, features)
• Pro: Set number of runs/month (e.g., 500 runs for $X)

What's Included:

• All features in both tiers
• No per-user fees
• No per-resource fees
• Free drift detection runs
• Unlimited concurrent runs with self-hosted agents

Cost Behavior:

• Highly predictable (pay only for actual runs)
• Scales linearly with usage
• Excluded from billing: drift runs, policy-failed runs, failed init runs

Self-Hosted Agents:

• 25 agents included free
• Unlimited additional agents at no platform cost
• Each agent can handle 5 concurrent runs independently

Real-World Example (assuming 500 runs/month):

• Free tier: $0 (up to 50 runs)
• Pro tier: $X for 500 runs

Spacelift: Concurrency-Based

Pricing Structure:

• Free: 2 users, 1 concurrent run
• Cloud: Starts at $250/month
• Pricing increases with concurrent workers needed

Cost Behavior:

• Predictable based on concurrency requirements
• Unlimited users and stacks once on paid plan
• Multi-team/multi-stack scenarios scale linearly with worker count

env0: Environment-Based

Pricing Structure:

• Trial available
• Pro: Quote-based per active environment
• Charged per active environment, unlimited runs within tier

Cost Behavior:

• Predictable based on number of environments
• Scales better than RUM for large projects
• Suitable for organizations with defined environment structure

Cost Comparison Scenarios

Scenario 1: Small Team (100 resources, 20 runs/month)

• Terraform Cloud Standard: ~$40/month
• Scalr: Free tier (~0 for 20 qualifying runs)
• Spacelift: ~$250/month
• Winner: Scalr Free

Scenario 2: Growing Team (1,000 resources, 200 runs/month)

• Terraform Cloud Standard: ~$140/month + worker costs (~$300 additional)
• Scalr Pro (500 runs): Estimated $150-300/month
• Spacelift (1-2 workers): $250-500/month
• Winner: Scalr (predictable, lower cost)

Scenario 3: Enterprise (5,000 resources, 1,000+ runs/month)

• Terraform Cloud: ~$700/month + Plus tier (quote) + worker costs
• Scalr (2,000 runs/month): Estimated $500-800/month
• Spacelift (4-8 workers): $1,000-2,000+/month
• Winner: Scalr (70% cheaper than TFC Plus, significantly cheaper than Spacelift)

Total Cost of Ownership (TCO)

Beyond platform costs, consider:

1. Migration Costs:
   • Terraform Cloud → Scalr: Free migration period available, automated script provided
   • Terraform Cloud → Spacelift: Python migration script, no free period
   • DIY Solutions: Significant internal engineering time
2. Operational Costs:
   • Terraform Cloud: Managed (low ops)
   • Scalr: Low ops (agent management minimal)
   • Spacelift: Medium ops (worker/DB management)
   • Self-Hosted: High ops (infrastructure, maintenance)
3. Learning Curve:
   • Terraform Cloud: Low (if coming from TFC)
   • Scalr: Very Low (similar workflow)
   • Spacelift: Medium (CI/CD thinking required)
   • Self-Hosted: High (full ownership)

Developer Experience

Terraform Cloud Developer Experience

Strengths:

• Familiar interface for existing users
• Simple VCS integration
• Clear workflow (plan → approve → apply)

Weaknesses:

• Limited customization
• Approval process can be cumbersome
• API experience is basic
• CLI integration is functional but not seamless

Scalr Developer Experience

Strengths:

• Familiar Workflow: Nearly identical to Terraform Cloud for basic operations
• Enhanced PR Experience: Detailed plan summaries in PR comments, execute runs from comments
• Multi-Workspace Visibility: Run dashboard provides unified view across account
• CLI Integration: Seamless terraform CLI experience with Scalr backend
• No-Code Option: Stack-based provisioning through UI for novice users
• Module Registry: Simplified module management with namespace inheritance

UI/UX Advantages Over TFC:

• Intuitive account → environment → workspace hierarchy
• Breadcrumb navigation and drill-down capabilities
• Real-time run status streaming
• Better error presentation and troubleshooting context

Spacelift Developer Experience

Strengths:

• Powerful for Complex Workflows: Stack dependencies, custom integrations
• Multi-Tool Support: Single interface for all IaC tools
• CI/CD Integration: Flexible pipeline customization
• Modern UI: Well-designed interface with good UX

Weaknesses:

• Steeper Learning Curve: Requires CI/CD mindset
• Less Terraform-Specific: Features spread across tool support
• No Native CLI Workflow: Less suitable for Terraform CLI users
• More Complex Setup: More configuration required vs. TFC/Scalr

Summary: Developer Experience Winner

For pure Terraform shops: Scalr provides the most familiar experience with meaningful enhancements over Terraform Cloud, particularly around PR workflows and observability.

For multi-tool environments: Spacelift provides superior capabilities despite steeper learning curve.

Ecosystem & Integrations

VCS Integration

Terraform Cloud:

• GitHub, GitLab, Bitbucket, Azure DevOps
• Basic webhook support
• PR comments with plan summary

Scalr:

• All major VCS providers
• VCS Agents: Run code retrieval without exposing VCS to internet (major security win)
• Enhanced PR comments with full plan output
• Execute runs directly from PR comments
• Checks API integration

Spacelift:

• All major VCS providers
• Strong GitHub-first features
• Flexible comment-based workflows
• Stack dependency visualization

Monitoring & Observability Integrations

Terraform Cloud:

• Webhooks for custom integrations
• Limited built-in monitoring

Scalr:

• Datadog Integration: Native streaming of Terraform metrics
• AWS EventBridge: Event-driven pipelines (run failures, drift detection)
• Slack: Notifications + approvals (built-in)
• Microsoft Teams: Notifications + approvals (built-in)
• Webhooks: Custom integrations

Spacelift:

• Webhooks
• Slack notifications
• Custom integrations via API

IaC Tool Integrations

Terraform Cloud:

• Terraform only
• Recently added limited OpenTofu support

Scalr:

• Terraform: Native first-class support
• OpenTofu: Native first-class support (founding member)
• Terragrunt: Native support with run-all command
• No CloudFormation, Pulumi, Ansible support

Spacelift:

• Terraform/OpenTofu
• Pulumi
• CloudFormation
• Ansible
• Custom tools via containers

Policy & Governance Integrations

Terraform Cloud:

• Sentinel: HashiCorp's policy language (not OPA)
• Recently added Open Policy Agent support

Scalr:

• OPA (Open Policy Agent): Native integration
• Pre-plan + post-plan checks
• Policy impact analysis before merge
• Built-in Checkov integration

Spacelift:

• OPA: Native integration
• Powerful policy engine
• Stack dependencies for orchestration

Credentials & Cloud Provider Integrations

All Platforms Support:

• AWS, Azure, GCP OIDC authentication
• Traditional API key management

Scalr Advantages:

• Provider credentials at account/environment scope (reusable)
• Storage profiles for state file placement
• Per-environment flexibility

Security & Compliance

Authentication & Access Control

Terraform Cloud:

• SAML/SSO support
• Team-based access
• Limited system roles

Scalr:

• SAML/SSO support
• SCIM Protocol: Automated user provisioning/deprovisioning (enterprise best practice)
• 120+ Granular Permissions: Custom roles following least privilege
• OIDC: API authentication without static tokens
• Team-based Hierarchies: Account, environment, workspace scopes

Spacelift:

• SAML/SSO support
• RBAC with custom roles
• Team-based access

Data Protection

Terraform Cloud:

• State stored in managed SaaS backend
• End-to-end encryption
• Limited options for state location

Scalr:

• Flexible State Storage: Choose any backend (S3, Azure, GCS, etc.)
• Storage Profiles: Per-environment state location choice
• Hybrid Architecture: Control plane managed SaaS, agents run in your infrastructure
• Credentials Never Leave Agents: Cloud credentials injected only to agents
• VCS Agents: Internal code retrieval without internet exposure

Spacelift:

• Cloud-based state management
• Self-hosted workers for internal execution
• Credentials managed securely

Audit & Compliance

Terraform Cloud:

• Basic audit logging
• Activity history
• Limited compliance features

Scalr:

• Comprehensive Audit Logs: User actions, policy changes, runs
• Drift Detection Reporting: Track infrastructure compliance
• Token Lifecycle Management: Identify unused/unrotated tokens
• Resource Deletion Tracking: Audit deleted resources
• Compliance Dashboards: Role-based reporting

Spacelift:

• Audit logging
• Activity tracking
• Compliance reporting

Code Security

Terraform Cloud:

• No built-in scanning
• Sentinel policy checks

Scalr:

• Checkov Integration: Native vulnerability scanning
• Prevents runs if vulnerabilities detected
• OPA policy enforcement

Spacelift:

• OPA policy integration
• Custom security policies
• Flexible workflow enforcement

Self-Hosted & Alternative Options

Self-Hosted Option: Scalr Hybrid Architecture

How It Works:

• SaaS control plane (managed by Scalr)
• Self-hosted agents (run in your infrastructure)
• Agents pull code from VCS and execute runs
• Credentials stay within your network

Benefits:

• Full endpoint security
• Control over execution environment
• Compliance-friendly (data sovereignty)
• Network isolation possible (private agents)
• No internet exposure of code or credentials

Trade-offs:

• Minimal operational overhead (just agent management)
• Small infrastructure footprint required

Open-Source Self-Hosted Options

Atlantis

What It Is: Original open-source Terraform automation tool. Listens for pull request comments, runs plan/apply.

Strengths:

• Simple to understand and deploy
• One binary to manage
• Free and open-source
• GitOps workflow

Weaknesses:

• Single-threaded execution (concurrency bottleneck)
• Security bottleneck (all credentials on one server)
• Limited drift detection
• Stagnant development
• No policy enforcement beyond Sentinel

Best For: Small teams, proof-of-concepts, learning.

Migration Path: Atlantis users often outgrow it within 1-2 years.

Digger

What It Is: New-generation orchestrator that bridges Atlantis limitations. Listens for PR comments, triggers jobs in your CI/CD system.

How It Works:

• Lightweight orchestrator (stateless)
• Triggers jobs in GitHub Actions / GitLab CI
• Credentials stay in CI environment
• Scales with your CI platform

Strengths:

• Security by design (no credentials on central server)
• Scales automatically (inherits CI/CD scalability)
• Lower maintenance
• Open-source

Weaknesses:

• Smaller ecosystem than Spacelift/Scalr
• Requires CI/CD platform
• Limited advanced features

Best For: Teams that love their CI/CD, want security, and need GitOps workflows.

Terrateam

What It Is: Enterprise-focused evolution of the orchestrator pattern. Server orchestrates CI jobs.

How It Works:

• More robust server architecture (Postgres-backed)
• Better scalability than Digger
• Horizontally scalable
• Job orchestration in CI runners

Strengths:

• Enterprise features (HA, RBAC)
• Multi-tool support (Terraform, Pulumi, Terragrunt)
• Better scalability than Digger

Weaknesses:

• More complex setup (requires database)
• Higher operational cost
• Less mature community

Best For: Large platform teams managing many projects.

Comparison: Open-Source vs. Managed Platforms

GitHub Actions as an Alternative

The Allure & Reality of DIY GitHub Actions

Why Teams Consider It:

• "We already use GitHub Actions for CI/CD"
• "Can't we just add Terraform tasks?"
• "Let's avoid another SaaS subscription"

The Simple Version (what it looks like initially):

name: Terraform Plan
on:
  pull_request:
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - name: Configure AWS
        uses: aws-actions/configure-aws-credentials@v4
      - name: Terraform Plan
        run: terraform init && terraform plan -no-color

Why This Becomes a Maintenance Nightmare

Complexity Compounding:

1. First Release: "Plan looks simple"
2. Week 1: Need to post plan output to PR comments
3. Week 2: Multiple environments, variable files, different AWS accounts
4. Week 3: Complex approval workflows, status checks
5. Month 2: State management, state locking, concurrency handling
6. Month 3: Policy enforcement, cost estimation, drift detection
7. Month 6+: Rewrite in progress (realized you're building TFC from scratch)

Specific Problems:

• State Locking: Manually implemented with S3 + DynamoDB (complex, error-prone)
• Plan Artifacts: Storing plan files across jobs (GitHub Actions limitations)
• Approval Workflows: GitHub branch protection + manual approvals = friction
• Error Handling: Plan failures, apply rollbacks (all DIY)
• Concurrency: Multiple runs stepping on each other (race conditions)
• Secrets Management: Rotating AWS credentials securely
• Logging: Accessing logs across jobs and runs
• YAML Duplication: Copy-paste across workflows (maintenance hell)

Verdict on GitHub Actions

Don't Use DIY GitHub Actions Unless:

• Extremely simple, single-team, single-environment setup
• You want to learn Terraform and GitHub Actions
• You have the engineering resources to maintain this long-term

Better Use of GitHub Actions:

• Pair with Digger or Terrateam for orchestration
• Let the tool handle complexity, GitHub Actions handles execution
• Best of both worlds: CI/CD flexibility + specialized tool features

Cost Comparison:

• GitHub Actions alone: Free (within free minutes), expensive at scale
• Digger + Actions: Free orchestration + Actions cost
• Terrateam + Actions: Small fee + Actions cost
• Dedicated Platform (Scalr/Spacelift): Flat fee, better experience

Migration Guide

Before You Start

Prepare Assessment:

• Count total workspaces
• Calculate monthly run volume
• Document current variable usage
• List all VCS integrations
• Review current policies (Sentinel or OPA)
• Document approval workflows

Cost Analysis:

• Calculate TFC current spend (number of resources × duration = resource-hours)
• Project costs on alternative platforms
• Include migration timeline in savings calculation

Scalr Migration: Step-by-Step

Scalr is the easiest migration path for TFC users (both are remote operations backends).

Phase 1: Setup (1-2 days)

1. Create Scalr account
2. Connect VCS providers
3. Configure AWS/cloud credentials
4. (Optional) Request free migration period

Phase 2: Automated Migration (1-2 days)

1. Use Scalr's TFC migration script
2. Script migrates:
   • Organizations → Environments
   • Workspaces → Workspaces
   • Workspace variables → Variables
   • State files → State
3. Validates migration success
4. Run test applies on non-critical workspaces

Phase 3: Testing (3-7 days)

1. Run drift detection on migrated workspaces
2. Execute applies on development workspaces
3. Verify PR workflows
4. Test approval chains
5. Validate policies (migrate Sentinel → OPA if needed)

Phase 4: Cutover (1 day)

1. Migrate critical workspaces during maintenance window
2. Monitor runs closely
3. Have rollback plan (state push back to TFC if needed)

Phase 5: Cleanup (ongoing)

1. Cancel TFC subscription
2. Archive old TFC workspaces (for reference)
3. Remove TFC credentials from CI/CD
4. Update team documentation

Migration Effort Estimate:

• Small team (1-10 workspaces): 1-2 days
• Medium team (10-100 workspaces): 1-2 weeks
• Large enterprise (100+ workspaces): 2-4 weeks

Spacelift Migration: Step-by-Step

Spacelift requires more configuration due to stack-based thinking.

Phase 1: Planning (3-5 days)

1. Design stack hierarchy (dependency mapping)
2. Plan policy rules (convert Sentinel → OPA)
3. Configure workers (if using self-hosted)
4. Finalize environment structure

Phase 2: Automated Migration (1-2 days)

1. Use Spacelift's Python migration script
2. Migrates workspaces → stacks
3. Migrates variables
4. Migrates state files

Phase 3: Stack Configuration (1-2 weeks)

1. Define stack dependencies
2. Configure policy rules
3. Test custom integrations
4. Optimize worker allocation

Phase 4: Testing & Validation (1-2 weeks)

1. Run on non-critical stacks
2. Validate policy enforcement
3. Test complex workflows
4. Optimize performance

Phase 5: Cutover & Training (1 week)

1. Migrate production stacks
2. Monitor heavily
3. Train teams on new workflows
4. Update documentation

Migration Effort Estimate:

• Small team: 2-3 weeks
• Medium team: 4-8 weeks
• Large enterprise: 2-3 months

Key Migration Considerations

State Transfer Safety:

• All platforms support terraform state pull/push
• Minimize downtime (state locked during transfer)
• Verify state integrity after migration
• Keep backup state file for 30 days

Policy Migration:

• Terraform Cloud uses Sentinel (HashiCorp language)
• Scalr/Spacelift use OPA (industry standard)
• Not a 1:1 translation; plan for rewrite
• Both platforms have examples
• Policy impact analysis available in Scalr

VCS Integration:

• Reconnect each VCS provider (may require new OAuth tokens)
• Update webhook URLs
• Test PR automation thoroughly
• Verify branch protection rules work

Team Training:

• Scalr has low learning curve (similar to TFC)
• Spacelift requires more training (CI/CD thinking)
• Plan for 1-2 hour training sessions
• Provide reference documentation

Decision Framework

Decision Tree

START: Evaluating Terraform Cloud Alternative

1. How many IaC tools do you use?
   ├─ Just Terraform/OpenTofu
   │  └─→ Go to Q2
   ├─ Multiple (Pulumi, CloudFormation, Ansible, etc.)
   │  └─→ Spacelift is likely best choice
   └─ Mix with strong cost focus
      └─→ env0 if FinOps critical, otherwise Spacelift

2. (Terraform/OpenTofu only) What's your primary pain point?
   ├─ COST (RUM pricing killing us)
   │  └─→ Scalr (60-80% savings typical)
   ├─ CONCURRENCY (3 runs max is suffocating)
   │  └─→ Scalr (unlimited with agents) or env0 (unlimited on all plans)
   ├─ FLEXIBILITY (want to manage own state/backend)
   │  └─→ Scalr (only option with any backend)
   ├─ SECURITY (data residency, internal network required)
   │  └─→ Scalr (hybrid SaaS with agents in your environment)
   └─ OPERATIONAL VISIBILITY (need dashboards, metrics, reporting)
      └─→ Scalr (best-in-class observability)

3. Do you want to manage infrastructure yourself?
   ├─ No, give me managed (SaaS)
   │  └─→ Scalr SaaS or Spacelift
   ├─ Yes, we want full control
   │  ├─ We use GitHub/GitLab heavily
   │  │  └─→ Digger (lightweight) or Terrateam (full-featured)
   │  └─ We don't have CI/CD yet
   │     └─→ Atlantis (small team) or self-host option
   └─ Hybrid (managed control plane, self-hosted execution)
      └─→ Scalr (agents in your infra)

4. What's your team size & maturity?
   ├─ Small (1-5 people)
   │  └─→ Scalr free tier (50 runs/month) or Atlantis
   ├─ Growing (5-20 people)
   │  ├─ Simple setup → Scalr (most cost-effective)
   │  ├─ Complex policies → Spacelift
   │  └─ GitOps purist → Digger
   └─ Enterprise (20+ people)
      ├─ Terraform-only → Scalr (scalability, cost, features)
      ├─ Multi-tool → Spacelift
      └─ High-security needs → Scalr (hybrid) or self-hosted

FINAL RECOMMENDATIONS:

→ FOR MOST TEAMS: Scalr
  Why: Drop-in replacement, best pricing, easiest migration,
       superior observability, includes all features in free tier

→ FOR MULTI-TOOL TEAMS: Spacelift
  Why: Best multi-tool support, powerful policies, 
       ultimate flexibility

→ FOR FINOPS-FOCUSED TEAMS: env0
  Why: Cost visibility, developer templates, budget control

→ FOR SECURITY-PARANOID TEAMS: Scalr (hybrid) or self-hosted
  Why: Credentials never leave your infrastructure

→ FOR OPEN-SOURCE PURISTS: Digger + GitHub Actions
  Why: Fully open-source, no vendor lock-in, 
       secure by design

Selection Matrix by Use Case

FAQ

Migration & Compatibility

Q: How difficult is it to migrate from Terraform Cloud to Scalr?

A: Very straightforward. Scalr is a drop-in replacement (both remote operations backends). The automated migration script handles Organizations → Environments, Workspaces → Workspaces, Variables → Variables, and State Files. Most teams complete migration in 1-2 weeks. Scalr offers free migration periods to avoid double-billing.

Q: Can I keep using the Terraform CLI with Scalr?

A: Yes. Scalr is a remote operations backend (like Terraform Cloud), so you can continue using terraform plan and terraform apply from the CLI. This is a major advantage over Spacelift, which requires using their UI/API.

Q: What about my existing Sentinel policies?

A: Sentinel is HashiCorp-specific. Scalr and Spacelift use Open Policy Agent (OPA), an industry-standard, language-agnostic policy engine. Policies need to be rewritten, but OPA is more powerful and flexible. Migration tools and examples are available.

Pricing & Costs

Q: Will Scalr be cheaper than Terraform Cloud for our 5,000 resource setup?

A: Almost certainly. Terraform Cloud with 5,000 resources costs ~$700/month minimum. Scalr's per-run model is typically 60-80% cheaper for similar usage. You'd need roughly 500-1,000 runs/month to spend $300-500, and that includes all features. Cost calculator available on Scalr's website.

Q: Do we have to pay for drift detection runs?

A: No. Scalr's drift detection runs don't count against your run quota. Neither do runs stopped by policies, failed init runs, or internal Scalr errors.

Q: What's included in the Free tier?

A: All features. You're limited to 50 qualifying runs/month but get unlimited users, workspaces, teams, and features. Team features like RBAC, policies, all integrations—everything is included.

Features & Capabilities

Q: Does Scalr support OpenTofu?

A: Yes, natively. Scalr is a founding member of the OpenTofu project and contributed significant resources to its creation. You can use Terraform < 1.6, Terraform 1.5.7 through latest OpenTofu without any differences.

Q: Can Scalr manage state in my own S3 bucket?

A: Yes. Scalr supports using any backend Terraform supports (S3, Azure Blob Storage, GCS, HTTP, etc.). State is stored in your backend while the run executes in Scalr. This is unique—Terraform Cloud only uses its own backend.

Q: Does Spacelift support Terraform CLI workflows?

A: No. Spacelift is UI/API driven. If your team relies on terraform apply from the CLI, this is a significant workflow change. For Terraform-only shops, this is a major disadvantage compared to Scalr.

Security & Compliance

Q: Where does our code and credentials stay with Scalr?

A: Code stays in your VCS (GitHub, GitLab, etc.). Credentials are injected into Scalr agents only at runtime—they never touch Scalr's SaaS control plane. Using VCS Agents, even code retrieval can happen without exposing your VCS to the internet.

Q: Does Scalr support SCIM for user provisioning?

A: Yes. SCIM protocol automatically adds/removes users based on your identity provider (Okta, Azure AD, etc.). This is an enterprise best practice and prevents orphaned accounts.

Q: Can we run agents inside our VPC for extra security?

A: Yes. Scalr's self-hosted agents can run in your infrastructure (AWS, Azure, GCP, on-premises). The control plane is SaaS, but all execution happens in your environment.

Operational Questions

Q: How long does a typical migration from TFC to Scalr take?

A: For most organizations, 1-2 weeks of actual work spread over a month:

• Week 1: Setup and automated migration (1-2 days work)
• Week 2-3: Testing and validation (3-5 days work)
• Week 4: Cutover and monitoring (1 day work) Exact timeline depends on team size and workspace count.

Q: Do we need to change our Terraform code to use Scalr?

A: No. Scalr uses the same terraform command and accepts the same HCL code. Zero changes required to your codebase. The backend configuration changes (add Scalr backend config), but that's managed by the migration script.

Q: What if we want to leave Scalr later? Can we easily migrate away?

A: Yes. Since Scalr is a remote operations backend (standard Terraform), you can migrate back to Terraform Cloud, Terraform Enterprise, or any other backend using standard Terraform state commands (terraform state pull/push).

Alternatives Comparison

Q: When would we choose Spacelift over Scalr?

A: When you need:

• Multi-tool support (Pulumi, CloudFormation, Ansible alongside Terraform)
• CI/CD-style flexibility
• Strong policy-based workflow orchestration The trade-off: more complexity, steeper learning curve, higher cost

Q: Is GitHub Actions a viable alternative to a dedicated platform?

A: For a very small, simple setup (one person, one environment), maybe. But teams typically hit complexity walls within weeks:

• State locking becomes complex
• Plan/apply coordination across jobs is fragile
• Policy enforcement is DIY
• Error handling is manual Once you reach 2-3 people or 2+ environments, a dedicated platform (Scalr, Spacelift, Digger) is worth the investment.

Q: What about Atlantis?

A: Great for getting started and learning, but scalability becomes the issue:

• Single-threaded execution (queues up easily)
• Credentials on central server (security risk at scale)
• Limited features (no drift, limited policy) Teams typically outgrow Atlantis within 1-2 years.

Technical Deep Dives

Q: How does Scalr's hierarchical model work?

A: Three scopes:

• Account: Organization-wide settings, shared credentials, modules, policies
• Environment: Project/team scope, similar to TFC organization, inherit account settings
• Workspace: Individual infrastructure project, inherit environment settings This enables massive reuse (credentials, modules, policies) at higher scopes while maintaining flexibility at workspace level.

Q: What's the difference between Scalr's pre-plan and post-plan OPA checks?

A: Pre-plan checks run before the plan executes. You can reject runs based on source, author, branch, etc. This prevents running plans in the first place. Post-plan checks run after plan and can enforce what changes are allowed (based on resources, costs, etc.). Both together provide comprehensive policy coverage.

Q: How does VCS Agents improve security?

A: Normally, the management platform needs access to your VCS provider (GitHub, GitLab). VCS Agents run inside your network and handle code retrieval. Your VCS stays on your network, never exposed to the internet. This is critical for organizations with strict network policies.

Recommended Next Steps

For Terraform Cloud Users

1. Week 1: Assess your needs using the decision framework above
2. Week 2: Request Scalr demo and free trial
3. Week 3: Conduct proof-of-concept on non-critical workspaces
4. Week 4: Build business case (cost savings analysis)
5. Month 2: Plan migration with your team

For Teams Considering Self-Hosted

1. Evaluate true operational cost (hosting + management time)
2. Assess security gains vs. additional complexity
3. Consider hybrid approach (managed control plane + self-hosted agents)
4. Scalr hybrid model offers best of both

For Multi-Tool Teams

1. Evaluate Spacelift vs. env0 based on primary use cases
2. Design stack/project hierarchy
3. Plan policy enforcement strategy
4. Allocate time for team training (more complex than Terraform Cloud)

Additional Resources

• Scalr Documentation: https://docs.scalr.com/
• Spacelift Documentation: https://docs.spacelift.io/
• env0 Documentation: https://env0.com/docs
• OpenTofu Project: https://opentofu.org/
• Terraform State Management: https://www.terraform.io/docs/language/state/
• Open Policy Agent: https://www.openpolicyagent.org/

This comprehensive guide was compiled from real-world platform comparisons, customer feedback, and technical analysis as of February 2026. Pricing and features are subject to change. Always verify current information with official vendor documentation.