La beta de n8n que te deja exportar el reporte de migración en CSV
n8n lanzó en beta la versión 2.45.2 con una función que agencias y equipos de TI venían pidiendo: exportar el reporte completo de cada migración en un archivo CSV, sin capturas de pantalla ni copiar datos a mano.
Qué trae la beta 2.45.2 y cómo usarla como bitácora de control de cambios
La nueva beta deja exportar en CSV el reporte completo de cada migración, pensado para quien administra varias instancias de n8n self-hosted.
n8n, la plataforma de automatización de flujos de trabajo, confirmó el 22 de octubre de 2026 el lanzamiento de la versión beta 2.45.2. La novedad que más le interesa a quien administra instancias de n8n self-hosted de varios clientes: ya se puede exportar en un archivo CSV el reporte completo de cada migración, sin abrir capturas de pantalla ni copiar datos a mano.
En resumen
n8n publicó el 22 de octubre de 2026 la beta 2.45.2, que permite exportar en CSV el reporte completo de cada migración, además de dos correcciones internas: las políticas de tipos y el nodo Postgres. Es una pre-release, así que conviene probarla en un ambiente de pruebas antes de llevarla a producción.
- Exportar el reporte de migración en CSV
- Versión beta, no estable todavía
- Publicada el 22 de octubre de 2026
- Dos correcciones técnicas adicionales en el núcleo y en el nodo Postgres
Qué trajo exactamente la beta 2.45.2
La nota de lanzamiento de n8n en GitHub marca la 2.45.2 como pre-release y la fecha el 22 de octubre de 2026. Trae una función nueva y tres correcciones: exportar el reporte de migración en CSV, una corrección en cómo el núcleo lee las políticas de disponibilidad de tipos, una corrección en el nodo de Postgres y una actualización de logos en la pantalla de confirmación de OAuth y en los correos de la instancia.
| Tipo | Cambio | Referencia |
|---|---|---|
| Función nueva | Exportar el reporte de migración como archivo CSV | #41670 |
| Corrección | El núcleo lee las políticas de disponibilidad de tipos desde memoria en el momento de aplicarlas | #41621 |
| Corrección | El nodo de Postgres ya no sobrescribe las políticas de tipos globales de la base de datos | #41666 |
| Corrección | Se actualizaron los logos en la pantalla de confirmación de OAuth de credenciales y en los correos de la instancia | #41637 |
Cómo funciona el nuevo reporte en CSV
Antes de esta beta, revisar una migración significaba abrir capturas de pantalla y copiar datos a mano para dejar constancia de lo que cambió. Con la 2.45.2, ese mismo reporte que n8n ya generaba se puede descargar directo en un archivo CSV, listo para guardar o compartir con el equipo o el cliente.
Se ejecuta la migración
n8n corre el proceso de migración igual que antes; nada cambia en este paso.
n8n genera el reporte
Al terminar, n8n arma el reporte completo de lo que se migró, como ya hacía en versiones anteriores.
Se descarga en CSV
Con la beta 2.45.2, ese reporte se exporta directo a un archivo CSV, sin capturas de pantalla ni copiar datos a mano.
Por qué esto importa más de lo que parece
Un CSV se puede archivar, comparar y auditar después; una captura de pantalla no. Ese es el salto real entre la 2.45.1 y la 2.45.2.
Las otras correcciones de la beta
La 2.45.2 corrige dos comportamientos internos, según el changelog. Primero, el núcleo ahora lee las políticas de disponibilidad de tipos desde memoria justo en el momento de aplicarlas, no antes. Segundo, el nodo de Postgres deja de sobrescribir los tipos globales (pgtypes) de la base de datos, un comportamiento que podía afectar a otros flujos que comparten la misma conexión.
Por qué le importa a agencias y equipos de TI con varias instancias
Quien administra instancias de n8n self-hosted para varios clientes gana un respaldo concreto antes de cada actualización en producción. El CSV del reporte de migración puede guardarse como bitácora de control de cambios por cliente, en vez de depender de capturas de pantalla o de copiar datos a mano cada vez que se actualiza una instancia.
Una agencia con cinco instancias de clientes
Este ejemplo es ilustrativo: muestra cómo un equipo de TI que administra varias instancias de n8n self-hosted puede usar el CSV de cada migración como respaldo antes de actualizar en producción, en vez de depender de anotaciones manuales.
Cómo probar la beta sin arriesgar producción
Levanta un ambiente de prueba
Instala la beta 2.45.2 en una instancia de prueba, separada de las instancias en producción de tus clientes.
Corre una migración y exporta el CSV
Repite el flujo de migración habitual y descarga el nuevo reporte en CSV para revisar que los datos salgan completos.
Verifica el nodo Postgres y las políticas de tipos
Si usas el nodo Postgres, confirma que ya no sobrescribe los tipos globales de tu base de datos, una de las correcciones de esta beta.
Decide cuándo pasar a producción
Mientras n8n no marque la 2.45.2 como estable, mantén las instancias de tus clientes en la versión actual y usa la beta solo para pruebas.
Es beta, no la versión estable
n8n marca la 2.45.2 como pre-release en GitHub. Pruébala primero en un ambiente de prueba, no en las instancias de producción de tus clientes.
Qué significa para México y Latinoamérica
En México y Latinoamérica, las agencias que automatizan procesos para varios clientes con n8n self-hosted suelen cargar a mano el registro de cada actualización. Lo mismo pasa en equipos de soporte y SaaS que migran datos entre entornos, o en ecommerce que depende de flujos de n8n para sincronizar pedidos e inventario: un CSV por migración es un respaldo más fácil de archivar y revisar que una serie de capturas de pantalla.
- Guarda un CSV del reporte de migración antes de cada actualización, por cliente
- Archívalo junto con la fecha y la versión de n8n a la que migraste
- Prueba toda beta en un ambiente aislado antes de tocar instancias en producción
- Si usas el nodo Postgres, revisa que los tipos de datos sigan correctos tras actualizar
- Documenta el proceso para que cualquiera en el equipo pueda auditar un cambio después
Preguntas frecuentes
¿Ya puedo usar la exportación a CSV del reporte de migración en n8n?
Sí, pero solo en la versión beta 2.45.2, publicada el 22 de octubre de 2026. n8n todavía no la marca como estable, así que conviene probarla en un ambiente de pruebas antes de usarla en instancias de clientes en producción.
¿Qué otras correcciones trae la beta 2.45.2 de n8n?
Trae dos correcciones técnicas: el núcleo ahora lee las políticas de disponibilidad de tipos desde memoria en el momento de aplicarlas, y el nodo de Postgres ya no sobrescribe los tipos globales de la base de datos. También actualizó los logos de la pantalla de confirmación de OAuth y de los correos de la instancia.
¿Para qué sirve el CSV del reporte de migración?
Sirve como respaldo del estado de una migración sin tener que tomar capturas de pantalla ni copiar datos a mano. Un equipo de TI o una agencia puede guardarlo como bitácora de control de cambios antes de actualizar una instancia en producción.
¿Esta actualización es solo para quienes usan n8n self-hosted?
El anuncio de n8n no distingue entre self-hosted y n8n Cloud; el changelog solo dice que el cambio está en el núcleo de n8n. El caso de uso de bitácora de control de cambios aplica sobre todo a quienes administran varias instancias self-hosted, como agencias y equipos de TI.
¿Qué riesgo hay en usar una beta de n8n en producción?
El riesgo es que una pre-release puede tener fallos que todavía no se detectaron, por eso n8n la marca como 'Pre-release' en GitHub. La recomendación es instalarla primero en un ambiente de prueba y esperar a la versión estable antes de actualizar instancias de clientes.
¿Administras varias instancias de n8n?
En Zadrig Technology ayudamos a agencias y equipos de TI a automatizar y mantener sus flujos de n8n sin arriesgar producción. Agenda una demostración y te mostramos cómo armar un control de cambios sólido.
Agenda tu demostración por WhatsApp
