If your patient portal, online scheduling tool, or intake app runs on a serverless backend, you may have just hit a wall you didn’t see coming. As of July 1, 2026, Amazon Web Services no longer lets you update Lambda functions built on the Node.js 20 runtime. The function still answers requests, but you can’t ship a fix, a config change, or a security patch to it through the normal path — and the runtime underneath it stopped receiving security updates back on April 30. For a healthcare business handling protected health information (PHI), “we can’t patch it and it’s no longer maintained” is exactly the sentence you don’t want to say to an auditor.
What actually changed with Node.js 20
Node.js 20 (codename “Iron”) reached end-of-life on April 30, 2026. From May 1 onward, the Node.js project ships no more security patches for the 20.x line — any new vulnerability found in it simply stays open. Cloud providers moved in lockstep. On AWS Lambda, the nodejs20.x runtime passed through three gates: on April 30, 2026 Lambda stopped applying security patches to it; on June 1, 2026 you could no longer create new functions on it; and on July 1, 2026 you can no longer update existing functions on it. Your functions keep running and can still be invoked — but they are now frozen and unmaintained.
The ripple doesn’t stop at Lambda. The AWS SDK for JavaScript and the Azure SDK for JavaScript have both announced the end of Node.js 20 support, so your dependency updates will increasingly assume Node 22 or newer. If your portal’s API layer, appointment-reminder jobs, or insurance-eligibility checks live in Node 20 functions, the clock already ran out.
What happens if you do nothing
Ignoring this isn’t a neutral choice — it compounds quietly:
- You can’t ship fixes. A bug in your check-in flow or a needed security change can’t be deployed to a nodejs20.x function without first migrating the runtime, turning a five-minute fix into an emergency migration.
- An unpatched runtime under PHI. Any Node 20 vulnerability disclosed after April 30 stays unpatched. Under the HIPAA Security Rule’s expectation to run reasonably current, supported software, an unmaintained runtime handling PHI is a finding waiting to happen.
- Dependency drift. As libraries and the AWS and Azure SDKs drop Node 20, your installs start throwing engine warnings and, eventually, break — right when you least want surprises.
- Audit and partner risk. SOC 2 reviewers, cyber-insurers, and hospital procurement teams increasingly ask for a runtime inventory. An “end-of-life” entry on that list stalls deals and renewals.
What your patients gain when you act
Frame this as a patient-experience win, not just a developer chore. Node.js 22 and 24 ship a faster V8 engine, so portal pages and API responses — appointment lookups, form submissions, document uploads — return quicker on the same Lambda memory. A supported runtime means security fixes land automatically, so the portal that holds your patients’ records stays defended. And an app that deploys cleanly means the small improvements patients actually notice — clearer reminders, smoother mobile check-in, fewer errors at 7am on a Monday — can ship again without a migration blocking the queue.
What to do on your own portal or app
The good news: the fix is well-trodden. Node.js 22 is Maintenance LTS, supported through April 30, 2027, and is the shortest, lowest-risk jump from 20 — most codebases need only dependency bumps and a runtime change. Node.js 24 is Active LTS, supported through April 30, 2028, and buys a longer runway, but it crosses two V8 major versions, so native modules may need rebuilding and deserve extra testing. Either way, treat the PHI-touching functions first and move them through staging before production.
Your quick-win Node.js 20 upgrade checklist
Work top to bottom — most teams clear this in a day or two:
- Find every Node 20 function. Run aws lambda list-functions filtered to Runtime nodejs20.x in each region and account to get the real inventory — not just the ones you remember.
- Pick a target. Choose Node 22 for the fastest, safest move; choose 24 only if you want the longest support window and can budget extra native-module testing.
- Bump local and CI first. Update your .nvmrc, the engines field in package.json, and your CI image so the pipeline builds on the new version before anything reaches production.
- Test the integrations that touch PHI. Re-run scheduling, eligibility, e-prescribe, and document-upload paths — these are where SDK and crypto changes bite.
- Redeploy through infrastructure-as-code. Change the runtime in your SAM, CDK, or Terraform template and deploy to staging, then production — don’t hand-edit in the console.
- Update the SDKs. Move to current AWS and Azure SDK versions so you’re not carrying Node 20-era dependencies forward.
- Add a runtime tripwire. Add a CI check or scheduled alert that flags any function on an end-of-life runtime so next April’s Node 22 deadline never sneaks up.
How Vadimages helps
Vadimages builds and maintains the patient-facing web and mobile software this problem lives inside — patient portals, online scheduling and intake apps, and the REST and GraphQL API layers that connect them to your EHR, payment, and eligibility systems. When a runtime goes end-of-life, we inventory every function, plan the jump to Node 22 or 24, upgrade the API and integration layer, regression-test the flows that touch PHI, and redeploy through your infrastructure-as-code so nothing is hand-edited in a console. You get a portal that ships fixes again, loads faster for patients, and passes a runtime review — without pulling your team off care operations to firefight a deprecation. We stay on the web and mobile app side; your EHR, hosting accounts, and clinical systems remain yours to own.
Bottom line
Node.js 20 is done, and AWS Lambda’s July 1 gate means the “we’ll get to it” window has closed — any Node 20 function you own is now frozen and unpatched. Inventory your runtimes this week, move the PHI-touching ones to Node 22 first, and add a tripwire so the next end-of-life never surprises you. Handled early, it’s a quiet one-day upgrade; handled late, it’s an outage or an audit finding.
This article is general technical information, not legal or compliance advice; confirm your HIPAA obligations with your compliance officer or counsel.