Lambda public preview runtimes are AWS finally letting you kick the tires on a language runtime before it’s finished cooking, instead of waiting for a GA announcement and finding out about the rough edges in production. Starting with Node.js 26 and Python 3.15, you can deploy real functions against pre-release language versions, watch how they behave, and file bugs while the Lambda team can still act on them. That last part is the whole point — once a runtime is GA, breaking it to fix something is off the table.
What “public preview” actually changes
Here’s the detail that makes this interesting instead of just another beta program: preview runtimes use the exact same runtime identifier as the eventual GA release. nodejs26.x in preview is nodejs26.x at GA. There’s no nodejs26.x-preview namespace to migrate off later, no second deployment to plan, no config diff to reconcile. When the runtime graduates, your function configuration doesn’t change at all — Lambda just stops treating it as preview and starts covering it under the standard SLA. If you’ve ever had to migrate a workload off a deprecated identifier, you’ll appreciate how deliberately boring that graduation path is.
Under the hood: how Lambda public preview runtimes differ from GA
Functionally, a preview runtime runs your code the same way a GA runtime does — same Lambda Runtime API, same execution model, same support for Lambda Managed Instances and durable functions. What’s different is what’s happening beneath that interface. Internal caching layers and cold-start optimizations that GA runtimes benefit from haven’t been tuned yet for the preview runtime, so expect noticeably slower cold starts than you’d see on an equivalent GA version. AWS is upfront that this gets optimized during the preview window, not before it — you’re testing an engine that’s still being dyno-tuned.
Lambda also won’t let you forget you’re on a preview runtime. Every cold start emits a warning straight to CloudWatch Logs flagging the function as running a preview version not intended for production. If you’re aggregating Lambda logs into a SIEM or alerting pipeline, that’s a string worth watching for — it’s a free tripwire against a preview runtime accidentally ending up in a prod stage.
aws lambda create-function \
--function-name preview-canary-fn \
--runtime nodejs26.x \
--handler index.handler \
--role arn:aws:iam::123456789012:role/lambda-preview-role \
--zip-file fileb://function.zip \
--tags Environment=preview-test,Owner=platform-teamThat’s the entire delta in tooling terms — same create-function call you already know, same runtime identifier syntax. Base container images follow the same pattern too: Lambda publishes preview builds to the Lambda ECR gallery tagged 26-preview and 3.15-preview, so container-based functions get the same early-access path without a separate image family to track.
Known gaps and breaking-change risk areas
The tradeoff for early access is real, and AWS doesn’t dress it up: preview runtimes aren’t covered by the Lambda SLA or AWS Support plans, and they’re explicitly not for production workloads. Because the upstream languages themselves haven’t hit their stable release yet — Node.js 26 and Python 3.15 are both still pre-release upstream — the runtime itself can pick up breaking changes mid-preview as the language spec settles and as Lambda’s own team tunes the execution environment. A function that passes your test suite today isn’t guaranteed to pass it after the next preview patch.
There’s a subtler gotcha around Runtime Management Controls. If you pin a function to a specific preview runtime version, that pin holds even after the runtime reaches GA — you have to explicitly unpin to pick up the GA build. And a function pinned to a pre-GA version stays outside SLA and Support coverage regardless of what’s happened to the unpinned identifier in the meantime. Pinning is a reasonable move for reproducibility during testing; just don’t forget you did it.
CDK’s awkward middle step
Every other tool in the deploy chain — the console, the CLI, CloudFormation, SAM — accepts the preview identifier as a plain string, no special casing required. The AWS CDK is the one holdout, because it hasn’t shipped enum members like Runtime.NODEJS_26_X yet. Until it does, you construct the runtime directly instead of importing a named constant:
import { Function, Runtime, RuntimeFamily, Code } from "aws-cdk-lib/aws-lambda";
new Function(this, "PreviewCanary", {
runtime: new Runtime("nodejs26.x", RuntimeFamily.NODEJS),
handler: "index.handler",
code: Code.fromAsset("lambda"),
});It synthesizes to identical CloudFormation as a named enum would, so there’s no functional downside — just a small readability tax on your construct until the enum lands post-GA.
Testing preview runtimes locally before you ever deploy
You don’t have to burn a deploy cycle just to poke at the runtime. The Lambda base images published to the ECR gallery under the 26-preview and 3.15-preview tags are pullable and runnable with Docker directly, which means you can spin up a local container running the actual preview runtime and exercise your handler against it before it ever touches an AWS account. That’s a meaningfully different workflow than what most runtime migrations look like — normally you’re stuck waiting for a real deploy to see how your dependency tree behaves under a new interpreter. Here, the interpreter itself is one docker pull away, which makes it trivial to fold preview-runtime checks into a local pre-commit hook or a fast-feedback CI job that never touches a Lambda function at all. It’s a cheap first filter before the heavier, full-deploy canary testing described in the pipeline architecture for this runtime.
How this compares to Lambda’s normal deprecation cadence
Lambda’s usual runtime lifecycle runs in the opposite direction from this. A runtime ships GA, runs for a couple of years, then hits a deprecation date where AWS blocks function creation and eventually updates on the old identifier — full stop, migrate now, as documented in the Lambda runtimes reference. That’s a forced deadline at the back end of a runtime’s life. Public preview is the mirror image: an optional, voluntary window at the front end, where nothing forces your hand and the only cost of participating is your own testing time. You’ve never been able to get ahead of a Lambda runtime transition this early before — usually the first signal is a deprecation notice with a countdown attached.
Practically, that means the sane way to treat a preview runtime is as a dedicated canary lane: a non-production stage, a subset of your test suite, maybe a scheduled synthetic invocation, feeding results back through the Node.js 26 or Python 3.15 feedback issues if you hit something. It’s available in every commercial Region plus GovCloud (US) and China, so there’s no regional excuse to skip it either. Given that it costs nothing beyond standard Lambda billing and the runtime identifier won’t change out from under you at GA, there’s not much reason for a team that cares about runtime upgrades to sit this one out.
At Enkompass (enkompass.net), this is our home turf. We build event-driven, serverless systems — and we’re the ones testing next year’s runtime today so you don’t have to scramble tomorrow. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.