HubSpot retira las funciones serverless del design manager y Node.js 20 en código personalizado: dejan de correr el 1 de febrero de 2027

HubSpot publicó el martes 3 de noviembre de 2026 en su changelog para desarrolladores el retiro de dos piezas que muchas operaciones usan sin saberlo: las funciones serverless del design manager, servidas desde la ruta /_hcms/api/, y los entornos Node.js 20 y anteriores de las acciones de código personalizado en workflows. La empresa explica que esas funciones corren sobre Node.js 18 o 20, versiones que no puede actualizar, y que esos runtimes ya no reciben parches de seguridad.

El cambio tiene fechas cortas. Desde el mismo 3 de noviembre ya no se pueden crear funciones nuevas en el design manager ni acciones nuevas en Node.js 20. El 17 de noviembre de 2026 se bloquea la edición de lo existente y el 1 de febrero de 2027 las funciones del design manager dejan de ejecutarse.

¿Qué cambia y en qué fechas?

• 3 de noviembre de 2026: no se pueden crear funciones serverless nuevas en el design manager. Las existentes todavía se pueden editar. Tampoco se pueden crear acciones de código personalizado nuevas en Node.js 20.
• 17 de noviembre de 2026: se bloquea la edición de las funciones del design manager, incluido el despliegue de paquetes en la beta privada. Tampoco se pueden guardar cambios en acciones Node.js 20 existentes. En ambos casos lo que ya existe sigue corriendo.
• 1 de febrero de 2027: las funciones del design manager dejan de ejecutarse y las solicitudes a /_hcms/api/ fallan. Las páginas, módulos y workflows que dependan de ellas se rompen.

Para las acciones en Node.js 20, el anuncio no fija una fecha de apagado: seguirán ejecutándose, pero sin actualizaciones de seguridad y sin posibilidad de editarlas. Las acciones en Node.js 16 ya estaban deprecadas y tampoco admiten cambios hasta migrarlas.

¿Qué reemplaza a las funciones y a Node.js 20?

Las funciones deben reconstruirse en proyectos de desarrollador, donde se sirven desde /hs/serverless/ en lugar de /_hcms/api/. HubSpot recomienda que los proyectos nuevos usen la versión de plataforma 2026.09. Los proyectos en 2026.03 o 2026.09 ya corren Node.js 24 y no necesitan migrar por ahora. Los que siguen en 2023.1, 2023.2 o 2025.1 corren Node.js 18 o 20 sin parches, ya tienen bloqueados los builds y despliegues, y se actualizan con el comando hs project migrate y un nuevo despliegue.

Las acciones de código personalizado pasan a Node.js 24. HubSpot advierte que esta versión elimina los handlers con estilo callback y que cambian las versiones de librerías, así que no basta con cambiar el runtime: hay que probar cada acción. Según el anuncio, Breeze Assistant puede hacer la actualización de las acciones.

¿Lo puede migrar HubSpot de forma automática?

No en el caso de las funciones. HubSpot indica que no puede migrarlas automáticamente y propone un proceso manual: inventariar cada función y cada página o módulo que la llama, reconstruirla en un proyecto y hacer el cambio una por una con un plan de reversa probado. La guía de migración incluye un prompt para agentes de código con IA que pide aprobación en cada paso. Para las acciones de workflows, el paso a paso es ubicar los workflows que las usan, actualizar a Node.js 24 y probar.

¿Qué significa para las empresas en Chile y Latinoamérica?

En muchas cuentas de HubSpot en Chile y Latinoamérica, las acciones de código personalizado sostienen procesos críticos: validar un RUT, consultar un ERP, calcular comisiones, asignar dueños o sincronizar datos con sistemas de facturación locales. Suelen haber sido escritas por un partner o un desarrollador que ya no está, y nadie las revisa mientras funcionan. Lo mismo ocurre con formularios o calculadoras del sitio que llaman a funciones serverless del CMS. El riesgo no es solo técnico: un workflow que deja de poder editarse congela una regla de negocio justo cuando hay que cambiarla.

Análisis de Revenue Hub

Este anuncio es un recordatorio de que la deuda técnica en el CRM se acumula en silencio. La mayoría de los equipos comerciales no sabe cuántas acciones de código tiene ni qué hace cada una, y el 17 de noviembre es la fecha que importa: desde ese día cualquier ajuste a una regla escrita en Node.js 20 exige migrar primero. Si el cierre de año trae cambios de territorios, comisiones o precios, ese trabajo se cruza con la migración.

La recomendación concreta es hacer el inventario esta semana. Primero, listar los workflows con acciones de código y su versión de Node, partiendo por los que tocan negocios, cotizaciones y facturación; una revisión como la que describimos para encontrar workflows olvidados en HubSpot sirve de base. Segundo, revisar el sitio en busca de llamadas a /_hcms/api/ y dar dueño y fecha a cada una antes de febrero. Tercero, probar cada acción migrada en un entorno de prueba antes de activarla en producción, porque el cambio de callbacks rompe código que hoy parece estable.

Para equipos que administran varias cuentas o necesitan replicar workflows entre un sandbox y producción durante la migración, PortalSync de Revenue Hub Latam permite copiar workflows y propiedades entre portales. Y si una integración ya muestra síntomas, la guía sobre cómo saber si una integración de HubSpot dejó de funcionar ayuda a ordenar el diagnóstico.