n8n 3.0 llega en octubre: qué cambia y cómo preparar tus flujos
n8n publicó los cambios incompatibles de su versión 3.0, prevista para octubre de 2026: Docker obligatorio en instalaciones propias, nodos antiguos eliminados y nuevos valores por defecto. Qué revisar y cómo migrar sin cortar tus automatizaciones.
9 min de lectura Investigado y publicado con Claude
En este artículo
n8n 3.0 está en camino y no es una actualización más: según la documentación oficial de cambios incompatibles, la nueva versión mayor está prevista para octubre de 2026 y trae cambios que pueden frenar flujos que hoy funcionan. Si tu pyme usa n8n instalado en un servidor propio, lo más importante es esto: la versión 3.0 solo va a funcionar con Docker, elimina más de veinte nodos antiguos y cambia varios valores por defecto. Antes de actualizar, revisá el Migration Report de tu instancia y planificá la migración con tiempo.
En esta nota te contamos qué cambia, a quién afecta y cómo prepararte sin cortar las automatizaciones que sostienen tu operación diaria.
Qué es n8n 3.0 y cuándo llega#
n8n describe la 3.0 como una versión "operativa": su objetivo no es sumar grandes funciones nuevas, sino limpiar componentes viejos y aplicar cambios incompatibles que venían anunciados. En su guía interna para desarrollar la versión 3, el equipo explica que trabaja con dos ramas en paralelo: la rama principal, donde siguen las versiones 2.x, y una rama 3.x que solo recibe cambios incompatibles. También publica imágenes de Docker nocturnas con la etiqueta v3-nightly para probar la versión antes del lanzamiento.
Al 5 de octubre de 2026, la 3.0 todavía no está publicada. En la página de versiones de n8n en GitHub, la última versión estable es la 2.41.7, del 5 de octubre, y la 2.42.3 figura como versión preliminar. Es decir: tenés unas semanas para prepararte, pero no muchas.
Los cambios que más impactan en una pyme#
La lista completa es larga. Estos son los cambios que, en la práctica, más pueden afectar a una empresa que usa n8n para ventas, atención o administración.
1. Docker pasa a ser obligatorio#
La documentación es clara: "n8n autoalojado va a requerir un despliegue basado en Docker" y la 3.0 "ya no va a soportar instalaciones ejecutadas con npm o npx n8n" (fuente). Si instalaste n8n directamente con npm en un servidor o en una PC de la oficina, vas a tener que migrar a Docker antes de pasar a la 3.0.
2. Se eliminan nodos antiguos#
n8n 3.0 quita una serie de nodos heredados. Si tus flujos los usan, van a dejar de funcionar hasta que los reemplaces. Los principales, con su reemplazo recomendado según n8n:
| Nodo que se elimina | Reemplazo recomendado |
|---|---|
| Function y Function Item | Code |
| Item Lists | Split Out, Aggregate, Sort, Limit, Remove Duplicates o Summarize |
| Cron e Interval | Schedule Trigger |
| HTML Extract | HTML |
| Read PDF | Extract from File |
| iCalendar | Convert to File (ICS) |
| Read/Write Binary File | Read/Write Files from Disk |
| OpenAI (heredado), OpenAI Assistant, OpenAI Model | Nodo OpenAI actual u OpenAI Chat Model |
| Workflow Trigger | n8n Trigger |
| Manual Chat Trigger | Chat Trigger |
| Chat Messages Retriever | Chat Memory Manager |
| Binary Input Loader, JSON Input Loader, GitHub Document Loader | Default Data Loader |
| Nodos separados de inserción y carga en vector stores | Nodos combinados Simple, Pinecone o Supabase Vector Store |
Hay además algunos nodos sin reemplazo directo: Motorhead, Zep, SerpApi y Orbit. Si dependés de alguno, conviene buscar una alternativa ya.
Muchas automatizaciones armadas hace dos o tres años usan Function, Cron o Item Lists, porque eran los nodos habituales en ese momento. Por eso este punto es el que más trabajo suele dar.
3. Tareas de código con menos tiempo#
El tiempo máximo por defecto de los task runners, que ejecutan el código de nodos como Code (la variable N8N_RUNNERS_TASK_TIMEOUT), baja de 300 segundos (5 minutos) a 60 segundos (1 minuto), según la documentación. Si tenés un nodo de código que procesa planillas grandes o muchos registros, podría empezar a cortarse. Se puede ajustar con esa misma variable.
4. Nodos de la comunidad no verificados, desactivados#
El valor por defecto de N8N_UNVERIFIED_PACKAGES_ENABLED pasa de true a false. En la práctica, los nodos comunitarios que no están verificados por n8n dejan de estar habilitados salvo que lo actives a propósito. Es un cambio a favor de la seguridad, pero puede romper flujos que usan integraciones de terceros.
5. Otros cambios de configuración#
- El modo de datos binarios
defaultdeja de ser válido: las instancias que lo usen pasan afilesystemal actualizar. - En el primer arranque, la carpeta
~/.n8n/binaryDatase renombra como~/.n8n/storage. - Bajan los límites del nodo de compresión: el tamaño máximo descomprimido pasa de 2 GiB a 256 MiB y la cantidad máxima de archivos dentro de un ZIP, de 5.000 a 1.000.
- La protección contra SSRF suma bloqueos para el rango
100.64.0.0/10y rangos de transición de IPv6. Si tus flujos consultan servicios internos en esas redes, vas a tener que habilitar excepciones conN8N_SSRF_ALLOWED_IP_RANGESoN8N_SSRF_ALLOWED_HOSTNAMES. - Se elimina la variable
N8N_PRE_EXECUTE_ERROR_CREATES_EXECUTION.
Todos estos datos salen de la lista oficial de cambios de la 3.0.
6. Funciones que se quitan o se apagan#
- Importar flujos desde una URL: se elimina. Siguen disponibles copiar y pegar, importar desde archivo, la línea de comandos y la API de n8n.
- Pestaña "Ask AI" del Code node: se elimina.
- Chat Hub: queda desactivado por defecto. Las sesiones se conservan y, si lo usás, podés volver a habilitarlo agregando
chat-hubaN8N_ENABLED_MODULES.
¿Y si uso n8n Cloud?#
La documentación de cambios está pensada sobre todo para instalaciones propias: el requisito de Docker, por ejemplo, aplica a n8n autoalojado. Aun así, la eliminación de nodos afecta a los flujos sin importar dónde corran. Si usás n8n Cloud, revisá igual qué nodos usan tus flujos y reemplazá los que se van a eliminar.
Qué hacer ahora#
Estos son los pasos que recomendamos para llegar a la 3.0 sin sorpresas:
- Abrí el Migration Report. Según n8n, en Settings > Migration Report vas a ver la lista de nodos y módulos afectados en tu instancia. Es el mejor punto de partida.
- Hacé un inventario de flujos críticos. Anotá cuáles sostienen ventas, cobros, atención por WhatsApp o facturación. Esos se revisan primero.
- Reemplazá los nodos que se eliminan mientras seguís en 2.x. Los reemplazos ya existen en la versión actual, así que podés migrar flujo por flujo, probar y recién después actualizar.
- Si instalaste con npm, pasá a Docker. Es el cambio más grande en infraestructura y conviene hacerlo antes, con calma.
- Hacé un backup completo. Base de datos, carpeta de datos de n8n, variables de entorno y credenciales. Sin backup, no actualices.
- Revisá las variables de entorno. Sobre todo el timeout de tareas, los paquetes comunitarios, la protección SSRF y el modo de datos binarios.
- Probá en un entorno de prueba. Las imágenes
v3-nightlypermiten ensayar la actualización en una copia de tu instancia, nunca en producción. - No actualices el primer día. Esperá a que salgan las primeras correcciones de la 3.0, salvo que n8n publique un aviso de seguridad que lo justifique.
Mientras tanto, mantené tu versión 2.x al día: hace pocos días te contamos que n8n corrigió 14 vulnerabilidades en su versión self-hosted, y esas correcciones siguen siendo prioritarias aunque estés planificando el salto a la 3.0. Si querés repasar lo que trajo la rama actual, también tenemos el análisis de las novedades de n8n 2.42 para crear flujos con agentes de IA.
Por qué conviene adelantarse#
Las automatizaciones suelen fallar en silencio: un flujo que deja de ejecutarse un fin de semana puede significar pedidos sin registrar, mensajes de WhatsApp sin responder o cobros sin conciliar. Si además tus flujos usan agentes de IA o conectan con APIs de pago, como los que analizamos en la nota sobre los nuevos precios de WhatsApp Business API, un corte puede tener costo directo.
Prepararse ahora, con la versión 2.x todavía estable, permite hacer los cambios de a uno, probarlos y documentarlos. Esperar a que la 3.0 se instale sola, por ejemplo con una imagen de Docker que apunta a latest, es la forma más rápida de encontrarse con flujos rotos.
Preguntas frecuentes#
¿Cuándo sale n8n 3.0?#
n8n indica que la versión 3.0 está prevista para octubre de 2026. Al 5 de octubre todavía no estaba publicada y la última versión estable era la 2.41.7.
¿Mis flujos van a dejar de funcionar?#
Solo si usan nodos que se eliminan (como Function, Cron o Item Lists), dependen de valores por defecto que cambian o corren en una instalación hecha con npm. El Migration Report de tu instancia te muestra qué está afectado.
¿Puedo seguir instalando n8n con npm?#
No en la 3.0. La documentación oficial indica que la versión 3.0 requiere un despliegue con Docker y deja de soportar npm y npx n8n.
¿Tengo que actualizar apenas salga?#
No es obligatorio hacerlo el primer día. Lo recomendable es preparar los flujos en 2.x, probar en un entorno aparte y actualizar cuando la versión esté estabilizada, sin dejar de aplicar los parches de seguridad de la rama actual.
¿Qué pasa con los nodos comunitarios que instalé?#
En la 3.0, los paquetes comunitarios no verificados quedan desactivados por defecto. Podés volver a habilitarlos con N8N_UNVERIFIED_PACKAGES_ENABLED=true, pero conviene revisar primero si son confiables.
Te ayudamos con la migración#
Si querés que revisemos tu instancia, migremos tu instalación a Docker o reemplacemos los nodos que se eliminan, en Mark-Co Digital podés ver nuestro servicio de actualización de n8n self-hosted y el de actualización y mantenimiento de flujos, o escribirnos desde nuestra página de contacto.
