On November 30, 2025, the AWS Cloud Development Kit formally ends support for Node.js 18. If you build or deploy with CDK, this AWS CDK Node.js 18 end of support milestone matters more than a calendar footnote. Your apps won’t keel over at midnight, but issues reproducible only on Node 18 won’t get fixes, new features will target newer runtimes, and your upgrade tax grows by the sprint.
Here’s the thing: this isn’t happening in isolation. Node.js 18 reached upstream end‑of‑life in April 2025. AWS services are tightening their timelines, too—App Runner stops supporting Node 18 on December 1, and Lambda has already moved the ball forward on Node 22 (and newer). It’s time to move.
What actually ends on November 30?
Support in this context means CDK maintainers won’t triage or patch problems unique to Node 18 across the CLI, constructs library, and ecosystem tools (JSII, Projen, CDK8s). New CDK features will assume supported Node versions, and CI for Node 18 fades out. Your existing stacks still deploy—until a future change pulls an API or transitive dependency that breaks on 18 and nobody backports a fix.
Meanwhile, App Runner declares Node 18 end of support on December 1, 2025. Lambda already supports Node 22 broadly, and AWS documentation shows newer runtimes on deck. Translation: the platform you deploy to is moving on, and your IaC toolchain is moving with it.
A quick, data‑anchored timeline
• April 30, 2025: Node.js 18 hits upstream EOL. No new community security fixes.
• November 30, 2025: AWS CDK Node.js 18 end of support.
• December 1, 2025: AWS App Runner ends support for Node.js 18 (and older major lines).
• Today: AWS Lambda supports Node 22; docs list Node 24 as a runtime with deprecation dates set years out. If you’re still shipping Lambda on 18, you’re in a deprecation window, and the longer you wait the harder upgrades become.
Who’s actually at risk?
If any of these ring true, you’re in the blast radius:
• Your developers run CDK locally on Node 18 (often via an older nvm default).
• CI images (GitHub Actions, CodeBuild, Jenkins, GitLab CI) pin node:18 or actions/setup-node@v3 with node-version: 18.
• Dockerfiles for build or deploy stages still read FROM node:18.
• Projen or custom scripts call CDK via Node 18, or your repo’s package.json engines field enforces 18.x.
• Your runtime targets lag too: Lambda on nodejs18.x or App Runner’s managed runtime set to Node 18.
Fast triage: find Node 18 everywhere
Let’s get practical. Before planning, locate Node 18 in code and pipelines:
• Search config: ripgrep for "node:18|nodejs18.x|setup-node.*18" across your org. It surfaces Dockerfiles, IaC templates, and workflow YAMLs fast.
• Check engines: look for engines.node in package.json. If it’s "^18" or "18.x", you’ll block the team after the bump or silently drift.
• Inspect CI: in GitHub Actions, scan for uses: actions/setup-node and node-version: 18. In AWS CodeBuild, review image tags and phases that run node -v.
• Inventory Lambda: use a simple CLI query to list functions by runtime (nodejs18.x) per Region, then prioritize by traffic and blast radius.
• App Runner: if you use managed runtimes, confirm the runtime setting in service YAML or console; if you build containers, check your Docker base images.
Upgrade decision: Node 20, 22, or 24?
Short answer for most teams: upgrade the CDK toolchain and your apps to Node 22 LTS now. It’s stable across AWS services, carries security fixes until April 2027, and avoids last‑minute surprises. If your roadmap horizon is three years and you control your base images, Node 24 LTS gives you runway into 2028, but expect a few weeks of ecosystem catch‑up on the newest line.
For serverless stacks, Lambda already supports Node 22 across regions, and CDK builds happily on 22. If your org mandates stepping‑stone upgrades, go 20 first, then plan a quick hop to 22. Whichever you pick, commit to trimming the gap to six months or less between Node LTS lines—no more skipping two majors.
Migration playbook: seven steps that actually ship
1) Set the organizational default. Update your language standards doc and dev containers: nvm alias default 22; devcontainer.json base image to Node 22; company seed repos with engines.node ">=22". Clear guidance beats ad‑hoc exceptions.
2) Upgrade CDK and the toolchain together. Bump aws-cdk-lib, constructs, and the CDK CLI in lockstep with Node. If you use Projen, update projen and re‑synthesize; for JSII‑based libs, align Node, TypeScript, and tsconfig targets.
3) Refresh your build images. Replace FROM node:18 with node:22 in Dockerfiles used for build, test, and deploy stages. If you’re on AWS CodeBuild standard images, select the latest image line and install Node 22 at build time or switch to an image that includes it. Cache warmup: clean node-gyp caches and rebuild native modules.
4) Update CI workflows. In GitHub Actions, bump actions/setup-node to a current major and set node-version: 22. Re‑pin lockfile hashing to avoid false cache hits, then run a full clean install (npm ci, pnpm install --frozen-lockfile, or yarn install --immutable) and rebuild any native bindings.
5) Cut over serverless runtimes. For Lambda, switch to nodejs22.x and redeploy; verify your bundler target (esbuild target=node22 or webpack/node target) and update Powertools or SDKs if pinned. For App Runner managed runtimes, set Node 22; for containerized services, rebuild with Node 22 base images.
6) Re‑verify security and performance. Node 22 brings OpenSSL updates and subtle TLS behavior changes. Re‑test mTLS handshakes, custom CA bundles, and HTTP keep‑alive under production‑like load. Watch cold starts if you also switch to AL2023‑based images.
7) Remove the escape hatches. After green builds and canary health hold steady, drop Node 18 from engines and CI matrices. If you leave it in, someone will add a fast follow feature that only “works on my 18.”
Common breakage when moving off 18
• Native modules: any dependency with native bindings (bcrypt, canvas, sharp, node-sass legacy chains) needs a rebuild against the new Node ABI. If you ship Lambda layers or App Runner containers, rebuild those too.
• TLS and OpenSSL edges: stricter defaults can surface expired intermediates, legacy ciphers, or pinned fingerprints. If your service talks to older appliances, test renegotiation and cipher lists early.
• ESM/CJS shape: newer bundlers and Node versions make ESM interop less forgiving. Watch for default vs named import mismatches and dependencies that ship only ESM. Set type: module consistently or keep a stable transpile target.
• Test runner assumptions: Node’s built‑in test runner matured after 18. If you used experimental flags or undocumented hooks, move to a stable test framework version or align flags with your new runtime.
People also ask: Is CDK itself blocked if I stay on 18?
Not immediately. Your CDK commands may still run for a while on Node 18. The risk is that future CDK features, bugfixes, or dependency updates won’t validate on 18, and regressions unique to 18 won’t be investigated. You’ll be the only team carrying that weight.
People also ask: Should we leapfrog to Node 24 now?
If you want the longest runway and your platform targets are ready, yes—especially for containerized services you fully control. For mixed estates with Lambda and App Runner, Node 22 is the safest, fastest path with clear support timelines, and you can schedule a well‑planned jump to 24 after peak season.
A 30‑minute checklist you can run today
• Confirm your current versions: node -v, npm -v, cdk --version in dev and CI; record them in the PR.
• Update engines: set engines.node ">=22" and add an .nvmrc with 22.0.0 or 22.x to enforce consistency.
• Bump dependencies: aws-cdk-lib, constructs, projen, aws-sdk v3, powertools, and your test runner. Regenerate lockfiles with a clean install.
• Switch CI: update actions/setup-node to a current major with node-version: 22 and re‑warm caches. For CodeBuild, update buildspec and image or install 22 in the install phase.
• Rebuild images: change Dockerfiles to FROM node:22 for build and runtime layers. If you multi‑stage, keep a small, current runtime image.
• Flip the runtime: migrate Lambda functions to nodejs22.x and App Runner to Node 22 or containers built on Node 22.
• Test the boring stuff: TLS, proxies, custom CAs, timesouts, and retry policies. Then run a canary deploy and watch logs and p95 latency.
Guardrails that prevent backsliding
• Add a repo rule: block Dockerfiles that reference node:18 in PRs. Even a simple regex bot saves hours.
• Enforce with CI: fail builds if node -v isn’t 22.x in CI. If you need 20.x for a legacy module, make it an explicit matrix entry with a retirement date.
• Track runtime inventory: export Lambda and App Runner runtime lists weekly; pipe them into a dashboard. Tie deprecation exceptions to tickets with owners and dates.
• Pin what matters, not everything: pin your base images and critical toolchain, but keep room for security patch updates.
Cost and velocity: why this pays back quickly
Upgrading isn’t just risk reduction. Node 22 typically improves startup, crypto, and fetch performance versus 18. On Lambda, AL2023‑based runtimes and smarter certificate loading can shave cold starts. Across CI, newer Node reduces rebuild time for many native packages and unlocks better parallelism in modern tooling.
Where CDK deploys meet runtime choices
Don’t confuse the dev/runtime split. CDK’s Node version controls your build and deploy pipeline. Your app runtime (Lambda, App Runner, containers) is independent—but the industry drifts together. Align them if you can, and test them separately so a CDK CLI bump doesn’t mask an app runtime regression.
Reference upgrade path we use with clients
• Week 0: Freeze feature work on repos that deploy infra weekly; create an upgrade branch; run the inventory search; open child PRs per repo.
• Day 1–2: Bump Node to 22, CDK toolchain packages, and test toolchain; fix native module rebuilds; green the CI matrix.
• Day 3–4: Flip Lambda to nodejs22.x and App Runner runtime or container base image; run load tests on TLS endpoints; validate alarms and dashboards.
• Day 5: Canary to 5–10% traffic for 24 hours; if stable, roll forward. Remove Node 18 from engines and CI; add guardrails.
If you want a deeper, production‑grade playbook for runtime upgrades, our Node.js 24 LTS production upgrade playbook maps nicely to this effort, even if you stop at 22 today.
Real‑world gotchas and fixes
• OpenTelemetry and tracing: check your collector and SDK versions. Older agents sometimes assume older TLS defaults or Node HTTP internals.
• SSO and corporate proxies: Node 22’s fetch often uncovers proxy misconfigs that were hiding behind request retry libraries. Validate NO_PROXY and certificate chains.
• Build reproducibility: switching major Node versions changes npm’s platform metadata. Pin your lockfile format and rebuild caches cleanly to avoid phantom diffs.
• Serverless bundling: esbuild target must match runtime to avoid polyfill bloat. If you deploy to Lambda 22, use target=node22; you’ll cut artifact size and cold starts.
What to do next (this week)
• Decide target LTS (22 for most teams) and publish the standard.
• Merge a single PR per repo that upgrades Node, CDK, and CI together.
• Migrate Lambda/App Runner runtimes and rebuild images.
• Add guardrails to block node:18 going forward.
• Schedule a follow‑up in two weeks to consider Node 24 if your ecosystem is ready—use our real‑world Node.js 24 LTS upgrade guide and the production upgrade playbook when you plan that hop.
Need a second set of hands?
If your estate spans dozens of repos and pipelines, a guided cutover pays for itself. Our application modernization services help teams ship upgrades without disrupting roadmaps. See the kinds of systems we build in our portfolio, and if you want help, talk to us.
Final take
The AWS CDK Node.js 18 end of support deadline is a forcing function. Pair it with App Runner’s cutoff and Lambda’s modern runtimes, and you’ve got a crisp case to upgrade now. Move your CDK toolchain and runtimes to Node 22 this week, keep the door open to 24 when the dust settles, and add guardrails so you don’t fight this fire again next year.
