// the take
SST is an infrastructure-as-code framework for building full-stack apps on AWS (and to a lesser extent Cloudflare) without hand-rolling Terraform or raw CDK. It targets teams who want their app code and infrastructure defined together in TypeScript and deployed through a single CLI, with first-class support for Next.js, Remix, Astro, and similar frameworks.
The 'Live' dev mode is the standout feature: your Lambda handlers run locally against real, deployed infrastructure (API Gateway, queues, etc.) instead of the slow deploy-to-test loop most serverless tooling forces on you. Resource Linking removes a real pain point — you get typed access to a bucket, queue, or table from app code without manually wiring env vars and IAM policies by hand. The CLI itself is a Go binary (post-v2 rewrite, dropped the old CDK/Node-based engine), which makes it noticeably faster and easier to distribute than the old JS-based tooling. The component model sits on top of Pulumi rather than being a thin CDK wrapper, which is why it can target both AWS and Cloudflare from the same abstraction.
The v2-to-v3 rewrite (CDK to Pulumi/Ion) was a full breaking change with no automated migration path — anyone still on an older SST app is looking at a rewrite, not an upgrade. State management is the usual Pulumi-style risk: a corrupted or drifted state file can leave your stack in a bad spot, and recovery is a manual, stressful process, not something the tool guards against. Despite the multi-cloud framing, AWS is clearly the primary, most battle-tested target; Cloudflare support is newer and thinner, and other providers aren't realistically supported. The abstraction is also fairly sticky — once your app is expressed as sst.config.ts components, dropping back to raw Pulumi, Terraform, or CDK means re-deriving the underlying resource graph by hand, since there's no clean export path out.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →