4.43.0

Features

• AI coding agents can set up and use the Serverless Framework on their own. serverless agent setup installs the bundled Agent Skills — the serverless-framework skill into your home directory for every agent session, and the feature skills into the service you run it in — and prints an environment report: whether you are signed in, which AWS credentials a deploy would use (the resolver or profile, whether its SSO session has expired, and the stages it did not check), and whether the directory has a serverless.yml, each failing line with its one-line fix. It needs no sign-in and no AWS credentials, and it is safe to re-run. serverless agent docs prints the documentation that ships with the installed CLI, offline, and serverless agent skills list / serverless agent skills read print the bundled skills without installing them; these commands work anywhere, including next to a serverless.yml that does not load. Getting Started now has a prompt to paste into Claude Code, Codex, Cursor or any agent that runs terminal commands. (#13897) Read more in For AI coding agents, the agent setup, agent docs and agent skills references, and the Agent Skills guide.

  :::bash serverless agent setup # skills + environment report serverless agent setup --stage prod --dir claude # check another stage, write only .claude/skills serverless agent docs providers/aws/guide/functions serverless agent skills read serverless-upgrade

The bundled skills in this release:

• serverless-framework (new) — start-here rules, a first-deploy checklist, and references for the CLI, the development workflow, multi-service projects, Python and serverless.yml.
• serverless-upgrade (new) — upgrades v1–v3 services to v4 without changing what deploys: a before/after template comparison, required changes kept apart from optional improvements, and plugin replacements.
• serverless-mcp and serverless-sandboxes — accuracy and clarity updates. Installed skills update themselves after the next command a newer Framework runs (the agent commands, --help and --version leave them alone).

Function packages leave out the skills that agent setup writes into a service (.claude/skills/serverless-* and .agents/skills/serverless-*), so they never reach your Lambda artifacts; other files in those directories are packaged as before, and package.patterns can include the skills again.

• serverless login works without a terminal, and --org picks your default org. Run from an agent or a script, serverless login prints the sign-in URL and waits up to 10 minutes for you to open it; with an existing session it reports that session and exits. In CI without a key it fails at once and names SERVERLESS_ACCESS_KEY and SERVERLESS_LICENSE_KEY. serverless login --org <name> sets the default org, switching an existing session without signing in again. --help for built-in commands now works before signing in, and commands that need a sign-in say so in one line naming serverless login and both keys, without a stack trace. (#13897) Read more in the login reference and Running in your own CI/CD.

  :::bash serverless login --org acme-platform

• Sandboxes and agents inherit provider.environment, and sandbox environment variables accept CloudFormation references. A sandbox or agent now receives every provider.environment variable, with its own keys taking precedence, exactly as functions do. Sandbox values can be CloudFormation references (!Ref, !GetAtt, !ImportValue, !Sub, …) resolved when the stack deploys — previously they reached the image as the text [object Object] — and vpc.subnetIds / vpc.securityGroupIds accept the same shapes as a function's vpc, including a single !Split expression. serverless dev --sandbox runs the local container with the same merged environment. Thanks @Hi-Fi for the report. (#13876, [#13881]) Read more in the Sandboxes guide and the agents runtime guide.

  :::yaml provider: environment: LOG_LEVEL: warn # now reaches every function, agent and sandbox sandboxes: renderer: artifact: ./renderer environment: JOBS_TABLE: !Ref JobsTable # resolved at deploy time

Note A sandbox or agent in a service that already sets provider.environment receives those variables on its next deploy; each sandbox builds a new image version once.

• Warnings for Lambda runtimes AWS has deprecated. package and deploy now warn when a function uses a runtime past its AWS deprecation date — for example nodejs20.x or python3.9 — and say when Lambda stops allowing new functions and updates on it. Services that set no runtime get nodejs20.x, the default, and see the warning too; set provider.runtime to a supported runtime such as nodejs24.x to clear it. (#13897) Read more in the functions guide.

Bug Fixes

• Python dependencies keep their compiled bytecode on Lambda, cutting cold starts by about 40%. Every dependency .pyc that pip compiled was stale by the time it reached Lambda, because packaging pins every zip entry to a fixed date so unchanged code is not redeployed; Python recompiled all of them on every cold start. Dependencies are now installed with SOURCE_DATE_EPOCH set, so pip writes hash-based .pyc files that stay valid (Python 3.7 and later; a value you set yourself is kept). Existing projects get the new bytecode on their first package after upgrading: the requirements are installed once more, without serverless requirements cleanCache, and the next deploy updates each function's code once. Thanks @juanjsebgarcia for the report, the measurements, and the fix! (#13889, [#13888]) Read more in the Python guide.
• serverless remove empties versioned deployment buckets. A service using the in-stack deployment bucket with deploymentBucket.versioning: true — required by codeStorageMode: reference — ended in DELETE_FAILED, because the object versions stayed in the bucket. remove now deletes every version and delete marker of the service's artifacts, reads the bucket's real versioning state (including buckets where versioning was later suspended), pages through large deployment prefixes, and no longer touches the artifacts of a sibling stage such as dev2 when removing dev. The misleading "S3 bucket not found. Skipping S3 bucket objects removal" notices are gone. (#13878) Read more in the remove reference.
• esbuild packaging works in git worktrees and submodules again. A service directory whose .git is a file failed with ENOTDIR: not a directory, stat '<service>/.git/**' when it used package.patterns or build.esbuild.bundle: false. Thanks @jamesclancy for the report. (#13877, [#13880])
• Variables that resolve to themselves fail immediately. A parameter such as stages.default.params.NAME: ${param:NAME, ''} refers to itself, because a parameter defined in serverless.yml takes precedence over a Dashboard parameter of the same name; the same applies to two parameters that reference each other. Such configurations previously ran at full CPU until the process ran out of memory; they now stop at once with Cyclic reference found: ${param:NAME, ''} -> ${param:NAME, ''} at 'stages.default.params.NAME'. Configurations that resolve today are unaffected. (#13871) Read more in the parameters guide.
• Sandboxes deploy with the in-stack deployment bucket. With enableLegacyDeploymentBucket: true, or on a stack that still owns its deployment bucket, the sandbox image build role was granted s3:::undefined/*, so the image build failed after the deploy had started. Thanks @Hi-Fi for the report. (#13872, [#13873])
• Dev Mode reaches functions with their own IAM role. Functions with iam.role.statements of their own timed out under serverless dev; they now connect like the rest. Dev Mode also stops cleanly on SIGTERM and names the stage and region to redeploy afterwards (for example serverless deploy --stage alice --region us-east-1), and without a terminal it prints its startup phases. (#13897)
• serverless deploy function says when it skips an environment change. When a function's environment holds a CloudFormation reference, deploy function cannot update the environment; it now warns when a local change would be lost, instead of skipping it silently. (#13881)
• Clearer AWS credential errors. Errors name the profile in use and the aws resolver that set it, an expired SSO session gets its own message with the command to sign in again, and credentials that AWS rejects say where they came from — for example environment keys that take priority over a profile. (#13897)
• serverless info on a stage that is not deployed says so, and names the service in a Compose project, instead of printing an internal error. (#13897)
• Python packaging: changing an install setting such as pipCmdExtraArgs or pythonBin now reinstalls the requirements instead of reusing a cache built with the old setting; a missing interpreter and non-string pipCmdExtraArgs entries fail with clear errors; invoke local works without a terminal on macOS. (#13897)
• Smaller fixes: clear errors for a frameworkVersion this CLI cannot run; Compose projects that use service resolvers run core commands at the Compose root; .serverless/meta.json is no longer written outside a service; the build-plugin conflict message prints without a stack trace. (#13897)

Maintenance

• Bumped the AWS SDK group with 106 updates across three bumps (#13865, [#13891], [#13894])
• Upgraded adm-zip to v0.6.1 (#13874) — hardens archive extraction (GHSA-vwc7-r8mq-g2x9)
• Upgraded hono to v4.13.8 (#13867, [#13895])
• Upgraded jest to v30.5.2 (#13895)
• Upgraded prettier to v3.9.8 (#13895)
• Upgraded eslint to v10.10.0 (#13884)
• Upgraded lint-staged to v17.5.1 (#13884, [#13895])
• Upgraded globals to v17.12.0 (#13867)