What actually runs your infrastructure when you use SST

Every infrastructure tool is a bet about which layer you want to think in. Terraform bets you want to describe resources. CloudFormation bets you will accept AWS’s own vocabulary in exchange for AWS’s own guarantees. SST bets you would rather describe an application and let the resources follow.

What makes SST worth a closer look isn’t the bet. It’s what sits underneath it. In v3 the answer changed, and the new answer runs straight through Terraform.

The chain, stated plainly

SST v2 compiled your configuration into AWS CDK constructs, which compiled into a CloudFormation template, which AWS then executed. Three translations between what you wrote and what ran.

SST v3, which the project calls Ion, removed CDK and CloudFormation and put Pulumi in their place. Pulumi, in turn, doesn’t hand-write most of its providers. It generates them from Terraform providers through a bridge. Pulumi says so directly: SST “leverages Pulumi behind the scenes for its providers and deployment engine while also bridging Terraform providers through Pulumi.”

So when an sst.config.ts creates an S3 bucket, the schema it’s validated against traces back to the same Terraform AWS provider you would use writing HCL by hand. Not a similar one. The same one, wrapped.

This is the part that matters if you have Terraform experience, and the part almost nobody says out loud: your knowledge transfers. Argument names, defaults, the awkward corners of a resource that you learned the hard way. They survive the move because the provider survived the move.

What SST actually buys you

Three things, worth naming precisely because the marketing blurs them together.

• One config for infrastructure and application. A single sst.config.ts defines the bucket, the function that reads from it, and the frontend that calls the function. In Terraform you describe the bucket and the function; wiring the application to them is a separate problem you solve with variables, outputs and a deployment script.
• Breadth without new syntax. SST’s documentation puts provider support at over 150, spanning AWS, Azure and GCP but also Cloudflare, Stripe, Vercel and Auth0. That number is a direct consequence of the bridge. SST didn’t write 150 integrations. It inherited an ecosystem.
• No CloudFormation. The stated reasons for leaving were the AWS-centric nature of CDK and CloudFormation, and that the intermediary template “often obscured the underlying logic and made it much more difficult to diagnose and resolve problems”. Anyone who has read a CloudFormation rollback message recognises the complaint. The template you debug isn’t the code you wrote.

What you give up

Choose a tool for what it costs you, not only for what it saves you.

An extra abstraction on the critical path. You gained a layer over Terraform providers, so when something breaks you debug in three vocabularies: SST components, Pulumi resources, and the provider underneath. The CloudFormation opacity SST was built to escape hasn’t disappeared so much as moved.

State becomes yours to reason about again. CloudFormation kept state on AWS’s side, which was limiting and also one fewer thing to lose. Pulumi-based state is a file you’re responsible for, with the locking and backup questions that follow. Anyone who has run Terraform at scale has already had the argument about remote state, and I’ve written about what it costs when a team never has it: one state file holding everything is the anti-pattern that eventually takes the site down.

A smaller hiring pool. Terraform and HCL are a labour market. SST is a smaller one. That isn’t an argument against it, but it’s an argument for writing down why you chose it.

Where the line falls

The useful question isn’t which tool is better. It’s which layer your team wants to be responsible for.

If your infrastructure exists to serve one application, and the people writing that application are the people deploying it, SST removes a translation step that was never earning its keep. The single config isn’t a convenience, it’s a correctness property: the function and the bucket it reads can’t drift apart, because they’re declared together.

If your infrastructure serves many applications, or a platform team hands environments to product teams, that same coupling works against you. You want the bucket to have a life independent of whoever consumes it. Terraform’s separation of resource from consumer is the point, not an inconvenience to be abstracted away.

The chain matters either way. When an SST deployment fails on an argument you have never heard of, the answer is in the Terraform provider documentation, three layers down. That’s a strange thing for a tool to inherit, and a genuinely good one.

Next

The short version:

• SST v3 runs on Pulumi, and Pulumi generates its providers from Terraform’s. The schema you validate against is the same one either way.
• Terraform experience transfers. Argument names, defaults and the awkward corners survive the move, because the provider does.
• You trade CloudFormation’s opacity for a third vocabulary to debug in, and the state file becomes yours to keep again.
• One application and one team: SST removes a translation step. Many consumers behind a platform team: keep the resource independent of whoever uses it.

The question I haven’t settled is what happens to the single-config argument once a second team needs the same bucket. That’s the point where this stops being about syntax and starts being about ownership, and it’s the part no comparison table will answer for you.