El lado oscuro de n8n: una crónica de lo que no siempre se cuenta

Cuando escuché por primera vez el nombre n8n, pensé que se trataba de una herramienta de automatización de ciencia‑ficción, algo tan complejo que tendría una curva de aprendizaje digna de un máster. Resultó ser algo mucho más cercano: una herramienta de automatización visual, de código abierto, que promete que cualquier persona, desde un estudiante técnico hasta el CEO que se empeña en “optimizar” todo, puede arrastrar y soltar bloques para conectar Google Sheets, Slack, GitHub y mil servicios más.

Al principio, me sentí como un niño con una caja de LEGO: cientos de piezas de colores, manuales claros, una comunidad que comparte trucos en repositorios en GitHub donde cualquiera puede añadir su propio ladrillo. Todo eso, sin pagar nada, con la promesa de que si alguna pieza no encajaba, la podías modificar tú mismo porque la licencia lo permite.

Así que, con el entusiasmo de quien descubre una nueva juguetería, instalé n8n y ya tenía una interfaz web donde dibujar flujos como quien dibuja un mapa. Empecé a pensar en como crear una integración que gestionase tareas automatizadas en mi homelab.

A medida que el proyecto crecía, empecé a necesitar más que “un par de pasos”. Quería que la solución fuera robusta, que pudiera escalar en un cluster de Kubernetes, que aprovechara máquinas con GPUs para procesar videos y que, sobre todo, no fuera el único punto de falla del sistema. Ahí fue cuando comencé a toparme con esas “pequeñas” limitaciones que, en la práctica, se convierten en muros.

En n8n el “master” es tanto la cara bonita que vemos en el navegador como el motor que ejecuta los flujos. En un escenario ideal, la UI debería vivir en una máquina ligera, mientras que el trabajo pesado se reparte entre varios workers. En n8n, sin embargo, el master no tiene botón de “apágame la ejecución”. Cada vez que un usuario lanza un workflow, ese mismo proceso consume CPU, RAM y tiempo de la máquina que también está sirviendo la interfaz.

Imagina que tu servidor master es un servidor con recursos limitados que usas también para revisar tickets. Un día decides que un flujo de procesamiento de imágenes, que necesita ffmpeg, se ejecutará allí porque no tienes otro nodo disponible. De repente, la UI se vuelve lenta, los tickets se quedan “pendientes” y los usuarios empiezan a quejarse porque la pantalla se congela cada vez que alguien abre el editor. Lo peor: no hay una variable de entorno o una opción en la configuración que diga “solo UI, nada de ejecución”.

Supongamos que tienes tres tipos de máquinas en tu clúster:

• Worker A: CPU rápida, sin GPU, ideal para consultas a APIs.
• Worker B: Equipado con GPU, perfecto para transcodificar videos.
• Worker C: Grandes capacidades de almacenamiento

En n8n, cuando envías un workflow a la cola, cualquier worker libre lo toma. No hay forma de decir “este flujo necesita GPU, por favor, pásalo al worker B”. El resultado es que a veces el nodo que debería procesar un video termina en el worker A y falla porque le falta ffmpeg o la GPU. Otras veces, un script de Python que requiere de una libreria específica y se ejecuta en un contenedor que solo tiene Node.js, y el flujo se rompe.

Para intentar sortear el problema, se pueden crear “instancias separadas de n8n”, cada una con su propia cola (Redis, RabbitMQ) y configuran un router externo que decide a cuál enviar la solicitud. Pero entonces pierdes la simplicidad de una única URL de API y tienes que mantener varios servicios, bases de datos de colas y scripts de enrutamiento. El encanto del drag‑and‑drop empieza a desvanecerse bajo capas de infraestructura.

La imagen oficial de n8n está pensada para ser ligera: Node.js, algunas librerías de base y los nodos preconstruidos. Eso está genial para flujos que sólo hacen peticiones HTTP o manipulan JSON, pero rápidamente te encuentras con la necesidad de algo más “pesado”.

Por ejemplo, en un proyecto queria realizar un analisis de reconocimiento de objetos a partir de videos. Necesitaba ffmpeg, imagemagick y una versión de Python muy concreta. La única forma de conseguirlo era crear un Dockerfile propio, copiar la imagen de n8n y, sobre ella, instalar todos esos paquetes.

Hasta aquí, todo bien. Pero cada vez que n8n lanza una nueva versión (y lo hace con bastante frecuencia), nuestro Dockerfile se vuelve obsoleto: debo volver a construir la imagen, probar que todo sigue funcionando y, a veces, solucionar conflictos entre versiones de librerías. En la práctica, el mantenimiento de esa imagen personalizada se convierte en una tarea a tiempo completo, muy lejos de la idea “solo arrastras y sueltas”.

En la vida real, la mayoría de los secretos que necesitas están dentro de tu infraestructura: tokens de Kubernetes ServiceAccount, claves de Vault, credenciales de una base de datos interna, etc. n8n, sin embargo, está diseñado pensando en “conectar con servicios externos”. En la sección de credenciales puedes crear una conexión a diversos servicios externos, pero no hay un modo nativo de decir “usa el ServiceAccount del pod donde estoy corriendo”.

Imagina que quieres que un workflow lea secretos de HashiCorp Vault usando la autenticación de Kubernetes. Tendrías que crear un nodo “HTTP Request” que manualmente construya el token, lo inserte en los headers y gestione la renovación. O peor, guardar la ruta del token en una variable de n8n, lo que implica dejar la información en texto plano dentro de la base de datos de n8n. Esto no solo es anti‑patrón, sino que también rompe con políticas de seguridad que exigen que los secrets nunca salgan de los mecanismos de gestión propios del clúster.

La versión self‑hosted de n8n es completamente libre, y eso es un punto a favor. Pero muchas de las funciones que realmente importan están reservadas a planes de de pago. La empresa ha optado por un modelo “open‑source + feature‑gating”: el código está disponible, pero para que sea realmente útil en producción tienes que pagar una suscripción o migrar a su SaaS.

N8n es, sin duda, un chico encantador: fácil de usar, con una comunidad que comparte recetas, y con la ventaja de ser open‑source. Pero como todo buen personaje de novela, tiene sus defectos. No saber apagar la ejecución del master, no poder elegir dónde corre cada tarea, obligarte a vivir dentro de una sola imagen Docker, no integrar los secretos internos de tu clúster y esconder funciones clave detrás de un modelo de pago son rasgos que, si tu historia necesita robustez y escalabilidad, tendrás que sortear.

Si tu proyecto es una pequeña prueba de concepto o una automatización interna que no necesita GPUs, bases de datos especiales o auditoría exhaustiva, n8n puede ser el héroe que te salve el día. Pero si ya estás soñando con un ecosistema cloud‑native, con workers que saben exactamente qué hardware tienen que usar, y con una gestión de credenciales digna de un banco, quizás sea momento de mirar más allá o, al menos, estar preparado para escribir algunos capítulos extra en la historia.

Al final, la elección depende de cuánto estés dispuesto a invertir en “hacer que el chico con encanto se comporte como un profesional”. Yo, por mi parte, sigo usando n8n para los flujos rápidos, pero siempre tengo a mano mi “caja de herramientas” alternativa para cuando la trama se vuelve más compleja.