Node.js 20 End-of-Life on Vercel: Our Migration to Node 24 LTS

Key takeaways

Node.js 20 is deprecated on Vercel as of October 1, 2026, and Node.js 18 has already been fully removed as a selectable runtime.

Node.js 24 LTS is Vercel's current default runtime, so any project without a pinned engines.node field moves onto it automatically on its next deploy.

The failures we saw during migration weren't in application code — they were native addons like sharp and better-sqlite3 shipping prebuilt binaries for an older Node ABI.

Vercel's default function timeout is now 300 seconds, up from the old 60-90 second ceiling, which changes what a hung deploy actually means while you're debugging one.

Pin engines.node in package.json before a version bump is forced on you — finding a stale native build in your lockfile during a production incident is the wrong time to learn this.

What does Node.js 20 end-of-life on Vercel mean for a project?

It means Vercel no longer runs functions on Node.js 20, and any project that doesn't explicitly pin a Node version moves to Node.js 24 LTS on its very next deployment, with no code changes required to trigger it. We found this out on a 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 had never required.

How do you check which Node.js version a Vercel project is running?

Run vercel inspect <deployment-url> --logs, or open the deployment's 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; if that field is undefined, the project is implicitly riding whatever Vercel's current default happens to be.

What actually breaks going from Node.js 20 to Node.js 24?

In our experience, application code almost never breaks on a Node major-version bump on Vercel — the breakage shows up one layer down, in native dependencies and build tooling. Three failure modes accounted for everything we hit: native addon ABI mismatches that force a from-source rebuild, deprecated Buffer() constructor calls in transitive dependencies that have graduated from warning to hard failure, and a stale build cache on the first deploy after the bump. None of this is a Node 24 regression specifically — it's the accumulated cost of skipping two major versions at once because nothing forced an earlier upgrade.

How do you pin the Node.js version for a Vercel deployment?

Set engines.node in package.json, for example to "24.x" — Vercel reads this field and fails the build loudly if it doesn't match, instead of silently running a version nobody chose. Projects using the newer vercel.ts configuration file can keep build and routing config in the same place as this intent, but the engines field in package.json is still what Vercel checks for the runtime version itself.

What changed with Fluid Compute that affects this kind of 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. That matters for a version migration because an instance that used to live for a single request can now be reused across several — so a subtle per-request state leak introduced during the upgrade, like a module-level cache that assumed a cold start every time, surfaces faster under Fluid Compute than it would have under the old one-instance-per-request model.

What is the rollback plan if Node 24 breaks production?

Keep the previous working deployment one command away: Vercel retains prior deployments, and vercel rollback re-promotes the last good one immediately without a rebuild. Before changing 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 a test suite wouldn't catch — image processing, PDF generation, and embedded databases are the usual suspects.

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 before they can deploy.

**Q: Does moving from Node 20 to Node 24 require rewriting code?**

**A:** Usually not. Most breakage traces back to native addons and build tooling rather than application-level JavaScript or TypeScript.

**Q: Does this migration also change the function timeout?**

**A:** Yes, separately — Vercel's default function execution timeout is now 300 seconds on all plans, regardless of which Node version a project runs.

**Q: Does pinning engines.node stop future automatic upgrades?**

**A:** Yes. An explicit engines.node value locks a project to that major version until it's changed on purpose, instead of tracking Vercel's platform default.

**Q: Should a project upgrade straight to Node 24, or stop at Node 22 first?**

**A:** Go straight to Node 24 if dependencies support it. It's the current LTS line Vercel defaults to, and stopping at 22 just means repeating this migration later.