# Serverless Framework V.4: AI agents in serverless.yml and an sf-core release line

> The Serverless Framework is a command line tool that deploys code and cloud infrastructure from a YAML file to AWS Lambda and other managed services. Version 4 widens that file well past functions, adding Bedrock agent definitions, sandboxes, durable functions and EC2-backed managed instances, while the releases themselves are tagged sf-core rather than serverless.

**serverless/serverless** — ⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.

- Repository: https://github.com/serverless/serverless
- Website: https://serverless.com
- Stars: 46,915 · Forks: 5,718
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/serverless-serverless

## serverless.yml now holds agents, memory and browsers, not only functions

The framework is a CLI with YAML syntax that deploys both your code and the cloud infrastructure around it, aimed at APIs, front ends, data pipelines and scheduled tasks, across Node.js, TypeScript, Python, Go and Java. In version 4 that single file widens considerably. An `ai` property defines Amazon Bedrock AgentCore resources directly in serverless.yml: agents, memory, tools, gateways, browsers and code interpreters, managed through the `serverless agent` commands. Other additions in the same file include a `stages` property with a `default` block to fall back to, and per-function IAM policies, or a service-wide switch to per-function policies.

The consequence is about review, not syntax. A pull request that touches serverless.yml is now a change to application configuration, to cloud resources and to agent capabilities at once, and a reviewer who knows functions but not agent infrastructure has no way to see which of the two they are approving. The long-term vision the project points to treats this widening as deliberate rather than incidental.

## serverless diff and serverless reconcile exist because the stack changes without you

Two of the version 4 commands are about the gap between the YAML file and the live account. The first previews what a deployment will do to the running AWS CloudFormation stack:

```bash
serverless diff
```

The second handles the reverse problem, keeping usage records in sync with your AWS accounts when stacks are removed outside the CLI:

```bash
serverless reconcile
```

Both assume drift is normal rather than exceptional, and together they say something about the operating model. Under CloudFormation the stack is nominally declarative, yet deletions performed in the console or by another tool leave the framework's own records disagreeing with reality, which is exactly the situation reconcile is described as addressing. Read that as a warning about your workflow: if anyone can reach the AWS console, the file in your repository is not the only source of truth, and diff is the command that tells you which of the two the deploy is about to overwrite. Credentials are a related sore point, since version 4 also added browser-based `serverless login aws` and `serverless login aws sso` flows.

## serverless dev forwards live events to local code, and the README leaves the limits out

The new dev mode routes events from your live architecture to code running on your machine, so a change can be made and tried without a deployment:

```bash
serverless dev
```

That is a real change to the feedback loop. A handler invoked this way receives the actual event and context your deployed stack produces, so the class of bug where a handler works under a hand-written test payload and fails on the real payload shrinks, and the class where it needs the network to reach a downstream service does not, because your local code is now the thing being called from deployed infrastructure.

What the README does not tell you is the boundary of that arrangement. There is no statement about how long a local session can stay connected, whether calls to other AWS services are billed while a local handler serves them, what happens to in-flight requests when the local process exits, or whether every event source can be routed this way. Each of those is a decision you have to make before adopting dev mode as the default inner loop, and each is documented only on the linked CLI reference page, not in the repository.

## Popular plugins became built-in features, so the 1,000 plugin count now overlaps the core

The framework's extensibility story rests on a plugin ecosystem the README puts at over 1,000 entries. Version 4 moved several of the most used ones inside the CLI itself: Python requirements, AppSync, Prune and API Gateway Service Proxy are now first-class built-in features, and custom domain and SSL configuration no longer needs an external plugin at all. Improved Compose behaviour and Terraform state plus Vault secret integrations arrived in the same release.

For a new user this is a clear improvement, since fewer dependencies stand between a repository and a working deploy. For an existing one it creates a duplication problem with no documented resolution path. A service pinned to the community AppSync or Prune plugin may now ship something that overlaps a built-in, and the README does not say which built-in features came from which plugin, what precedence applies, or whether the plugins are deprecated. Nobody at the project is asserting that your pinned plugin is wrong, but the plugin you chose for a reason is now competing with the tool that hosts it, and that is a migration to plan rather than a duplicate to ignore.

There is a commercial layer behind this too. The project is maintained by Serverless Inc and the README points to a paid offering, so the boundary between what the core does and what a subscription adds is a pricing-page question rather than a repository one.

## Managed instances are EC2-backed, which moves the substrate out from under the idle-cost claim

The project describes its goal as applications that cost nothing while idle. Several version 4 features sit awkwardly against that sentence, and the first is managed instances: native support for EC2-backed Lambda execution, offered for higher throughput, predictable capacity and long-running workloads. The second is durable functions, built-in support for stateful workflows and long-running orchestrations, which by definition hold state across invocations rather than ending with the request. A third is tenant isolation mode, which creates distinct Lambda compute environments per tenant to reduce noisy neighbour effects on high-traffic customers.

The pattern is that the framework now routes a function to a different substrate depending on what the workload needs, and the README describes none of the operational consequences of that choice. It does not say what a managed instance costs while doing nothing, how the framework decides which mode a function should use, or whether a durable function's state survives a redeploy. So a reader who prices a service on the promise of no idle cost has to check the mode of each function rather than the service as a whole, and that check is not answerable from the repository.

## Sandboxes and streaming widen what a Lambda-backed service can be asked to do

