Your project is being built for Node.js ${major} as the runt

Error message

Your project is being built for Node.js ${major} as the runtime, which is retiring by ${support.removal}.

What it means

During `astro build`, the @astrojs/vercel adapter runs getRuntime() (packages/integrations/vercel/src/index.ts:771) to map your local Node.js major version to a Vercel Serverless Functions runtime string. If that major is listed in SUPPORTED_NODE_VERSIONS with status 'retiring' and today's date is past its warnDate, the adapter logs this warning and still returns `nodejs<major>.x`. It is a deprecation notice, not a build failure: your build succeeds and deploys on the retiring runtime until Vercel actually removes it.

Source

Thrown at packages/integrations/vercel/src/index.ts:805

function getRuntime(process: NodeJS.Process, logger: AstroIntegrationLogger): Runtime {
	const version = process.version.slice(1); // 'v18.19.0' --> '18.19.0'
	const major = version.split('.')[0]; // '18.19.0' --> '18'
	const support = SUPPORTED_NODE_VERSIONS[major];
	if (support === undefined) {
		logger.warn(
			`\n` +
				`\tThe local Node.js version (${major}) is not supported by Vercel Serverless Functions.\n` +
				`\tYour project will use Node.js 24 as the runtime instead.\n` +
				`\tConsider switching your local version to 24.\n`,
		);
		return 'nodejs24.x';
	}
	if (support.status === 'default' || support.status === 'available') {
		return `nodejs${major}.x`;
	}
	if (support.status === 'retiring') {
		if (support.warnDate && new Date() >= support.warnDate) {
			logger.warn(
				`Your project is being built for Node.js ${major} as the runtime, which is retiring by ${support.removal}.`,
			);
		}
		return `nodejs${major}.x`;
	}
	if (support.status === 'beta') {
		logger.warn(
			`Your project is being built for Node.js ${major} as the runtime, which is currently in beta for Vercel Serverless Functions.`,
		);
		return `nodejs${major}.x`;
	}
	if (support.status === 'deprecated') {
		logger.warn(
			`\n` +
				`\tYour project is being built for Node.js ${major} as the runtime.\n` +
				`\tThis version is deprecated by Vercel Serverless Functions.\n` +
				`\tConsider upgrading your local version to 24.\n`,
		);

View on GitHub (pinned to 3578d45d34)

Solutions

Upgrade the local/CI Node.js to 24 (the current 'default' runtime): update `.nvmrc`/`.node-version` to 24 and re-run the build — the warning disappears and you build against the supported default.
If you cannot move to 24 yet, move to another major with status 'available' (currently 20 or 22) so you are outside the retirement window.
Update @astrojs/vercel to the latest version so its SUPPORTED_NODE_VERSIONS table matches Vercel's current support policy; the table is adapter-version-dependent.
If you must stay on the retiring major short-term, treat the `support.removal` date in the message as a hard deadline and schedule the upgrade before it — after removal, Vercel rejects or re-routes the runtime.

Example fix

# before (.nvmrc)
20

# after (.nvmrc)
24

# then rebuild
nvm use && pnpm build

Defensive patterns

Strategy: validation

Validate before calling

// before building with the Vercel adapter, fail fast on a bad local Node major
import { execSync } from 'node:child_process';
const major = Number(process.version.slice(1).split('.')[0]);
const supported = { 20: 'available', 22: 'available', 24: 'default' };
if (!supported[major]) {
  throw new Error(`Node ${major} is not 'available'/'default' on Vercel — switch to 24`);
}

Prevention

Pin the Node version used for builds in .nvmrc / .node-version and CI setup-node to the major Vercel lists as 'default' (currently 24), so the local build runtime always matches production.
Add an `engines.node` field (e.g. ">=24") plus `engine-strict=true` (pnpm) or an install script check so mismatched environments fail before build.
Keep @astrojs/vercel updated; its SUPPORTED_NODE_VERSIONS table is the source of the retiring/beta/deprecated statuses and changes as Vercel revises support.
Treat any runtime-support warning from the adapter as CI noise to fix (upgrade Node), not suppress — the retirement date in the message is a real deploy deadline.

When it happens

Trigger: Running `astro build` (or `vercel build`) with @astrojs/vercel while `process.version`'s major is marked `{status:'retiring', warnDate, removal}` in the adapter's SUPPORTED_NODE_VERSIONS table (line 78) and `new Date() >= support.warnDate`. In the current table no major has status 'retiring' (18=deprecated, 20/22=available, 24=default), so this fires only once the adapter ships a 'retiring' entry — e.g. when Vercel announces removal of Node 20 or 22 — or in older/newer adapter versions whose table differs.

Common situations: A local dev machine or CI image pinned to a Node major that Vercel has scheduled for removal (stale `.nvmrc`, `engines.node`, or a Docker/CI image never updated); upgrading @astrojs/vercel to a release whose table newly marks your Node version as retiring; building on Node 20 or 22 after Vercel announces their retirement window.

Related errors

AI-assisted analysis of withastro/astro@3578d45d34 (2026-08-18). Data as JSON: /api/errors/8d7ea30dfb195587. Report an issue: GitHub.