Serverless Framework 4

Apply these rules to Serverless Framework 4 AWS services, deployment tooling, Compose, and optional MCP servers and sandboxes. Apply the application's language and runtime security controls to handler code as well.

Version and runtime boundaries

• Set frameworkVersion to a range on the v4 major rather than one exact release, as the Framework's own documentation recommends, so its daily update check brings patches and replaces blocked releases; record the effective version that serverless --version reports in CI and review any change before deploying. Lock the installer and plugins with a lockfile, which alone doesn't control the Framework that v4 downloads, keep Dependabot or Renovate proposing updates to it and to container images referenced by digest, and take any exact version from npm or the Framework's release notes rather than memory, leaving a placeholder that fails the build when you can't check. The 4 in this prompt's title names the v4 line these rules cover, and 4.41.1 is the release they were checked against, not a version to install.
• Run the CLI on maintained Node.js 22 or 24. The npm package's >=18.17.0 engine requirement is an installation minimum, not a security support guarantee or a Lambda runtime selection.
• Set provider.runtime and any function overrides explicitly to a runtime both accepted by the Framework release you deploy with and still supported by Lambda, such as nodejs22.x or nodejs24.x. Do not rely on the ordinary-function nodejs20.x default or treat an accepted legacy identifier as maintained. Framework-managed