Stack vs Terraform

TL;DR

Terraform is HashiCorp's battle-tested IaC tool: you write HCL that describes cloud primitives, and Terraform reconciles your described state against the cloud. It has the largest provider ecosystem in the industry (3,000+ providers on the registry), mature state management, and is the default choice for anything touching AWS, GCP, or Azure. Stack provisions the other half of modern infrastructure — the third-party SaaS services (Supabase, Stripe, Clerk, Vercel, PostHog, Sentry, and 23 more) — via their Management APIs, with OAuth, secrets routed through Phantom, and MCP-native automation. Stack is not a Terraform replacement. It's what you reach for when Terraform's provider coverage runs out.

When to pick each

Pick Terraform when	Pick Stack when
You own AWS/GCP/Azure accounts and need VPCs, IAM, RDS, Lambda, CloudFront, GKE.	You rent SaaS: Supabase, Stripe, Clerk, Vercel, PostHog, Resend.
Multi-region, multi-account, remote state, workspaces, policy-as-code (Sentinel / OPA).	You want stack add stripe to create the account, capture webhooks, and write the key to an encrypted vault.
Regulated industry with audit trails and drift detection at the cloud-primitive layer.	You are shipping a SaaS and want the third-party glue done in minutes rather than days.

The quickest decision heuristic: if the thing you're provisioning lives in the AWS, GCP, or Azure console, Terraform is the right tool. If it lives in the Supabase, Stripe, or Clerk dashboard, Stack is the right tool.

At-a-glance

Capability	Stack	Terraform
Category	SaaS control plane	Cloud IaC
Primary surface	CLI + MCP server + Claude Code plugin	CLI (HCL DSL); Terraform Cloud / Enterprise for collaboration
Language	Declarative TOML (.stack.toml)	HCL (HashiCorp Configuration Language)
What it provisions	Supabase, Vercel, Stripe, Clerk, PostHog, Sentry, GitHub, Resend, Neon, Fly.io, Railway, and 18 more	AWS, GCP, Azure, Kubernetes, Cloudflare, 3,000+ providers
State management	Shape-file only (.stack.toml); Phantom holds values; no server	Local or remote state file; locking via backend (S3 + DynamoDB, Terraform Cloud, etc.)
Secrets	E2E-encrypted via Phantom; never on disk in plaintext	Variables marked sensitive; state file contains plaintext secrets unless encrypted at rest
AI surface	Native stack recommend + 19 MCP tools + Claude Code plugin	HashiCorp AI in Terraform Cloud (preview); no native MCP
License	MIT · pre-alpha v0.1.1	BSL 1.1 (since 2023); OpenTofu is the Apache 2.0 fork
Free tier	Entire CLI, MCP, plugin — free forever	CLI free; Terraform Cloud free for up to 5 users
Best for	SaaS composition, indie devs, YC startups, agentic workflows	Platform engineering, SRE, regulated cloud deployments

Where they overlap

The overlap is real but narrow. Terraform's provider registry includes community-maintained wrappers for a handful of SaaS products — there's a supabase/supabase provider, a stripe/stripe provider, a cloudflare/cloudflare provider that's actually first-class. In theory you can write HCL that creates a Stripe product, a Supabase branch, a Clerk application. In practice the ergonomics are wrong: you're spinning up a state backend, writing 80 lines of HCL, and importing plaintext secrets — all to do what stack add stripe does in one command with encrypted secrets by default.

The honest cases where Terraform's SaaS providers are the right answer: you already have Terraform in production, your platform team owns all provisioning, and the SaaS resources need to live in the same state graph as your cloud resources.

Where Stack wins

