AWS Lambda opens Node.js 26 and Python 3.15 runtimes in public preview

25 August 2026. AWS Lambda changed the way it ships managed runtimes. Node.js 26 and Python 3.15 arrive in public preview, a first in the platform’s history. No SLA. That is the condition the service attaches to any function running on these trial runtimes, and it says everything: this channel exists to test, not to serve production.

Since its launch, Lambda had only ever published managed runtimes at general availability, immediately usable by production workloads. That policy carried an invisible cost: once a runtime reached GA, the team could not introduce breaking changes without risking existing functions. The preview inverts the logic. It lets you test a workload, report issues, and lets observability vendors, Infrastructure-as-Code tools and deployment frameworks validate compatibility — while breaking changes are still on the table.

What actually changes

The two runtimes are enabled with the identifiers nodejs26.x and python3.15, through the console (the “Node.js 26 (Preview)” and “Python 3.15 (Preview)” options), the AWS CLI, CloudFormation, AWS SAM or the CDK. Three properties set the preview apart from GA.

First, no SLA. Preview runtimes are covered neither by the Lambda SLA nor by AWS support plans. A function running on nodejs26.x carries no availability guarantee — that is the rule to internalise before even thinking about a cutover.

Second, breaking changes remain possible. This is the point that matters most to an operator: during the preview, AWS can change the runtime in a way that breaks a function. You test, you do not migrate.

Third, graduation is automatic. A preview runtime carries the same identifier as its eventual GA runtime. When Node.js 26 or Python 3.15 reach production, functions flip over automatically with no action from the team. It is an engineering detail with real operational weight: the test code you write today will not have to be redeployed tomorrow.

The footprint is broad. Previews are available in every AWS commercial region, the GovCloud (US) regions and the China regions, at no extra cost — billing stays at standard Lambda rates.

Why these two languages now

The choice of Node.js 26 and Python 3.15 is not neutral. These are the two next deadlines that Lambda estates are about to hit, and each language’s calendar forces a fast switch.

Node.js 26 shipped on 5 May 2026 on the Current branch, with the Temporal API enabled by default, the V8 14.6 engine and Undici 8.0. It enters LTS in October 2026. The context matters more than the feature list: the Node.js project has announced a change of cadence. From October 2026, one major release a year (in April), LTS promotion in October, and, critically, no more odd/even distinction — Node.js 27 will become LTS too. For a Lambda estate, that means the “Current before LTS” window reads differently, and the decision has to come early.

Python 3.15 is at the end of its cycle. 3.15.0rc1 shipped on 4 August 2026, and the stable release is due on 1 October 2026. Offering the runtime in preview now lets you validate native dependencies — the things that most often break on a Python minor-version bump — before the official release.

The underlying signal is end-of-life. Functions still on Python 3.12 or Node.js 22 are approaching the end of AWS support for their runtime, and every runtime end-of-support turns into a forced migration. The public preview is the official channel for not living through that migration under pressure.

What an operator should do now

The preview changes the preparation work, not the production work. Three commands are enough to open the job.

# 1. List preview runtimes available in the region
aws lambda list-runtimes --region eu-west-3 | jq '.Runtimes[] | select(.Runtime | test("nodejs26|python3.15"))'

# 2. Deploy a test function on the Node.js 26 preview runtime
aws lambda create-function --function-name preview-test --runtime nodejs26.x \
  --role arn:aws:iam::123456789012:role/lambda-exec --handler index.handler \
  --zip-file fileb://function.zip

# 3. Confirm the runtime actually assigned after creation
aws lambda get-function-configuration --function-name preview-test --query 'Runtime'

The point is not to run production code on the preview, but to validate three things: native dependency compilation, cold start behaviour, and compatibility of layers and extensions. Those three points concentrate most of the surprises in a runtime migration.

The classic trap is treating the preview as just another runtime. It is not: with no SLA and no anti-breaking-change guarantee, a production function moved onto it is a function without a net. AWS says it outright — previews “should not be used for production workloads.”

Verdict

If your functions run on Node.js 22 or Python 3.12, open a test space on nodejs26.x and python3.15 now. Validate dependencies, measure cold starts, and file issues in the dedicated GitHub trackers for Node.js 26 and Python 3.15 before GA. The preview is precisely the tool that was missing to prepare a migration instead of enduring one.

If your functions are on older runtimes still — Node.js 20, Python 3.11 — the message is more urgent: you have two version jumps to plan, and the Python 3.15 preview is the right moment to confirm your native dependencies will survive the trip. Either way, the rule holds: test on preview, never produce on preview. Automatic graduation handles the rest the day GA lands.

References

• AWS — AWS Lambda introduces managed runtimes in public preview for Node.js 26 and Python 3.15, 25 August 2026
• AWS Compute Blog — Introducing public preview runtimes on AWS Lambda
• Node.js — Node.js 26.0.0 (Current), 5 May 2026
• PEP 790 — Python 3.15 Release Schedule
• Python — Python 3.15.0rc1, 4 August 2026