Terraform at scale: GitOps tools and the long apply problem

If you’ve been using Terraform Cloud for a while, you’ve probably hit at least one of these: the pricing model changed and suddenly it’s expensive, applies take 10+ minutes, or the state files have grown into something nobody wants to touch. You’re not alone — this is a recurring topic in every DevOps community right now.

This post covers the main tools people are using to solve these problems in 2025–2026, with a focus on two separate issues that often get conflated: GitOps orchestration (who triggers plans, who approves applies) and state management at scale (why applies are slow and what to do about it).

The two problems

1. GitOps orchestration

The question here is: how does infrastructure change flow from a PR to production? Terraform Cloud gives you a UI, remote runs, and policy checks. When you leave it, you need something to replace that workflow.

2. Long applies

A plan or apply that takes 10 minutes is usually not about Terraform being slow — it’s about dependency chains. If you have dozens of Lambda functions each depending on IAM roles depending on VPC resources, Terraform has to walk that entire graph on every run, even for changes that touch one function. Splitting the state helps, but it doesn’t always solve it.

GitOps orchestration tools

Atlantis

The classic self-hosted option. Watches your PRs, runs plan on open and apply on merge (or a comment). Free, open source, runs anywhere.

Works well for small teams. Gets painful at scale — no native dependency ordering between stacks, no web approval UI, no drift detection. You end up writing a lot of wrapper logic yourself.

1
2
3
4
5
6
7
8

# atlantis.yaml
version: 3
projects:
  - name: vpc
    dir: infra/vpc
  - name: eks
    dir: infra/eks
    depends_on: [vpc]

Digger

Open source, CI-native — runs Terraform inside your existing GitHub Actions or GitLab CI rather than running its own compute. That means you keep your secrets, your runners, your audit logs.

Good fit if you already have CI infrastructure and just want PR-driven plans and applies without moving to a SaaS platform.

1
2
3
4
5

# .github/workflows/digger.yml
- uses: diggerhq/digger@v0.5.0
  with:
    setup-aws: true
    aws-role-to-assume: arn:aws:iam::ACCOUNT:role/digger

Terrateam

Similar idea to Digger — GitHub-native, PR-driven. Runs as a GitHub App, no separate servers. Decent for teams already living in GitHub who want minimal setup.

Terragrunt + Terragrunt Scale

If you’re already using Terragrunt, the Scale add-on gives you orchestrated CI/CD with dependency-aware runs. Stack ordering is handled automatically based on your dependency blocks.

Good choice if you’ve already invested in Terragrunt’s module structure. Not worth adopting Terragrunt just for the CI features.

Spacelift

The most full-featured option in this category. Treats infrastructure like CI/CD with proper pipelines, supports Terraform, OpenTofu, Pulumi, Ansible, and more. Built-in policy engine using OPA. Solid audit logs.

Teams who compared Scalr and Spacelift in 2025 generally preferred Spacelift — Scalr got feedback for feeling underdeveloped. Audit features in Spacelift are available without requiring the highest tier.

Worth looking at if you’re moving off Terraform Cloud and want a like-for-like replacement with more features rather than a DIY setup.

Scalr

A Terraform Cloud drop-in replacement with compatible CLI and API. Predictable pricing (not per-resource). Has AI troubleshooting built in. More affordable for large teams than Terraform Cloud’s RUM pricing.

The tradeoff: audit logs are gated behind higher tiers, and the feature set lags Spacelift in some areas. Still a reasonable choice if cost predictability is the priority and you don’t need enterprise-level audit/policy features.

env0

Focuses on developer self-service and FinOps — shows estimated cost impact directly in PRs, unlimited concurrent runs on paid plans. Good if your biggest pain point is teams spinning up expensive resources without visibility into cost.

The long apply problem

Splitting state is the obvious answer, and it works. Smaller states mean fewer resources Terraform has to reconcile on each run. The downside: you now manage more state files and more workspaces, and cross-stack dependencies become explicit data sources or hardcoded values.

There’s a newer approach worth knowing about.

Stategraph

Stategraph converts your Terraform JSON state into a directed graph stored in PostgreSQL. During plan/apply it only processes resources with explicit dependencies on what changed — not the entire state.

The result: applies that used to take 10 minutes because of Lambda→IAM→VPC dependency chains can drop significantly, because Stategraph only walks the relevant parts of the graph.

It also lets you query your infrastructure via SQL:

1

SELECT count(*) FROM resources WHERE type = 'aws_s3_bucket';

And it has a web-based approval board instead of CI job comments — useful if you want non-engineers to approve infrastructure changes.

Importantly: it can export back to standard Terraform state format, so if you try it and don’t like it, you can return to regular state files without losing anything.

Still early-stage and worth monitoring rather than immediately adopting for production, but the approach to the dependency problem is genuinely novel.

Building your own orchestrator

Some teams go DIY. The Terraflow approach uses git diff to detect which stacks changed, builds a dependency tree from it via static analysis, and triggers runs in the right order using GitHub Actions labels — for example a apply-prod label that gates behind code owner approval and multiple PR reviews. Works well for monorepos with Terragrunt.

The downside is obvious: you own the code and the bugs. Fine if you have the capacity, but Digger or Terragrunt Scale will get you most of the same benefits without the maintenance.

GitOps orchestration — comparison

State management at scale — comparison

For most teams leaving Terraform Cloud: if you want to stay self-sufficient, Digger or Atlantis with split states covers 80% of use cases. If you want a managed platform with proper policy and audit, Spacelift is the current community recommendation over Scalr. If your apply times are the primary pain and splitting state hasn’t solved it, Stategraph is worth a demo.