Sandboxes deploy isolated, ephemeral compute environments on AWS Lambda, positioned for untrusted or per-session work such as AI agents and code execution. Alongside them, HTTP response streaming sends logs, long-running reports, partial responses or AI LLM responses out of Lambda through API Gateway HTTP APIs, and the Serverless MCP component auto-detects cloud resources from your code and pulls logs, state and config from AWS for IDEs such as Cursor and Windsurf.

The honest limit is that each of these is described in one sentence in the README, and the detail lives behind documentation links. For sandboxes that means the isolation boundary is undefined in the repository: what a sandbox can reach, how it is torn down, and whether one per session is pooled or created are all open questions from what is written down here. For streaming it means the failure mode of a client that disconnects mid-response is unstated. For MCP it means an IDE-facing component now reads from your AWS account, which is a permission question the README does not answer. Each is a feature you would want to size before enabling rather than after.

## Releases are tagged sf-core, the root package is private, and the licence is a file to open

The version numbers are not published under the name the project is known by. Recent tags read sf-core@4.43.0 on 2026-09-24, sf-core@4.42.0 on 2026-09-09 and sf-core@4.41.1 on 2026-08-26, while the repository root package is named frameworks-core, carries version 0.0.0 and is marked private. It is a monorepo root: the workspaces are packages/* with framework-dist and sf-core-installer excluded, and the test script runs unit tests across three of them, @serverlessinc/sf-core, @serverless/framework and @serverless/mcp. A binary-installer directory and a packages/sf-core-installer package sit at the top of the tree.

Two consequences for anyone automating against this. A watcher subscribed to tags prefixed with the project name sees nothing, because the prefix is sf-core. And a person looking for the published package name in the repository has to read the workspace list rather than the README title, which still says V.4.

On licensing, a LICENSE file and a THIRD_PARTY_LICENSES file are both committed, and the release metadata records no licence identifier at all. The project is maintained by a company rather than a foundation, so if you intend to vendor the CLI into an internal distribution, read the LICENSE file first rather than assuming an open source release line implies the terms you expect.

## Contributors get a Node version warning, not a stop, and a nine-package install allowlist

The development requirements are declared but deliberately non-blocking. devEngines asks for node ^24.15.0 and npm >=12.0.0 with packageManager pinned to npm@12.0.1, and both entries set onFail to warn, so a contributor on an older runtime is told and then allowed to continue. The consequence is that a change can pass the test suite on a runtime the project does not target and fail later in a release instead.

The allowScripts list is the sharper constraint. Only nine packages are permitted to run install scripts: aws-crt, aws-sdk, cpu-features, esbuild, fsevents, protobufjs, ssh2 and unrs-resolver, along with the entry that appears first in the file. Everything else in the dependency tree installs without executing its own build step. That is a sensible guard against supply chain compromise through postinstall code, and it also means a transitive dependency that needs a native build fails quietly until somebody adds it to the list in package.json.

The rest of the contributor surface is visible: AGENTS.md, CODING_STANDARDS.md, CONTRIBUTING.md, TESTING.md, RELEASE_PROCESS.md, VERSIONING.md and SECURITY.md at the top level, a .devcontainer directory, husky installed by the prepare script, and eslint plus prettier as the lint and format commands.

## Conclusion

Adopt the Serverless Framework if your team already deploys to AWS Lambda and wants functions and their infrastructure in one YAML file, because that shared file is the product and everything else follows from it. Do not adopt it as a portable abstraction across clouds, and read serverless.yml knowing that a diff in it can now change agent memory, tools and browsers as well as functions. Verify two things before you commit: the terms in the repository's LICENSE file, since the release metadata records no licence identifier and the project is maintained by a company, and which compute mode each function lands in, because managed instances are EC2-backed and the project's claim about costing nothing while idle does not describe them.

## FAQ

### How do I use the Serverless Framework?

You describe your service in serverless.yml and deploy it with the command line tool, which handles the code and the cloud infrastructure together. The named use cases are APIs, front ends, data pipelines and scheduled tasks, across Node.js, TypeScript, Python, Go and Java, and version 4 added a dev mode that routes live events to local code so changes can be tried without deploying.

### How do I install the Serverless Framework?

The repository README carries no install command, so the route it gives is its own documentation, linked from the header as the Serverless Framework Documentation, together with the website at serverless.com. For contributors rather than users, the repository documents its own setup through package workspaces, a setup-dev-for-dev-mode.sh script and a devEngines entry requiring Node ^24.15.0.

### How do I install Serverless?

Install instructions are not printed in the README, which points to the framework documentation and the website instead. The repository does show how the project is built and tested, with npm workspaces under packages, a private root package named frameworks-core, and a test script that runs unit tests across the sf-core, framework and mcp workspaces.

### How do I install Serverless version 3?

The current major line is version 4, described in the README as a continuation with significant updates, and the repository does not document how to install or migrate from version 3. What it does document is what version 4 added, including Sandboxes, Bedrock AgentCore support, Managed Instances, Durable Functions, AWS Login and SSO, and the serverless diff and serverless reconcile commands.

## Sources

- [Official documentation](https://serverless.com)
- [Official README](https://github.com/serverless/serverless#readme)
- [Project repository](https://github.com/serverless/serverless)
- [Release notes](https://github.com/serverless/serverless/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/serverless-serverless