¡Hola Devs! El reloj ya está corriendo

Si tu proyecto en Vercel sigue clavado en Node.js 20, apunta la fecha: 1 de octubre de 2026. Después de ese día, Node.js 20 se desactiva en Project Settings y cualquier deploy nuevo va a marcar error.

La buena noticia: los deploys existentes no se ven afectados. Las Serverless Functions que ya están arriba siguen respondiendo normal. El dolor solo aparece cuando haces un deploy nuevo — o sea, cada martes, ¿no? 😅

Y esto no es cuento solo de Vercel. Node.js 20 llegó a su end-of-life oficial el 30 de abril de 2026, sin más parches de seguridad upstream. Vercel solo está aplicando lo que el calendario de Node ya decidió. Si corres Node 20 en cualquier lado — Lambda, Cloud Run, EC2 — estás en la misma barca. Vale la pena auditar todo, no solo el lado Vercel.

Developer checking Vercel project list showing Node.js 20 deprecation warning on terminal Dev Environment Setup

Paso 1: Averigua qué proyectos están en la mira

Antes de salir actualizando todo como loco, saca una lista. Vercel liberó una flag en la CLI justo para esto:

# Instala la Vercel CLI más reciente de forma global
npm i -g vercel@latest

# Lista todos los proyectos que aún usan una versión deprecada de Node.js
vercel project ls --update-required

Ese comando imprime cada proyecto donde la versión de Node.js está fuera de soporte. Córrelo una vez, pásalo a una hoja de cálculo y ya tienes tu backlog de migración.

Paso 2: Actualiza el runtime

Tienes dos caminos limpios:

Opción A — Project Settings UI: Ve a Settings → General → Node.js Version y cámbialo a 24.x.

Opción B — campo engines en package.json (recomendado):

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

El campo engines gana sobre las Project Settings en el próximo deploy — o sea, la versión queda versionada en git. Se acabó la arqueología de "¿quién cambió el runtime en el dashboard?"

Paso 3: No olvides los pins escondidos

El package.json no es el único lugar donde Node 20 puede estar escondido. Dale un grep a estos antes de darlo por cerrado:

  • .nvmrc
  • .node-version
  • Configs de CI (.github/workflows/*.yml, CircleCI, GitLab CI)
  • Dockerfiles locales

Después cambia el runtime local, borra node_modules, reinstala y corre el build completo + tests. Node 24 trae V8 más nuevo, npm actualizado y varias breaking changes en APIs deprecadas — de esas que solo aparecen cuando de verdad corres los tests.

Cloud serverless functions dashboard displaying Node.js runtime version migration settings Programming Illustration

La salida de emergencia: deploy como container

A veces de verdad no puedes actualizar antes de la fecha. Dependencia legacy, un módulo nativo que no compila en Node 24, un contrato con cliente que congela el stack. La respuesta de Vercel es: mándalo como container image.

Pon un Dockerfile.vercel en la raíz del proyecto:

# Fija Node.js 20 como imagen base
FROM node:20-alpine

WORKDIR /app
COPY . .

RUN npm ci

# Tu servidor debe escuchar en $PORT
CMD ["node", "server.js"]

Con ese archivo en su lugar, Vercel buildea y deploya la imagen en cada commit. La versión de Node.js en Project Settings no aplica a containers, así que la deprecación no bloquea estos deploys.

Pero sé honesto con el trade-off: ahora tú eres dueño de la versión de Node.js y de cada parche de seguridad upstream. Node 20 está en EOL — o sea, cero fixes de CVE. El container te compra tiempo, no seguridad.

Ojo con esto

  • Drift silencioso de versión: el engines del package.json sobrescribe el dashboard. Si pusiste 24 en la UI pero engines dice 20, sigues en 20. Confirma con process.version en una línea de log después del deploy.
  • Preview vs. Production: los deploys de preview usan la misma config de runtime. Prueba la actualización en una branch de preview antes de mergear a main.
  • Dependencias nativas: sharp, bcrypt, better-sqlite3 — cualquier cosa con binario compilado necesita rebuild en Node 24. El cambio de ABI te va a morder.
  • Sin rollback a 20 después del 1 de octubre: una vez que la versión se desactiva, no puedes regresar así nomás. Si el container es tu red de seguridad, súbelo antes de la fecha límite.

Developer desk setup with laptop running Dockerfile build for Vercel container deployment System Abstract Visual

Resumiendo el asunto

El EOL de Node.js 20 nunca fue decisión de Vercel — es el calendario upstream de Node alcanzando tu package.json. La migración en sí es trabajo de 15 minutos para la mayoría de los proyectos: bump en engines, actualiza .nvmrc, reinstala, prueba, deploya. Los proyectos que sufren son los que tienen módulos nativos o stacks congelados — y esos necesitan empezar a planear ahora, no el 30 de septiembre.

Próximos pasos recomendados:

  1. Corre vercel project ls --update-required hoy y haz triage de la lista.
  2. Actualiza un proyecto de bajo riesgo de punta a punta como template, luego haz el resto en lote.
  3. Si estás atorado en Node 20, sube el fallback de container temprano y ponte una fecha real para salir de él.

Para leer más

Fuente: Vercel Changelog — Node.js 20 is being deprecated

Este contenido fue redactado con la asistencia de herramientas de IA, basándose en fuentes confiables, y fue revisado por nuestro equipo editorial antes de su publicación. No reemplaza el asesoramiento de un profesional especializado.