n8n lanzó la 3.0 en beta: qué revisar antes de actualizar

El 27 de octubre, n8n liberó en beta la versión 3.0, la primera actualización mayor en mucho tiempo. La pensaron para "confiabilidad, estabilidad y seguridad", pero mete cambios que rompen compatibilidad con lo que ya tenés corriendo. Si tu negocio tiene un bot de WhatsApp, un flujo de cotizaciones o cualquier automatización armada sobre n8n, hay un par de cosas puntuales que conviene revisar antes de tocar el botón de actualizar.

Qué cambia de verdad

n8n usa versionado semántico: un número mayor (de 2.x a 3.0) significa que trae cambios que rompen cosas, por eso los fue juntando durante el último año en vez de soltarlos de a uno. Lo más fuerte para quien instala n8n por su cuenta (self-hosted): instalarlo con npm o con npx n8n dejó de estar soportado. De acá en más corre sobre Docker, el sistema que empaqueta la aplicación con todo lo que necesita para andar igual en cualquier servidor —si ya lo corrías en Docker, o en Kubernetes/Helm, esto no te cambia nada—. También se van varios nodos viejos (Function, Function Item, Item Lists, Cron, Interval, el nodo viejo de OpenAI), casi todos con un reemplazo directo, y el tiempo de espera por defecto del nodo Code baja de 5 minutos a 1 (se puede volver a subir a mano).

El Migration Report, antes de tocar nada

Desde la versión 2.39, n8n sumó una pantalla nueva en Configuración que lista qué workflows y qué ajustes del servidor usan algo que la 3.0 cambia o elimina. A varios los corrige solo —guarda el arreglo como una versión nueva del flujo para que alguien la revise y la publique, mientras la versión vieja sigue funcionando sin cortes— y a los que quedaron sin uso hace rato se los puede marcar como "no corregir". Al final exporta un CSV con el resumen completo, así queda registro de qué se tocó y por qué.

Si ya tenés flujos corriendo hoy

La recomendación de n8n tiene sentido para cualquier negocio chico: actualizar primero a la última versión 2.x, revisar el Migration Report entero, hacer un backup completo —no hay vuelta atrás una vez que pasás a 3.x— y recién después probar en una instancia aparte antes de tocar la de producción. Las credenciales y el historial de ejecuciones se mantienen igual. La rama 2.x sigue recibiendo parches de seguridad y de errores críticos durante 12 meses después de que salga la 3.x estable, prevista para principios de diciembre, pero las funciones nuevas de acá en más sólo van a la 3.x. Si todavía corrés la versión 1.x, el soporte se corta el 31 de diciembre de 2026 y no hay salto directo a la 3.0: primero hay que pasar por la 2.x.