The question we hear most from Serverless Framework users in 2026 is not technical. It is: do we have to pay now, and how much? This post explains the V4 licensing model in plain terms, who is exempt, what the alternatives are, and how we help clients decide. It reflects the published terms as of August 2026; check serverless.com/pricing and the Upgrading to V4 guide for the current text, because the details can change.
The short version
- Serverless Framework V3 is free, MIT-licensed, and no longer maintained.
- Serverless Framework V4 (May 2024 onward) is the maintained release. It is free for organizations with less than $2 million in annual revenue and paid for everyone else.
- Paid usage is metered in credits consumed per Service Instance: one service deployed to one stage in one region counts as one instance per month.
- Every V4 user, paid or not, must authenticate the CLI with a Dashboard login, an access key, or a license key.
Who pays
The threshold is organizational annual revenue, not the size of your serverless footprint. A two-person startup with 40 services pays nothing; a $50M company with one service pays. Note the word organization: the threshold applies to the legal entity that owns the workload, and a subsidiary or agency running code on behalf of a large client should read the license terms carefully about whose revenue counts. We are not lawyers and this is not legal advice; your counsel should read the terms if you are near the line.
Nonprofits, open-source projects, and educational use generally fall under the free tier by virtue of the revenue test, but confirm against the current terms.
What it costs
Serverless, Inc. prices V4 in credits rather than seats. The unit that consumes credits is the Service Instance: a unique combination of service name, stage, and region. The important consequence is that cost scales with how many deployed stages you keep, not with traffic, function count, or invocations.
Two things this means in practice:
- Ephemeral stages are not free. If every pull request deploys its own stage and you keep them around for a month, each one is an instance. Tear them down when the PR closes.
- Consolidation pays. Five microservices that could reasonably be one service with five function groups cost five times as much to license. That is not an argument to merge everything, but it is a real input to service boundaries you did not have under V3.
We deliberately do not quote dollar figures here; the per-credit price and any volume tiers are on the pricing page and have changed since launch. Model it with your actual instance count across all environments, including the ones people forget (that dev-old stage from 2023 still counts if it is still deployed).
How authentication works
V4 will not deploy without identifying itself. Options:
serverless loginopens a browser and ties the CLI to a Serverless Dashboard account. Fine for laptops.SERVERLESS_ACCESS_KEYis a Dashboard-issued key for CI and headless use.SERVERLESS_LICENSE_KEYis for accounts on a license-key arrangement, typically larger customers; it does not require Dashboard usage.
Some teams object to the Dashboard dependency on principle. The license-key path addresses most of those concerns, and the framework does not upload your code or templates as part of authentication; it verifies entitlement and reports instance usage. Read the license keys guide for specifics.
Your options if you are over the threshold
1. Pay for V4
For many organizations the annual license is small next to the engineering cost of a migration. You get a maintained tool, built-in TypeScript bundling, serverless dev, and a vendor to call. If your team is productive with the framework and your instance count is modest, this is usually our recommendation. Our V3 to V4 upgrade tutorial covers the mechanics.
2. Stay on V3 (do not)
It deploys today. It will not receive fixes for AWS API changes or new runtimes, and the plugin ecosystem has stopped testing against it. Treat this as a time-boxed state, not a plan.
3. Use oss-serverless
oss-serverless is a community fork of the V3 codebase (npm package osls) that keeps the MIT license and continues to patch runtime and dependency issues. It reads your existing serverless.yml without changes. Its limitations: a small volunteer maintainer group, no new V4-style features, and no commercial support. We consider it a solid bridge for teams that need a supported V3-compatible tool while they decide, and a risky long-term foundation.
4. Migrate to a different tool
AWS CDK, Terraform/OpenTofu, and SST are the realistic destinations. Each is free to use. The cost is the migration itself: resource imports, API Gateway rebuilds, CI changes, and team retraining. We compare them in Serverless Framework vs SST vs AWS CDK in 2026. As a rule of thumb, migration makes sense when you are already over the threshold and either your platform team already standardizes on one of these tools or your instance count makes the license a meaningful annual spend.
A decision tree
- Under $2M revenue? Upgrade to V4. Done.
- Over the threshold, fewer than roughly ten Service Instances, no strong tooling standard elsewhere? Pay for V4. The license is cheaper than the migration.
- Over the threshold, platform team already on Terraform or CDK? Plan a migration; use oss-serverless or V4 as the bridge while it happens.
- Over the threshold, large instance count, no immediate capacity to migrate? Negotiate a license-key agreement for now, consolidate stages, and schedule the migration decision for a fixed date.
What we do for clients
Our V4 Readiness Assessment starts with an instance inventory across every AWS account and region, which is the number the whole decision hangs on and the one most teams cannot state from memory. From there we model the license, estimate the migration alternative, and give you a written recommendation per service. If you would like that done for your estate, contact us.