Serverless Framework V.4: a YAML-driven AWS deployment CLI that now hosts web apps, MCP servers and Bedrock agents

One serverless.yml describes both the code and the AWS resources

The Framework is a command-line tool that reads YAML and deploys your code together with the cloud infrastructure it needs, for use cases such as APIs, front ends, data pipelines and scheduled tasks. It supports Node.js, TypeScript, Python, Go, Java and other languages, and it is extensible through over 1,000 plugins. Version 4 pulls several popular community plugins into the core: Python requirements, AppSync, Prune and API Gateway Service Proxy are now built-in features, and custom domains with SSL certificates no longer need an external plugin. TypeScript handlers written as .ts files build automatically on deploy, with ESBuild included in the Framework. The same CLI also deploys AWS SAM and AWS CloudFormation project files alongside traditional Serverless Framework projects. For a team carrying an older V.3 configuration, that consolidation means fewer plugin versions to keep compatible, but it also means the behaviour of those features now follows the Framework's own release cycle rather than a plugin author's.

webApps runs an unchanged HTTP server on Lambda Web Functions

The newest addition is a top-level webApps block. You point it at an Express, Fastify, Hono, Next.js or other Node.js HTTP server, then deploy:

serverless deploy

The deploy packages the server, creates the web function and its HTTPS endpoint, and prints the URL. Your code listens on process.env.PORT the same way it does locally, so there is no handler to export and no adapter to install. Custom domains for these apps are served through Amazon CloudFront. The practical gain is that an existing Node.js server can move onto Lambda without being rewritten around a handler signature. The practical limit is the scope of the list: every server named is a Node.js one, so a Python or Go web server is outside what webApps is described as supporting, and those languages stay on the regular function model.

Stacks removed outside the CLI leave usage records out of sync

Two V.4 commands deal with the gap between what the Framework thinks is deployed and what AWS actually holds. The first previews a deployment's effect on your live CloudFormation stack before anything changes:

serverless diff

The second exists because the Framework keeps usage records tied to your AWS accounts, and those records drift when someone deletes a stack outside the CLI, through the console or another tool:

serverless reconcile

The consequence for operators is a rule worth writing down. If stacks are removed with anything other than the Serverless CLI, run reconcile afterwards, or the Framework's records will still count stacks that no longer exist. Running diff before each production deploy is the cheap way to catch an unexpected resource replacement before it reaches the live stack.

Under a detected coding agent the CLI stops prompting

V.4 treats AI coding agents as a first-class user of the CLI. This command installs bundled Agent Skills that teach Claude Code, Codex, Cursor and other agents how to work with the Framework:

serverless agent setup

The wider serverless agent command group gives agents structured access to your service. When a command runs under a detected AI coding agent, the CLI never opens an interactive prompt and reports progress as plain lines instead. That is helpful for automation, and it carries a consequence: any step that would ask a human for confirmation in a terminal will not ask when an agent runs it, so review what an agent is allowed to deploy. Separately, an mcp section in serverless.yml deploys MCP servers written with the official MCP TypeScript SDK to Lambda behind API Gateway with response streaming, and Serverless MCP lets Cursor, Windsurf and other AI IDEs fetch logs, state and config from AWS.

Bedrock AgentCore, Sandboxes and Durable Functions deepen the AWS lock-in

Most of the V.4 feature list is AWS-specific. The ai property in serverless.yml defines Amazon Bedrock AgentCore agents, memory, tools, gateways, browsers and code interpreters, managed through the serverless agent commands. Sandboxes deploy isolated, ephemeral compute on AWS Lambda for untrusted or per-session work such as AI agents and code execution. Managed Instances add EC2-backed Lambda execution for higher throughput, predictable capacity and long-running workloads. Durable Functions add stateful workflows and long-running orchestrations. Lambda tenant isolation mode creates separate compute environments per tenant to reduce noisy neighbour effects. HTTP response streaming works with API Gateway HTTP APIs. The description mentions other managed cloud services, but every one of these features names an AWS service. The consequence is that a service built on them has no straightforward path to another cloud, and the more of the ai, Sandboxes and Durable Functions configuration you adopt, the more of serverless.yml you would rewrite to move.

Credentials and secrets come through browser login, SSO and Doppler

V.4 adds browser-based flows for setting up AWS credentials. For a standard AWS login:

serverless login aws

For organisations that sign in to AWS through SSO:

serverless login aws sso

Permissions can be scoped more tightly than before. Per-function IAM roles let you attach policies to individual functions, or switch the entire service to per-function policies, which narrows what a compromised function can touch. Secrets can be pulled from Doppler through Serverless Framework Variables, so values do not need to live in serverless.yml or environment files checked into the repository. These additions reduce the amount of credential handling a team has to script around the CLI, though they still assume the account and permissions model of AWS.

The license is not a recognised standard one, and contributors sign a CLA

GitHub reports the license as NOASSERTION, meaning the LICENSE file at the repository root does not match a standard license it can identify. A THIRD_PARTY_LICENSES file sits beside it, and CLA.md sets out a contributor license agreement for anyone sending changes. The Framework is maintained by Serverless Inc, which also runs the CLI's usage records against your AWS accounts. The consequence is that you cannot assume MIT or Apache terms just because the source is public on GitHub. A company adopting it for production should have someone read LICENSE before rollout, and an outside contributor should read CLA.md before opening a pull request, because the agreement governs how their changes can be used.

sf-core ships a minor release about every week, and contributors need Node 24.15+

The project is under active development, with the last push on 2 November 2026. Releases are tagged against sf-core: 4.44.0 on 14 October 2026, 4.45.0 on 20 October 2026 and 4.46.0 on 28 October 2026. VERSIONING.md and RELEASE_PROCESS.md describe how those versions are cut. The root package.json, named frameworks-core, is an npm workspace over packages/* and release-scripts, excluding packages/framework-dist and packages/sf-core-installer. Its devEngines field asks for Node ^24.15.0 || ^26.0.0 and npm ^12.0.0, both set to warn rather than fail. The test script runs unit tests for @serverlessinc/sf-core, @serverless/framework and @serverless/mcp. The repository also contains binary-installer/, dev-mode-bridge/ and a skills/ folder, and installation instructions live in the documentation at serverless.com/framework/docs/.

Editorial conclusion

The Serverless Framework V.4 fits teams building on AWS Lambda who want one serverless.yml to cover functions, HTTP servers, custom domains, MCP servers and Bedrock agents, and who are comfortable with a vendor-run CLI that keeps usage records against their AWS accounts. It fits poorly for teams that need provider portability or a standard open source license. Before adopting it, read the LICENSE file, run serverless diff on a test stack, and decide how stacks will be removed so usage records stay in sync.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes