SST vs Terraform: Which to Use for Serverless on AWS in 2026

Pick SST if you’re a TypeScript team shipping a serverless product on AWS and the speed of your development loop matters more than anything else. Pick Terraform if infrastructure is its own discipline on your team — multi-cloud, shared modules, explicit plans reviewed before anything changes. And know the twist before you start: SST v3 is built on Terraform’s own providers, so this is less a question of which engine than of which layer you want to work at.

The twist most comparisons miss

SST v2 was a layer over AWS CDK and CloudFormation. SST v3 (the “Ion” rewrite) dropped that entirely and rebuilt on the Pulumi engine with Terraform providers underneath. When SST creates a bucket or a Lambda function today, it’s exercising much of the same provider code a terraform apply would.

That makes “SST vs Terraform” a comparison of layers, not capabilities. Almost anything one can deploy, the other can. What you’re actually choosing is the authoring model, the daily workflow, who manages state, and whose stewardship you trust — and on those axes the two could hardly be more different.

What each one actually is

• Terraform is general-purpose infrastructure as code: declarative HCL, an explicit plan → apply workflow, and the broadest provider ecosystem in the industry. It has no opinion about what you’re building — a Kubernetes cluster, a Datadog dashboard, and a Lambda function are all just resources.
• SST is a framework for building serverless applications in TypeScript. Its components encode opinions — a Function, an API, a Next.js site are a few lines each — and it ships app-developer features Terraform doesn’t try to have: typed resource linking and a live local development mode.

Language and authoring

Terraform’s HCL is declarative and deliberately not a general-purpose language. That constraint is a feature: configs are easy to read, diffs are legible in review, and a surprising side effect can’t hide in a for-loop. The cost shows up in serverless specifically — a single Lambda behind an API means a function resource, an IAM role, policy attachments, and API Gateway wiring, written out by hand or pulled from community modules. Serverless is where HCL is at its most verbose.

SST is the opposite trade. Components collapse that boilerplate to a few lines of real TypeScript, and resource linking passes one resource to another as a typed reference your editor can check — closer to application code than to configuration. The price is the one every high-level abstraction charges: when your needs diverge from a component’s opinions, you drop down to the raw Pulumi/Terraform resources beneath it, and the few-lines elegance goes with you.

The daily loop — where SST runs away with it

This is the biggest practical difference, and it isn’t close. sst dev runs your Lambda code locally against your real deployed AWS resources — save a file and the next invocation runs your new code in milliseconds, with real IAM, real queues, real data. For someone building an application, that loop feels like frontend development.

Terraform has nothing equivalent, because it isn’t trying to: changing a Lambda means rebuilding the artifact, then plan and apply. As a cadence for reviewing infrastructure changes, that explicitness is exactly right. As an inner loop for iterating on application code, it’s painful — which tells you what each tool is actually for.

State: both make you think about it

Neither tool uses CloudFormation — both deploy via direct API calls and track what they created in their own state, which means neither leaves the AWS-native, browsable record a CloudFormation stack does (a trade-off we dig into in the three-way comparison).

The difference is ceremony. With Terraform, you choose and operate the backend — typically S3 with locking, or a managed service like HCP Terraform — and state discipline is part of team life. SST handles it for you: bootstrapping creates a bucket in your own AWS account and state management is automatic. Less to set up, but it’s the same fundamental model — when a deploy wedges, you’re still un-sticking state (SST ships an unlock command for a reason).

Ecosystem and multi-cloud

Here Terraform is simply in a different weight class. Thousands of providers, a registry full of battle-tested modules, policy-as-code tooling, and the largest hiring pool in infrastructure. If your graph spans AWS plus Cloudflare plus Datadog plus GitHub, Terraform treats all of it as one system. SST can technically reach other providers through its engine, but its components, documentation, and community are concentrated on AWS application patterns — that focus is precisely what makes it productive, and what bounds it.

Stewardship — who’s steering each project

Infrastructure code is a multi-year commitment, so it’s worth looking past the feature matrix. As of this writing: HashiCorp relicensed Terraform under the Business Source License in 2023 — prompting the community’s OpenTofu fork under the Linux Foundation — and has since been acquired by IBM. Terraform remains heavily maintained, but its licensing and governance are more complicated than they were, and “Terraform or OpenTofu?” is now a real question. SST, meanwhile, is open source with a small core team whose attention has substantially shifted to a separate product (opencode, an AI coding agent). Neither story is disqualifying; both belong in the decision.

When Terraform is the right choice

• Multi-cloud or multi-provider graphs — anything beyond AWS in the same deployment is Terraform’s home turf.
• A platform team owns infrastructure — shared modules, review-gated plans, and policy checks are the workflow Terraform was built for.
• Compliance and auditability of changes — an explicit, reviewable plan before every apply is a genuine control, not overhead.
• You’re standardizing across many teams — the ecosystem, docs, and hiring pool make Terraform the safe organizational default.

When SST is the right choice

• A TypeScript product team on AWS — the same developers own the app and its infrastructure, in one language.
• Iteration speed dominates — sst dev’s live loop is worth more to a small team shipping features than any other line in this comparison.
• Your app is shaped like SST’s components — a Next.js/Remix/SvelteKit frontend plus functions, queues, and cron jobs maps one-to-one onto what SST makes easy.

The option this head-to-head skips

If you read the SST column nodding — single cloud, TypeScript end to end — but the stewardship section gave you pause, there’s a third path this matchup ignores: AWS CDK. It’s first-party, typed TypeScript like SST, and instead of a state file it deploys through CloudFormation, so AWS itself holds the record of every resource. It gives up Terraform’s multi-cloud breadth and SST’s live dev loop, and in exchange you get the strongest longevity story an AWS-only team can buy. The full three-way trade-off — including AI-agent ergonomics, which increasingly favors typed first-party tooling — is in AWS CDK vs Terraform vs SST.

The bottom line

SST and Terraform aren’t really competing — they’re different layers wearing the same “IaC” label, and SST literally runs on Terraform’s providers. Terraform is an infrastructure discipline tool: explicit, ecosystem-rich, organization-shaped. SST is a product velocity tool: opinionated, AWS-shaped, with the best development loop in serverless. Choose by which job you’re hiring for. And if your job is “a serverless SaaS on AWS, built to last, with an AI agent in the loop,” that’s the brief that led us to CDK instead — it’s the foundation of cdkbase and the stack it deploys.