Friday Night Wiki
TopicsAbout
Buy me a coffee
Terraform Tutorial

Ecosystem: Terragrunt, Atlantis, OpenTofu, and Friends

This chapter surveys the tools built on top of Terraform, when each earns its keep, and how to think about the OpenTofu fork.

The Shape of the Ecosystem

Terraform's community is huge. Tools fall into a few categories:

  • Wrappers: run Terraform for you, adding features. Terragrunt, tofu (OpenTofu).
  • PR automation: run plan/apply from PRs. Atlantis, Spacelift, Env0, Scalr.
  • Orchestration: manage many Terraform stacks across a monorepo. Terramate, Digger.
  • Cost: estimate spend changes from a plan. Infracost.
  • Security scanners: tfsec, Checkov, KICS (covered in Chapter 10).
  • Module registries: public (registry.terraform.io), private (HCP, Artifactory, Spacelift).

This chapter covers the ones you'll hear about. None are mandatory; all solve real problems.

Terragrunt

A thin wrapper by Gruntwork that removes the duplication that Terraform's directory-per-env pattern creates.

Without Terragrunt, each environment directory has its own backend block, provider config, and module call. A lot of copy-paste.

With Terragrunt:

infra/
├── terragrunt.hcl              # root config, shared settings
├── dev/
│   └── terragrunt.hcl          # dev-specific
├── staging/
│   └── terragrunt.hcl
└── prod/
    └── terragrunt.hcl

Root terragrunt.hcl:

remote_state {
  backend = "s3"
  config = {
    bucket         = "my-company-tfstate"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "tf-locks"
  }
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite"
  contents  = <<EOF
provider "aws" {
  region = "us-east-1"
}
EOF
}

Per-env terragrunt.hcl:

include "root" {
  path = find_in_parent_folders()
}

terraform {
  source = "git::https://github.com/your-org/modules.git//platform?ref=v1.2.0"
}

inputs = {
  environment   = "prod"
  instance_type = "m5.large"
}

Run:

cd prod
terragrunt apply

Terragrunt generates the provider and backend, downloads the module, passes the inputs, runs Terraform.

When to Use Terragrunt

  • Multiple environments with repetitive config.
  • A fleet of small Terraform "projects" (per-team, per-service).
  • You want strict module versioning enforced at every call site.

When Not To

  • Single environment, simple setup. Native Terraform is fine.
  • Team unfamiliar with Terragrunt. Adds a learning curve.
  • HCP Terraform does most of what Terragrunt does, differently.

Atlantis

Open-source PR automation. Self-hosted. Runs Terraform in response to GitHub/GitLab/Bitbucket webhooks.

Workflow:

  1. Open a PR.
  2. Atlantis posts a plan comment automatically.
  3. Reviewers read the plan.
  4. Someone comments atlantis apply.
  5. Atlantis applies and reports back.

Benefits:

  • Self-hosted (your servers, your credentials).
  • Works with any git hosting.
  • Free.

Costs:

  • You run the server. Scaling, upgrades, monitoring are yours.
  • Configuration can be complex for multi-repo setups.

A good choice for teams with a strong DevOps function and a preference for self-hosting.

Hosted PR Automation: Spacelift, Env0, Scalr

Hosted alternatives to Atlantis. Think "GitHub Actions, but specialized for Terraform".

  • Spacelift: powerful, granular. Supports Terraform, Pulumi, Ansible.
  • Env0: dev-friendly, good UI, strong CI/CD.
  • Scalr: Terraform-focused, emphasis on governance.

All offer: PR automation, drift detection, policy-as-code, cost estimates, team/project RBAC, audit logs.

Trade-off: price and vendor lock-in for ops burden. For larger teams, the math often works out in favor of hosted.

HCP Terraform (HashiCorp's own hosted product) is in this category too. The main difference: HCP is the first-party option, which may matter for enterprise support, or may not.

OpenTofu

The community fork of Terraform, created in September 2023 after HashiCorp changed Terraform's license to BSL (non-OSI). Backed by the Linux Foundation.

Why It Exists

HashiCorp's license change restricted commercial use of Terraform by competitors. The community wanted true open source back. OpenTofu forked Terraform 1.5 and continued development under MPL 2.0.

What's Different

As of OpenTofu 1.6+, very little. Configurations are compatible. The CLI is tofu instead of terraform. Providers, modules, and state formats are all the same.

OpenTofu has shipped a few features ahead of Terraform (notably state encryption), and they broadly try to maintain compatibility.

Which to Pick

Use OpenTofu if:

  • You want genuinely open-source infrastructure tooling.
  • You're building a platform product that would be restricted by Terraform's BSL.
  • You want community governance over corporate governance.

Use Terraform if:

  • You're already on HCP Terraform and happy there.
  • Your team or org has standardized on Terraform.
  • You want HashiCorp's commercial support.

For individual learning, either works. Most examples in this tutorial run unmodified on both.

Migration

From Terraform to OpenTofu: install OpenTofu, run tofu init in an existing Terraform project. Done.

From OpenTofu to Terraform: similar, but watch for features OpenTofu added that Terraform doesn't have yet.

Terramate

A newer tool for orchestrating many Terraform stacks.

If you have a monorepo with dozens of Terraform configs (one per service, one per environment, one per team), you need orchestration: which stacks changed, which depend on which, in what order do I apply.

Terramate handles this via its own HCL-based config plus a CLI that understands stack graphs.

Niche but growing. Worth knowing if you're at monorepo scale.

Infracost

Estimates the cost impact of a Terraform plan.

infracost breakdown --path .

Project: notes

Name                                         Monthly Qty  Unit          Monthly Cost
aws_instance.web
├─ Linux/UNIX usage (on-demand, m5.large)             730  hours         $70.08
└─ root_block_device
   └─ General Purpose SSD (gp3)                        30  GB-months      $2.40

OVERALL TOTAL                                                           $72.48

PR integration posts estimates as comments. A good nudge against "I'll just throw m5.24xlarge at it".

tfsec and Checkov

Covered in Chapter 10. Both are widely used; both are worth having in CI.

Picking Tools

A decision tree:

  1. Do you have 1-3 engineers? Skip most of this. Native Terraform plus GitHub Actions plus tfsec is plenty.
  2. Do you have 5-20 engineers with a DevOps focus? Add Atlantis (self-hosted) or Spacelift (hosted). Consider Terragrunt.
  3. Do you have 50+ engineers and multiple teams doing IaC? HCP Terraform or a Spacelift-style platform is justified. Terragrunt helps with multi-env. Terramate if you have dozens of stacks.
  4. Are you cost-sensitive? Infracost in every PR.

Don't adopt a tool because it's popular. Adopt it because you have the problem it solves.

The Tool You Shouldn't Rush Into

Every team at some point writes a custom shell script wrapper around Terraform. It starts small and grows. Eventually it reimplements Terragrunt, poorly.

If you feel the need, try the off-the-shelf tool first. Your wrapper ends up unmaintained the moment you leave the team.

Common Pitfalls

Adopting too many tools at once. Pick one or two. Live with them. Add more when you hit actual limits.

Terragrunt on a single environment. Adds complexity without benefit. Use when you have multi-env duplication.

OpenTofu versus Terraform wars. Both work. Pick one. Don't waste a week arguing.

Building internal IaC platforms. Unless you are a huge org, you don't need a platform. You need a CI template and a wiki page.

Paying for tools you haven't stressed native Terraform with. HCP Terraform is great; so is the free tier of GitHub Actions for most small teams. Start simple, upgrade when you hit pain.

Next Steps

Continue to 12-best-practices.md for the conventions that keep a codebase healthy.