Originally published on protomindlabs.com.
Serverless Framework v4 went paid in early 2024, and the serverless corner of my timeline has been arguing about it on and off ever since. Most of the noise misses the actual decision.
Here's the thing people skim past. The $2M annual revenue threshold means most indie builders and small startups pay nothing. Side project? Pre-Series A? You pay zero. The pricing page looks scary, but the bill is usually $0.
So the real question isn't "what's cheaper than v4." It's whether you want the config that defines your production infrastructure tied to someone else's revenue model. The $2M threshold today is a choice, and choices get revised. I've been burned by that exact pattern before, with a different tool but the same story, and it shapes how I pick infrastructure now.
Here's what actually changed, and what I'd reach for instead, depending on what you care about.
What v4 actually charges for
The v4 pricing model is narrower than the panic suggests. From the announcement post:
- Organizations under $2M in annual revenue: free
- Independent developers, open-source projects, consultants deploying for clients: free
- Users staying on v3 or older: free, forever
- Everyone else: starts at $49/month, billed per "Instance." This is defined as a unique combination of AWS account, stage, and region running a deployed service for more than 5 days in a calendar month
The 5-day rule is a real carve-out. Preview environments and ephemeral CI stacks don't count. It's the long-lived production stacks that rack up the bill.
And honestly, it's a reasonable business model. The Serverless Framework team has to pay engineers, and "enterprises pay, hobbyists free" is about as fair as that trade gets. My issue isn't the pricing itself. It's that once a tool starts taking money, its incentives shift toward what paying customers ask for, and away from the long tail. That's not a flaw, just how commercial software works. It does mean the math for starting a new project in 2026 is different from 2022.
The four real alternatives
These are the tools I'd actually consider if I were starting fresh today. Not a list of twelve options. Just the ones that solve a real variant of the problem.
1. AWS SAM, if you want AWS's own answer
SAM is a CloudFormation extension with a CLI. It's free, first-party, and about as safe a bet as it gets in terms of longevity. AWS ships it. The YAML is verbose, and you will probably curse it the first time you write a nested intrinsic function. The local dev loop with sam sync is decent, and the ecosystem is smaller than Serverless Framework's. Still, "smaller than SF" is larger than what most people actually need.
Pick SAM when you're deep in AWS, comfortable with CloudFormation's declarative model, and want to minimize external dependencies.
2. AWS CDK, if you want code instead of config
CDK lets you define infrastructure in TypeScript, Python, Java, or C#. It compiles down to CloudFormation. For anyone who has tried to write conditional logic in YAML, CDK is a relief.
The trade-off is the abstraction ceiling. L2 and L3 constructs hide complexity well, until they hide the one thing you need. Then you're back at L1, effectively writing CloudFormation in TypeScript. CDK works best for teams willing to build and maintain their own construct library. It is less forgiving if you expect to avoid CloudFormation entirely.
Pick CDK when you want a code-first approach, plan to standardize constructs across a team, and are committed to AWS.
3. SST, with one caveat
SST launched in 2020 to fix many of Serverless Framework's pain points. The sst dev live development loop is still one of the best in the category. It streams Lambda invocations to your laptop with hot reload. If you've ever been stuck in a deploy-debug loop, you know why that matters.
The caveat is that SST has been in maintenance mode since mid-2025. The team pivoted to OpenCode, an AI coding agent that scaled quickly. SST v3 still works and still gets maintenance updates, but active feature development has slowed.
"Maintenance mode" doesn't mean unusable. The framework is stable, and the docs are solid. But if your plan depends on future features, that roadmap is no longer the same.
Pick SST when you want a strong local development experience and are fine with a stable, low-change tool.
4. Terraform, if you want long-term stability
This is the one I picked for the SaaS kit. Terraform isn't a serverless framework. It's a general-purpose infrastructure-as-code tool with serverless support. It's more verbose than Serverless Framework, and you lose some convenience. The AWS provider can also feel awkward around Lambda packaging.
Still, it has been stable for years, supports multiple clouds, and the contract between you and the tool doesn't depend on your revenue. When you're selling something that people will run for years, the infrastructure layer should be predictable. Terraform fits that role.
HashiCorp's license change in 2023 raised concerns, and OpenTofu emerged as a fork. That fork is actively maintained and provides a viable open-source fallback. Having two viable paths reduces risk.
The fifth option: don't migrate
If you have a working v3 project and the $2M clause doesn't apply, the best option might be to do nothing. It is not exciting, but it is practical.
You can also switch to oss-serverless, a community fork maintained by the Bref team. It acts as a drop-in replacement for v3. Install it and keep going. The fork keeps Node.js runtimes up to date and patches dependencies. It does not aim to add new features, only to keep things stable.
Staying on a working tool, with a community-supported fork, and delaying migration until necessary is a reasonable approach.
Where v4 still wins
Serverless Framework v4 still has a place. If your team relies on its plugin ecosystem, the migration cost is significant. The plugin library represents years of accumulated work that alternatives do not fully match. For organizations above $2M in revenue, $49 per month is negligible.
The v4 pricing model does not make Serverless Framework a bad tool. It changes the nature of the commitment. If you would have chosen it in 2023, you would likely still choose it now.
What changed is that new projects have a stronger reason to evaluate alternatives. Those alternatives have matured enough to be viable.
If you're starting fresh in 2026, choose the tool whose pricing model you will not need to revisit later.
Top comments (0)