Headline: Node.js 20 was deprecated on Vercel on October 1, 2026, and Node.js 18 is no longer an available runtime at all — if a project doesn't explicitly declare its Node version, the next deploy can silently land on Node.js 24 LTS and change behavior underneath it.
Key takeaways
- Node.js 20 is deprecated on Vercel as of October 1, 2026; Node.js 18 has already been removed as a selectable runtime.
- Node.js 24 LTS is Vercel's current default, so any project without a pinned
engines.nodefield moves onto it automatically on the next deploy. - The deploys that broke for me weren't Next.js route code — they were native addons (
sharp,better-sqlite3) shipping prebuilt binaries for an older Node ABI. - Vercel's default function timeout is now 300 seconds, up from the old 60-90s ceiling, which changes what "it just hung" means mid-migration.
- Pin
engines.nodeinpackage.jsonbefore you need to — a silent major-version bump on a production deploy is the wrong time to discover a stale native build in your lockfile.
What does Node.js 20 end-of-life on Vercel actually mean for my project?
It means Vercel no longer runs your functions on Node.js 20, and if your project doesn't pin a version, the very next deployment runs on Node.js 24 LTS instead — no application code changes required to trigger it. I found this out on a side project that had been untouched for months: a routine deploy failed at the build step because better-sqlite3's prebuilt binary didn't match the new runtime's Node ABI, and npm's fallback to compiling from source then failed on missing build headers the old runtime never required.
How do I check which Node.js version my Vercel project is running?
Run vercel inspect <deployment-url> --logs, or open the build log in the dashboard — the Node version is printed at the top of every build. Locally, compare node -v against the engines field in package.json:
node -v node -e "console.log(require('./package.json').engines)" If engines.node is undefined, the project is implicitly riding whatever Vercel's current default is.
What actually breaks going from Node.js 20 to Node.js 24?
In my experience, application code almost never breaks — the breakage shows up one layer down, in native dependencies and build tooling.
| Failure mode | Symptom | Fix |
|---|---|---|
| Native addon ABI mismatch | Build fails compiling from source instead of using a prebuilt binary | Bump the dependency to a version with a Node 24 prebuild, or force a clean rebuild |
Deprecated Buffer() constructor calls | A warning in a transitive dependency becomes a hard failure | Update the package; Buffer.from() / Buffer.alloc() are the long-stable replacement |
| Stale build cache | First deploy after the bump installs the wrong native build | Trigger one deploy with the build cache cleared |
None of this is a Node 24 regression — it's the cost of skipping two major Node versions in one jump.
How do I pin the Node.js version for a Vercel deployment?
Set engines.node in package.json:
{ "engines": { "node": "24.x" } } If the project uses vercel.ts for configuration, the same intent can live alongside build and routing config:
// vercel.ts import type { VercelConfig } from '@vercel/config/v1'; export const config: VercelConfig = { buildCommand: 'npm run build', framework: 'nextjs', }; Either way, the goal is an explicit, version-controlled statement of which Node major version a project runs on.
What changed with Fluid Compute that affects this migration?
Fluid Compute reuses warm function instances across concurrent requests instead of spinning up one instance per request, and now supports graceful shutdown and request cancellation. A function instance that used to live for one request can now live across several — so a subtle per-request state leak introduced during the upgrade surfaces faster than it would have under the old one-instance-per-request model.
What's the rollback plan if Node 24 breaks production?
Keep the previous deployment one command away — vercel rollback re-promotes the last good deployment immediately without a rebuild. Before touching engines.node on a production project, open a preview deployment on the new version first, run the real test suite against it, and manually exercise anything the suite wouldn't catch (image processing, PDF generation, embedded databases).
FAQ
Q: Is Node.js 18 still available on Vercel at all?
A: No. Node.js 18 has been fully removed as a selectable runtime on Vercel; projects still targeting it must upgrade to deploy.
Q: Do I need to rewrite code to move from Node 20 to Node 24?
A: Usually not. Most breakage comes from native addons and build tooling, not application-level JavaScript or TypeScript.
Q: Does the default function timeout change with this migration?
A: Yes, separately — Vercel's default function execution timeout is now 300 seconds across all plans, regardless of Node version.
Q: Will pinning engines.node stop future automatic upgrades?
A: Yes. An explicit value locks a project to that major version until changed on purpose.
Q: Should I upgrade straight to Node 24, or go through 22 first?
A: Go straight to 24 if your dependencies support it — stopping at 22 just means doing this migration twice.
Originally published on devya.dev. Also on eng-ahmed.com. Built by Devya Solutions.
