El mundo de la automatización avanza rápido y n8n ha dado un gran salto con el lanzamiento de su versión 2.0. Esta actualización no es solo un cambio estético; trae consigo mejoras significativas en estabilidad, rendimiento y seguridad. Sin embargo, como toda gran actualización, incluye "breaking changes" (cambios que rompen compatibilidad) que requieren atención inmediata si quieres mantener tus flujos de trabajo operativos.
Si estás gestionando una instancia de n8n en producción, es crucial que entiendas qué cambia y cómo te afecta. A continuación, resumimos los puntos críticos de esta migración.
1. Adiós a MySQL y MariaDB como base de datos del sistema
Este es quizás el cambio más impactante para muchas instalaciones self-hosted. En la versión 2, n8n ha eliminado el soporte para MySQL y MariaDB como bases de datos backend (donde n8n guarda sus ejecuciones, flujos y credenciales).
- El cambio: Ahora, las únicas opciones soportadas oficialmente son PostgreSQL (recomendada para producción) y SQLite (para pruebas o cargas muy ligeras).
- La implicación: Si tu instancia actual corre sobre MySQL, necesitarás migrar tus datos a Postgres antes de actualizar, o perderás tu historial y configuraciones.
2. Seguridad reforzada en el nodo "Code"
La seguridad ha sido un pilar central en esta versión. Anteriormente, el nodo Code podía acceder libremente a las variables de entorno. En la v2, esto se ha restringido para evitar fugas de información accidental.
- El cambio: El acceso a variables de entorno desde el nodo Code está bloqueado por defecto.
- La solución: Deberás configurar explícitamente qué variables pueden ser leídas o adaptar tus scripts para manejar las credenciales de forma más segura.
3. Cambios en la ejecución de Python
Si utilizas Python dentro de tus flujos, presta atención. La implementación basada en Pyodide ha sido eliminada.
- El cambio: n8n v2 apuesta por los Task Runners (habilitados por defecto) para ejecutar código, lo que ofrece un aislamiento y rendimiento superior, pero cambia la forma en que se gestionan las dependencias y la ejecución de scripts externos.
4. Gestión de Archivos y Comandos
Para proteger el servidor donde se aloja n8n, se han endurecido los permisos por defecto:
- Los nodos Execute Command y Local File Trigger ahora vienen deshabilitados por defecto. Si tus flujos dependen de scripts de shell o de vigilar carpetas locales, tendrás que reactivarlos manualmente mediante variables de entorno.
- Se ha eliminado el modo de datos binarios en memoria. Esto es una excelente noticia para el rendimiento, ya que evita que el servidor se sature (crash) al procesar archivos grandes, obligando a un manejo más eficiente en disco.
5. Fin del túnel de prueba (--tunnel)
La opción rápida n8n --tunnel, muy usada para exponer webhooks locales durante el desarrollo, ha sido eliminada. Ahora deberás configurar tu propio túnel (usando herramientas como ngrok o Cloudflare Tunnel) si necesitas exponer tu instancia local a internet.
¿Por qué es vital planificar tu migración?
Actualizar a ciegas a la versión 2.0 puede detener tus automatizaciones críticas. La migración de base de datos y la revisión de los nodos de código requieren una estrategia técnica sólida para asegurar que no haya pérdida de datos ni interrupción del servicio.
La estabilidad y las nuevas funciones de la v2 valen la pena, pero el camino debe recorrerse con cuidado.
¿Necesitas ayuda con la migración?
Sabemos que migrar bases de datos y refactorizar flujos de trabajo complejos puede ser un dolor de cabeza y un riesgo para tu operación diaria. No tienes que hacerlo solo.
En DigitalCube, somos expertos en automatización y orquestación de flujos. Podemos auditar tu instalación actual y ejecutar la transición a n8n v2 de forma segura y eficiente.
Agenda un Discovery Workshop con DigitalCube
Preguntas Frecuentes (FAQ)
¿Qué cambios importantes trae n8n v2?
n8n versión 2.0 introduce cambios significativos: eliminación del soporte para MySQL/MariaDB (solo PostgreSQL y SQLite), restricciones de seguridad en el nodo Code, cambios en la ejecución de Python, y deshabilitación por defecto de nodos como Execute Command y Local File Trigger.
¿Puedo actualizar directamente de n8n v1 a v2?
No es recomendable actualizar directamente sin planificación. Si usas MySQL, necesitarás migrar primero a PostgreSQL. Además, deberás revisar y adaptar tus workflows que usen nodos Code, Python, o comandos del sistema.
¿Qué pasa con mis workflows existentes en n8n v2?
La mayoría de tus workflows seguirán funcionando, pero aquellos que dependan de características eliminadas o restringidas (como acceso a variables de entorno desde Code, Pyodide, o comandos del sistema) requerirán modificaciones.
¿Es seguro migrar a n8n v2 en producción?
Sí, pero requiere planificación cuidadosa. Te recomendamos hacer una auditoría completa de tu instalación, probar la migración en un entorno de staging, y tener un plan de rollback antes de actualizar producción.
¿Necesito conocimientos técnicos avanzados para migrar?
Depende de la complejidad de tu instalación. Si tienes workflows simples y usas SQLite, la migración puede ser sencilla. Sin embargo, si usas MySQL, tienes workflows complejos con código personalizado, o dependes de características eliminadas, es recomendable contar con asistencia técnica especializada.