The Clock Is Ticking on Node.js 20
If your Vercel project still pins Node.js 20, you have a hard deadline: October 1, 2026. After that date, Node.js 20 will be disabled in Project Settings, and any new deployment targeting it will throw an error.
The good news: existing deployments are safe. Serverless Functions that are already live will keep answering invocations normally. The pain only hits when you push a new deploy — which, let's be honest, is every Tuesday.
This isn't a Vercel-only story. Node.js 20 reached its official end-of-life on April 30, 2026, meaning no more security patches upstream. Vercel is simply enforcing what the Node.js release schedule already decided. If you're running Node 20 anywhere — Lambda, Cloud Run, bare EC2 — you're on borrowed time. This is a good moment to audit your entire fleet, not just the Vercel side.

Step 1: Find Out Which Projects Are Affected
Before you panic-upgrade everything, get a list. Vercel shipped a CLI flag for exactly this:
# Install the latest Vercel CLI globally
npm i -g vercel@latest
# List all projects still targeting a deprecated Node.js version
vercel project ls --update-required
That command prints every project where the Node.js version is out of support. Run it once, pipe it into a spreadsheet, and you have your migration backlog.
Step 2: Upgrade the Runtime
You have two clean paths:
Option A — Project Settings UI: Navigate to your project → Settings → General → Node.js Version, and flip it to 24.x.
Option B — package.json engines field (recommended):
{
"engines": {
"node": "24.x"
}
}
The engines field wins over Project Settings on the next deployment, which means your version is now tracked in git — no more "who changed the runtime in the dashboard?" archaeology.
Step 3: Don't Forget the Hidden Pins
Your package.json isn't the only place Node 20 might be lurking. Grep for these before you call it done:
.nvmrc.node-version- CI configs (
.github/workflows/*.yml, CircleCI, GitLab CI) - Dockerfiles used locally
Then switch your local runtime, blow away node_modules, reinstall, and run the full build + test suite. Node 24 ships with a newer V8, updated npm, and a handful of breaking changes in deprecated APIs — the kind that only show up when you actually run the tests.

The Escape Hatch: Container Deployments
Sometimes you genuinely cannot upgrade before the deadline. Legacy dependency, a native module that doesn't compile on Node 24, a client contract that freezes the stack. Vercel's answer is: ship it as a container image.
Drop a Dockerfile.vercel at your project root:
# Pin Node.js 20 as the base image
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
# Your server must listen on $PORT
CMD ["node", "server.js"]
Once that file exists, Vercel builds and deploys the image on every commit. Project Settings' Node.js version does not apply to containers, so the deprecation doesn't block these deployments.
But be honest with yourself about the trade-off: you now own the Node.js version and every security patch that lands upstream. Node 20 is EOL — meaning zero CVE fixes. A container buys you time, not safety.
Watch Out For
- Silent version drift:
enginesinpackage.jsonoverrides the dashboard. If you set 24 in the UI butenginessays 20, you're still on 20. Checkprocess.versionin a log line after deploying. - Preview vs. Production: Preview deployments use the same runtime config. Test the upgrade on a preview branch before merging to
main. - Native dependencies:
sharp,bcrypt,better-sqlite3— anything with a compiled binary — needs a rebuild on Node 24. ABI changes will bite you. - No rollback to 20 after Oct 1: Once the version is disabled, you can't just flip back. Deploy the container fallback before the deadline if that's your safety net.

The Bottom Line
Node.js 20's EOL was never a Vercel decision — it's the upstream release schedule catching up with your package.json. The migration itself is a 15-minute job for most projects: bump engines, update .nvmrc, reinstall, test, deploy. The projects that struggle are the ones with native modules or frozen stacks, and those should start planning now, not on September 30.
Recommended next steps:
- Run
vercel project ls --update-requiredtoday and triage the list. - Upgrade one low-risk project end-to-end as a template, then batch the rest.
- If you're stuck on Node 20, ship the container fallback early and set a real date to leave it.
Further Reading
- For teams formalizing their platform layer, the Santander platform engineering case study shows what "hours instead of 90 days" provisioning actually looks like at scale — the same discipline applies to runtime upgrades.
- If you're auditing UI quality alongside your runtime, this CSS contrast-color() accessibility guide is a solid complement.