• End-to-end SaaS provisioning. stack add supabase drives the OAuth flow, calls the Supabase Management API to create a project, waits for it to come online, extracts the service-role key and anon key, writes them to Phantom, and regenerates .env.local with phm_* tokens. Terraform's Supabase provider requires you to already have a project and a PAT before HCL can do anything.
• Secrets-safe by default. Stack never writes plaintext secrets to disk. Terraform's state file contains secrets in plaintext unless you configure encryption at rest. In day-to-day use this difference is huge — an accidentally committed terraform.tfstate has leaked AWS keys many times; a committed .stack.toml contains slot names only.
• MCP-native. Stack's 19 MCP tools let an agent drive the entire lifecycle — recommend, apply, doctor, rotate, remove — from a Claude Code session. Terraform has no first-class MCP surface; you'd have to wrap the CLI yourself.
• Zero state server. No Terraform Cloud, no S3 backend, no DynamoDB lock table. .stack.toml gets checked in; Phantom holds the values. For a solo dev or a small team, that eliminates a whole category of operational overhead.
• OAuth onboarding. Stack handles provider OAuth — you click Authorise in a browser and Stack takes it from there. Terraform expects you to have created long-lived tokens in each provider's dashboard before terraform apply runs.

Where Terraform wins

Honest concessions:

• Cloud primitives. Stack does not create VPCs, subnets, security groups, IAM roles, RDS instances, GKE clusters, or Azure Function Apps. If you own cloud infrastructure, Terraform is the standard and Stack is not a replacement.
• Provider ecosystem. Terraform has 3,000+ providers on the registry, covering every major cloud, database, monitoring tool, DNS provider, VPN, and identity system. Stack ships 29 curated providers.
• State and drift detection. terraform plan compares desired to actual state across thousands of resources; Stack only checks the presence and validity of declared SaaS services via stack doctor.
• Enterprise controls. Terraform Cloud has SOC2, SAML SSO, audit logs, policy-as-code via Sentinel, team RBAC, and private registries. Stack is pre-alpha; team-tier features are on the roadmap.
• Multi-env and workspaces. Terraform has first-class support for dev/staging/prod environments with shared modules. Stack v0.1 is single-environment-per-project.

Can I use both?

Yes, and it's the most common pattern for teams with any serious cloud footprint. Terraform owns the cloud account — VPCs, IAM, RDS, ECS, CloudFront — and Stack owns the SaaS layer: Supabase for data, Stripe for billing, Clerk for auth, PostHog for analytics, Sentry for errors. Hand-offs happen via environment variables: Terraform outputs feed into Stack config, and Stack-managed Phantom secrets can be injected into Terraform runs via phantom exec -- terraform apply.

If you're on OpenTofu (the Apache 2.0 fork of Terraform), the same pattern works — Stack doesn't care which CLI you use for the cloud side.

Migration and caveats

Stack is pre-alpha — these comparisons reflect v0.1.1 as of April 2026. We do not claim parity with Terraform's maturity, provider breadth, or enterprise tooling. If you already have a working Terraform monorepo, don't rip it out; add Stack for the SaaS services you're currently hand-wiring. For the provider catalog, see /docs/providers. For agentic automation via MCP, see /docs/mcp.

FAQ

Can Stack replace Terraform?

Not for cloud infrastructure. Terraform remains the industry standard for provisioning AWS, GCP, Azure, and on-prem resources with a huge provider ecosystem and mature state management. Stack replaces the hand-written glue around SaaS services — Supabase, Stripe, Clerk — where Terraform providers are thin or non-existent.

Does Terraform have a Supabase or Stripe provider?

There is a community Supabase provider with limited coverage and a Stripe provider that mostly wraps the API surface. Neither handles OAuth onboarding, project creation, secret extraction, or vault routing the way Stack does end-to-end. Stack treats these providers as first-class SaaS citizens, not API wrappers.

Which should a two-person startup pick?

If you deploy to Vercel, Fly, or Railway and rent the rest (Supabase, Stripe, Clerk, PostHog), Stack alone covers 90 percent of your setup. If you run on AWS primitives — EC2, RDS, VPCs — you need Terraform for infra and can add Stack for the SaaS layer on top.