Vercel Node.js 20 Deprecation: Upgrade AI-Built Apps Safely

If a client app still targets Node.js 20 on Vercel, treat the next deployment as at risk: inventory the affected project, move to Node.js 24 or 22, rebuild from a committed lockfile, test a preview, and verify the runtime after deployment. Do not assume the existing production site is already broken. Vercel says deployments that were created earlier continue running; the change affects new builds and Functions deployments.

Vercel published its Node.js 20 deprecation notice on July 14, 2026, with an October 1 cutoff for Builds and Functions. This guide was checked October 9, 2026. It is documentation-based guidance, not a test of your Vercel account or a report of a customer incident.

First, confirm whether the project is affected

Check every place that can select a runtime. AI-built apps often accumulate more than one version pin as they move between a builder, GitHub, local development, CI, and Vercel.

Review:

• Vercel Project Settings → Build and Deployment → Node.js Version
• the root package.json and any app-level package.json in a monorepo
• .nvmrc, .node-version, Volta settings, Dockerfiles, and CI workflow files
• build logs from the most recent preview and production deployments

For teams that already use the Vercel CLI, the documented inventory command is:

vercel project ls --update-required --format=json

Run it in the intended team scope and inspect the results; do not treat an empty output as proof that every repository and external CI job is current.

There is a documentation wrinkle worth knowing. Vercel's time-specific notice says Node.js 20 would be disabled for new Builds and Functions deployments on October 1. Its general supported-versions page, last updated February 27, still lists 20.x alongside 22.x and 24.x. When those pages disagree, use the dated deprecation notice plus the actual project setting and deployment result. Record what you observed rather than claiming a universal rollout state.

Choose the target deliberately

Vercel's supported Node.js versions page currently documents Node.js 24 as the default and Node.js 22 as an available version. The Node.js release table lists both 24 and 22 as LTS releases, while version 20 is end-of-life.

For most maintained projects, choose Node.js 24 if the framework and important dependencies support it. Choose 22 when a documented compatibility constraint prevents 24 and you have a named owner and date for revisiting the decision. Do not select an older runtime merely because the current production deployment still responds.

A narrow package setting makes the decision reviewable:

{
  "engines": {
    "node": "24.x"
  }
}

Vercel says a valid engines.node range in package.json overrides the project setting for a deployment. Avoid a loose range such as >=20 when you want predictable major-version behavior: Vercel maps that example to its latest available major, not necessarily the version a developer expected.

In a monorepo, confirm which package.json belongs to the Vercel project's configured root directory. Changing a package file outside that build root may have no effect.

Upgrade the repository, not just the dashboard

A dashboard-only change can leave local development and CI on Node.js 20. A repository-only change can surprise a team that thinks the dashboard is authoritative. Align both, then make the remaining version files consistent.

Use this sequence:

1. Create a branch for the runtime upgrade.
2. Update the intended engines.node value and explicit Node version files.
3. Switch the local and CI test environments to the same major version.
4. Reinstall dependencies with the project's existing package manager.
5. Commit the resulting lockfile change only if the package manager legitimately changes it.
6. Run the application's typecheck, tests, production build, and any migration validation that normally gates release.

Vercel detects the package manager from lockfiles. Do not delete a lockfile to make an install error disappear; that trades a visible compatibility problem for a less reproducible build. If the runtime change exposes a native-module or postinstall failure, update or replace that dependency through the project's normal review process.

Also inspect generated code instead of assuming the builder will update it. A prompt saying “upgrade Node” is not evidence that .nvmrc, CI, the monorepo root, and the deployed Functions runtime all changed.

Test the paths that Node actually executes

A successful static page load is too narrow for an app with server code. Exercise the behavior that runs in Vercel Functions or during the build:

Keep secrets and customer data out of logs. If you add temporary runtime logging, remove it after retaining the minimum evidence required for the handoff.

A Vercel preview is the appropriate place to test the change without replacing production. Preview success still proves only the environment tested: production can use different environment variables, domains, data, or access controls. Compare those differences before release.

Release with a rollback decision already made

Before the production deployment, record:

• the commit being released
• the chosen Node major and where it is configured
• the preview URL and checks performed
• the last known good production deployment
• the person authorized to promote or roll back
• any dependency or framework caveat that remains

After deployment, verify the production routes and the actual runtime. Watch for build failures, Function startup errors, authentication callback failures, and increased 5xx responses. If the release fails, use the team's established rollback procedure rather than editing production settings repeatedly without a controlled build.

Vercel documents containers as a temporary escape hatch for teams that cannot leave Node.js 20 before the cutoff. That does not make Node.js 20 supported again: the team becomes responsible for the container's runtime and security updates. Treat it as a time-bounded exception with an owner, not the default fix.

What to give the client at handoff

A useful handoff says more than “upgraded Node.” Include:

• project and repository
• production and preview environments checked
• previous and new runtime versions
• exact configuration files changed
• commands or CI jobs run
• deployment identifier and verification time
• unresolved compatibility risks
• rollback location and owner

The completion statement should stay precise: “This deployment was built and exercised on Node.js 24 using commit X.” It should not claim that every route is secure or that future dependency updates are covered.

Use Sentrail's seven pre-launch security checks to keep the runtime upgrade inside the wider release review. For the go/no-go record, the launch-readiness methodology separates verified evidence from checks that are still missing.

Prepared with AI assistance and checked against the linked primary documentation. No independent human expert review is claimed.