Beyond the News
Sign in
Web DevelopmentCloud & InfrastructureCloud PlatformsJavaScriptDeployment & DevOps Active dossier

AWS Lambda adds a pre-GA runtime channel for Node.js and Python

Lambda can now run Node.js 26 and Python 3.15 before their stable releases, giving application teams and tooling vendors a real AWS environment for compatibility testing while breaking changes are still allowed.

Reviewed and published by Lars Jansen Updated 4 min read
Comment
First published

Key details

  1. Node.js 26 and Python 3.15 are Lambda’s first managed runtimes released through a public-preview phase.
  2. Preview runtimes may receive breaking changes and are not covered by the Lambda SLA or AWS Technical Support.
  3. They are available across commercial, GovCloud and China Regions at standard Lambda pricing.
  4. Runtime identifiers are `nodejs26.x` and `python3.15`, the same identifiers planned for GA.
  5. AWS documentation targets November 2026 for the managed-runtime launches, subject to upstream release timing.
  6. AWS says preview runtimes are an experiment it may extend to future runtime releases.

What builders should take away

  1. Use the preview to run CI and representative workloads, not production traffic.
  2. Test native dependencies, observability agents, frameworks and IaC definitions before GA instead of waiting for the production cutoff.
  3. Avoid pinning a pre-GA runtime version unless you have a specific reproducibility reason and a plan to unpin it.
  4. Track AWS’s dedicated feedback channels because breaking changes during preview are expected rather than exceptional.
  5. Treat any preview performance measurement as provisional until AWS completes GA optimization.

What changed

AWS Lambda has introduced managed runtimes in public preview for the first time, beginning with Node.js 26 and Python 3.15. Previously, new Lambda runtimes launched directly at general availability. The preview channel lets customers, infrastructure-as-code frameworks, deployment tools, observability vendors and upstream language communities run real workloads before GA while AWS can still make breaking changes. Preview functions use the eventual GA identifiers, `nodejs26.x` and `python3.15`, so they graduate automatically when AWS moves the runtimes to GA.

Why it matters

The change creates an earlier compatibility window around one of serverless computing’s most important managed-runtime boundaries. Teams can test dependencies, cold starts, native modules, instrumentation and deployment tooling before a language version becomes production-supported. It also shifts some risk onto testers: preview runtimes can break, are outside the Lambda SLA and AWS Technical Support, and AWS explicitly recommends against production use.

This is a new release process, not just two new language versions

AWS says Lambda historically launched managed runtimes directly at GA. The new preview stage is intended to expose compatibility problems while AWS and upstream language projects can still make breaking changes. AWS says it hopes previews can become the default pattern for future runtime launches if the experiment succeeds.

Existing deployment tools can target the preview identifiers

The runtimes are available through the console, CLI, CloudFormation, SAM and CDK using the same identifiers that will be used at GA. That makes it possible to test normal infrastructure definitions rather than maintaining a separate preview-only deployment model.

The preview is deliberately outside the production support boundary

AWS does not cover these runtimes under the Lambda SLA or AWS Technical Support and warns against production workloads. Performance can also differ from GA, including slower cold starts while optimization and internal caching mature.

Functions graduate automatically at GA

Because the identifier remains unchanged, an unpinned preview function moves onto the GA runtime without a configuration migration. Teams that pin a specific runtime version retain that pin and therefore need to manage the transition themselves.

What to watch next

  • Whether AWS makes public previews standard for future Lambda runtimes.
  • Breaking changes or performance improvements during the Node.js 26 and Python 3.15 preview periods.
  • Final GA timing after the upstream language releases.
  • Compatibility updates from major serverless frameworks and observability vendors.

Still unclear

  • The preview runtimes can change before GA.
  • AWS’s target GA dates are indicative and depend partly on upstream language release schedules.
  • Performance and operational behavior during preview may not represent the final GA runtimes.

Sources

Direct reading behind this dossier.

3 sources
Lambda runtimes
Amazon Web Services primary documentation

Current runtime status and projected release/deprecation information.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading
Cloud & Infrastructure

AWS Lambda can now reference deployment packages directly from your S3 bucket

AWS has added a `REFERENCE` mode for Lambda deployment packages. It eliminates duplicate managed copies, raises the default managed-storage quota to 300GB, and gives teams direct control over encryption, lifecycle and audit policy—but a deleted or inaccessible source object can now make a function inactive.

Cloud & Infrastructure

AWS Lambda adds SnapStart to container-image functions

SnapStart previously covered only selected managed runtimes; extending it to container images changes the latency-versus-packaging trade-off for teams shipping large dependencies or standard container bases, with regional exclusions and runtime-specific guidance still applying.