Un sitio sano en producción puede ocultar un lanzamiento bloqueado
Vercel deshabilitará Node.js 20 para compilaciones y funciones el 1 de octubre de 2026. Su aviso de deprecación establece una diferencia importante: los despliegues serverless existentes siguen funcionando, pero un proyecto que continúe configurado para Node 20 fallará cuando alguien cree un nuevo despliegue.
Eso hace que la fecha límite sea fácil de malinterpretar. Puede que no haya un incidente de producción el 1 de octubre. El monitoreo puede seguir en verde, los clientes pueden continuar usando la versión actual y el equipo puede asumir que nada cambió. El fallo aparece después, cuando una corrección rutinaria, una reversión, un cambio de configuración o una actualización de seguridad necesita una compilación nueva.
Según comprobamos el 24 de septiembre de 2026, la tabla de versiones de Node.js muestra Node 20 como end-of-life. Node 22 y Node 24 son versiones LTS. Por tanto, Vercel elimina un runtime administrado después de que el proyecto de origen dejara de mantenerlo, no termina antes de tiempo una línea de Node con soporte activo.
La consecuencia operativa es sencilla: trata esto como un problema de preparación para lanzamientos. Cambiar un selector de versión es solo el primer paso. El resultado útil es un despliegue probado que pueda promoverse, revertirse y reconstruirse con el runtime compatible.
Encuentra cada lugar que selecciona el runtime
Vercel indica que el runtime puede definirse en Project Settings o mediante el campo engines de package.json. Su aviso también ofrece vercel project ls --update-required para encontrar proyectos afectados. Empieza ahí y después revisa el repositorio y el sistema de entrega para descubrir otros valores fijados.
Un proyecto puede nombrar Node en .nvmrc, .node-version, una imagen base de contenedor, un paso de configuración de GitHub Actions, un paquete del monorepo o una imagen interna de compilación. Estas declaraciones no coinciden automáticamente. Un desarrollador puede probar con Node 24 mientras CI sigue usando 20. Una configuración de Vercel puede indicar 22 mientras package.json la reemplaza en el siguiente despliegue.
Anota qué declaración controla cada entorno: desarrollo local, comprobaciones de pull requests, compilaciones de producción, tareas en segundo plano y cualquier worker separado. Elimina las discrepancias accidentales en lugar de cambiar solo el primer valor que encuentres. Si un valor antiguo sigue siendo intencional, registra quién es responsable y cuándo se eliminará.
Para organizaciones con varios proyectos en Vercel, haz el inventario por proyecto y no solo por repositorio. Un repositorio puede desplegar varias aplicaciones con configuraciones distintas. A la vez, un paquete compartido puede afectar a varios proyectos aunque su propio código no se despliegue directamente.
Prueba la actualización como un cambio de dependencia
Pasar de Node 20 a 22 o 24 cambia más que process.version. El runtime incluye un motor V8 más reciente, una biblioteca estándar distinta y cambios en el comportamiento de interfaces nativas. Las dependencias también pueden elegir rutas de código diferentes según la versión de Node detectada.
Instala las dependencias desde un checkout limpio con la misma versión del gestor de paquetes y el mismo lockfile que usa CI. Ejecuta lint, comprobaciones de tipos, pruebas unitarias y la compilación de producción. Después prueba los límites donde suelen esconderse las suposiciones sobre el runtime: callbacks de autenticación, carga de archivos, tareas programadas, generación de imágenes, renderizado de correos, migraciones de base de datos y cualquier código que invoque módulos nativos.
Las notas de la versión original de Node 22, por ejemplo, enumeran cambios semver-major que incluyen la eliminación de import assertions y cambios en API criptográficas. Eso no significa que todas las aplicaciones en Node 20 vayan a fallar. Significa que un servidor de desarrollo que arranca no es evidencia suficiente para una migración de producción.
Los complementos nativos merecen una comprobación separada. Un paquete que descarga o compila un binario puede funcionar en un portátil y fallar en la compilación Linux alojada. Revisa el registro de una compilación limpia en Vercel en lugar de aceptar una caché local como prueba. Si la aplicación no usa complementos nativos, registra ese hecho y continúa sin inventar un riesgo.
Demuestra la ruta de lanzamiento antes de la fecha límite
Despliega el runtime compatible en un entorno de preview mientras el despliegue actual de producción continúa activo. Confirma el runtime en la función desplegada, no solo en un archivo de configuración. El aviso de Vercel recomienda comprobar process.version, lo que aporta evidencia directa sobre el entorno que atiende la solicitud.
Ejecuta una pequeña lista de lanzamiento sobre el preview: una página sin autenticar, una ruta autenticada, una lectura y una escritura en cada almacén de datos crítico, una acción en segundo plano o programada y la ruta de error de una dependencia externa. Usa los caminos críticos reales de la aplicación en lugar de copiar esta lista de forma mecánica.
Después prueba la reversión que realmente tienes. Volver a un despliegue ya creado con Node 20 puede seguir funcionando porque Vercel dice que los despliegues existentes no se ven afectados. Reconstruir el mismo commit después del corte es diferente: crea un nuevo despliegue y por eso no puede depender de Node 20. Conserva esa diferencia en el runbook de incidentes.
Ese detalle cambia la preparación del equipo. Un despliegue conocido y estable es una red de seguridad temporal, no una estrategia de compilación reproducible. Si producción necesita una corrección de seguridad después del 1 de octubre, la rama con el runtime compatible ya debe ser capaz de publicarla.
Usa contenedores solo como una excepción temporal explícita
Vercel documenta una ruta con contenedores para los equipos que no pueden completar la actualización antes de la fecha límite. Un proyecto puede mantener una imagen base con Node 20 porque Project Settings no controla la versión de Node dentro de esa imagen.
Esto evita el bloqueo del runtime administrado, pero transfiere la responsabilidad. Vercel señala de forma explícita que el equipo administra la versión de Node del contenedor y sus actualizaciones de seguridad. Como Node 20 ya está end-of-life, un contenedor no equivale a permanecer en un runtime administrado con soporte.
Usa esa ruta solo con un responsable, una fecha de vencimiento y una migración registrada. Documenta el digest de la imagen, la prueba de despliegue y el plan de parches. Sin esos controles, la solución temporal convierte una fecha límite visible en una obligación de mantenimiento invisible.
Qué no cambia
El corte no detiene las funciones serverless existentes con Node 20 el 1 de octubre, según Vercel. No demuestra que una aplicación sea vulnerable y actualizar el runtime no demuestra que la aplicación sea segura.
Tampoco exige que todos los equipos elijan la versión Current más nueva. La guía de versiones de Node indica que las aplicaciones de producción deben usar versiones Active LTS o Maintenance LTS. El objetivo correcto depende del soporte del framework y de las dependencias, pero debe ser una línea con soporte explícito.
La condición de aceptación útil es más limitada y comprobable: el proyecto puede producir una compilación alojada limpia con el runtime compatible elegido, las rutas críticas del preview funcionan, el runtime se verifica en la función desplegada y el equipo entiende qué puede y qué no puede revertirse. Eso evita que una corrección rutinaria descubra la fecha límite de la plataforma por ti.
Escrito por Dandelion Labs