We are a Serverless Framework consultancy, so you might expect this comparison to end with "use the Serverless Framework." It does not, always. The V4 licensing change and V3's end of life have pushed a large number of teams to re-evaluate, and we have migrated clients to each of the alternatives below. Here is how we actually compare them in 2026, and the questions we ask to pick one.
The three (and a half) contenders
Serverless Framework V4. YAML-first, AWS-only since V4, deploys through CloudFormation. Maintained by Serverless, Inc.; free under $2M annual revenue, paid per Service Instance above it. Built-in esbuild bundling and serverless dev. The V3 line is unmaintained; the community fork oss-serverless (osls) keeps V3 alive as the "half."
SST v3 ("Ion"). TypeScript-first, with a live-reload local development loop that is the best in the category. Since v3 (2024) SST no longer uses CloudFormation or CDK; it deploys through Pulumi and Terraform providers, which means multi-cloud resources (Cloudflare, Vercel, Stripe) in the same program. It is free and open source. The active-development pace slowed noticeably through late 2025 and into 2026 as the core team's attention moved to other products, which is the main risk we now flag to clients.
AWS CDK v2. TypeScript (or Python, Java, Go, C#) that synthesizes CloudFormation. Maintained by AWS, free, with the broadest construct library and first-party support for every AWS service. No opinion about "serverless" specifically; you assemble APIs, functions, and tables from constructs, with NodejsFunction handling esbuild bundling.
Terraform / OpenTofu. HCL, provider-based, state-file workflow, multi-cloud. Not serverless-specialized; packaging Lambda code and wiring API Gateway routes is verbose without a module. The right answer when a platform team already runs everything else through it.
Comparison by the things that matter
Deployment engine and blast radius
Serverless Framework and CDK both produce CloudFormation. That is slow (stack updates take minutes) but it gives you drift detection, automatic rollback, and the ability to import existing resources, and many enterprises have governance built around CloudFormation stacks. SST v3 and Terraform use their own state; deploys are faster and partial failures leave partial state that you reconcile with the tool. Neither model is wrong; your operations team will have a strong preference.
Local development
SST v3's sst dev is the benchmark: it runs your functions locally against real deployed resources, with live reload, in seconds. Serverless Framework V4's serverless dev now offers a comparable experience for Lambda. CDK has sam local and hot-swap deploys (cdk deploy --hotswap), which are workable but clunkier. Terraform has no equivalent; you deploy or you mock.
Type safety and reuse
CDK and SST are real TypeScript: you get types on every property, you can write loops and abstractions, and you can publish reusable constructs to an internal registry. The Serverless Framework's serverless.ts gives you types for the configuration schema but not the same compositional power. Terraform modules are reusable but HCL's type system is limited.
Ecosystem and longevity
- CDK: AWS's own; the safest bet on being maintained in five years.
- Terraform/OpenTofu: enormous ecosystem; OpenTofu resolved the 2023 license worry for teams who care about that.
- Serverless Framework: fifteen years of plugins, many now stale. V4 is maintained but by one vendor with a commercial model that changed once and could change again.
- SST: a smaller community and a single sponsor; the 2026 slowdown is the concern.
Cost of the tool itself
Only Serverless Framework V4 charges above the revenue threshold. Everything else is free; you pay in engineering time.
Migration cost from Serverless Framework V3
- To V4: a day to a week per service. See the upgrade tutorial.
- To CDK: moderate. Because both use CloudFormation, you can import the existing stack's resources into a CDK stack with
cdk import, preserving tables, buckets, and function names. Expect a week or two per service of rewriting configuration as constructs. - To SST v3 or Terraform: higher. Resources must be imported into a new state backend, and API Gateway definitions are rebuilt. Plan a blue/green cutover with DNS.
What we recommend, by situation
You are under the $2M threshold and productive with the framework. Stay and upgrade to V4. Nothing else is cheaper.
You are over the threshold, mostly Node/TypeScript, and you want something that will outlast this decade's tooling churn. AWS CDK. It is the most boring, best-supported choice, and the CloudFormation lineage makes the migration safer than any other destination.
Your platform team runs Terraform for everything and expects you to as well. Terraform/OpenTofu, with a well-built internal module for Lambda + API Gateway so application teams are not hand-wiring permissions. Accept the weaker local development story.
You are a small, fast-moving TypeScript team that values developer experience above all and can tolerate maintainer risk. SST v3. Go in with eyes open about the pace of development, pin versions, and have an exit plan (the Pulumi state underneath is portable, which helps).
You are on V3, over the threshold, and have not decided. oss-serverless for up to a year as a bridge, with a dated decision point. Do not let the bridge become the destination.
Questions we ask clients before choosing
- Who owns infrastructure in your organization: the application team or a platform team? What do they already run?
- How many services and stages? (This is the V4 license number.)
- Is anything non-AWS in scope (Cloudflare, Vercel, SaaS resources)?
- How much do you value local development speed versus deployment governance?
- What is your tolerance for depending on a small vendor or community?
Answers to those five questions pick the tool in nearly every engagement. If you would like us to walk through them with your team and produce a written recommendation, that is the first half of our V4 upgrade and migration service. Contact us.