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 connects supported SaaS services through provider-specific setup, with secrets routed through Phantom and MCP tooling. 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 verify and store an existing restricted key in Phantom.
Regulated industry with audit trails and drift detection at the cloud-primitive layer.	You want to compose supported SaaS services with explicit provider authorization.

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	Provider-specific setup for Supabase, Vercel, Stripe, Clerk, PostHog, Sentry, GitHub, Resend, Neon, Fly.io, Railway, and others	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	Credential values routed through Phantom; .stack.toml records slot names	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 handling credentials — while stack add stripe can verify and store an existing restricted key through Phantom.

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

• Provider-specific SaaS setup. stack add supabase uses OAuth or a supplied PAT, calls the Supabase Management API to create a project, fetches available service-role and anon keys, stores credentials in Phantom, records slot names in .stack.toml, and merges its MCP entry into .mcp.json. App environment configuration is a separate step.
• Credential references in config. Stack routes provider credential values through Phantom and records slot names in .stack.toml. Treat Terraform state as sensitive and secure its backend and access controls separately; Stack does not attest to what other tools write to disk or logs.
• MCP-native. Stack's 19 MCP tools let an agent drive the supported lifecycle — recommend, apply, doctor, 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 where supported. Some Stack adapters use browser authorization; others require an existing provider token. 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 39 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. phantom exec -- terraform apply delegates the Terraform command to Phantom; verify its environment and state handling separately.

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. Stack supports Supabase project creation and Phantom credential routing. Its Stripe adapter verifies and stores an existing restricted key; setup behavior varies by provider.

Which should a two-person startup pick?

If you deploy to Vercel, Fly, or Railway and rent the rest (Supabase, Stripe, Clerk, PostHog), Stack can help connect supported SaaS services. If you run on AWS primitives — EC2, RDS, VPCs — you need Terraform for infra and can add Stack for the SaaS layer on top.