n8n no es la navaja suiza que te han vendido

Las plataformas de automatización visual prometen que cualquiera puede conectar sistemas arrastrando cajas. Es una promesa útil en su justa medida y peligrosa fuera de ella.

Hay herramientas que se ponen de moda y herramientas que se convierten en religión. n8n está en ese punto delicado entre ambas. En cada foro técnico, en cada charla de pasillo y en cada consultora que acaba de descubrir los agentes de IA, alguien propone lo mismo: «eso lo montamos en n8n en una tarde». Y a menudo es verdad. El problema no es la tarde. El problema son los tres años siguientes.

Conviene dejarlo claro desde el principio: esto no es un alegato contra n8n. Me apasionan la automatización, los sistemas distribuidos y la concurrencia, y precisamente por eso desconfío de cualquier herramienta que se venda como la respuesta a todo. n8n es un buen martillo. Pero no todo es un clavo, y algunas cosas que parecen clavos son, en realidad, la tubería del gas.

Una caja fuerte con todas las llaves dentro

Pensemos qué es realmente una instancia de n8n en producción: un único proceso que guarda credenciales de APIs, tokens OAuth, cadenas de conexión a bases de datos y accesos a servicios en la nube. Y que, además, puede ejecutar comandos en el sistema operativo. Desde el punto de vista de un atacante, cuesta imaginar un objetivo más rentable.

No es una hipótesis. En diciembre de 2025 se publicó la CVE-2025-68613, con una puntuación CVSS de 9,9 sobre 10. Un fallo en el motor de evaluación de expresiones permitía a cualquier usuario con permiso para crear o editar flujos escapar del sandbox y ejecutar código arbitrario en el servidor. Censys contó entonces más de 103.000 instancias potencialmente vulnerables expuestas en internet.

Un mes después llegó algo peor. En enero de 2026 se hizo pública la CVE-2026-21858, bautizada como «Ni8mare», con la puntuación máxima: 10,0. Esta vez no hacía falta ni una cuenta. Una confusión en el tratamiento de la cabecera Content-Type de webhooks y formularios permitía leer ficheros del servidor, entre ellos la configuración con la clave secreta y la base de datos SQLite de usuarios. Con ambos, un atacante podía fabricar una sesión de administrador y, desde ahí, usar el nodo Execute Command, que hace exactamente lo que su nombre indica.

Hay que ser justos: Horizon3 matizó que la explotación real exige un formulario público sin autenticación, y el equipo de n8n respondió con rapidez. Pero lo relevante es el patrón. Aquella hornada de avisos incluyó cinco CVE encadenables, entre ellas un escape del sandbox del nodo de Python («N8scape») y una escritura arbitraria de ficheros a través del nodo de Git. Y un dato inquietante: según su autor, la prueba de concepto pública de la cadena completa se construyó de forma automatizada con IA unas nueve horas después de la divulgación. El margen para parchear ya no se mide en semanas.

La lección de fondo no es «n8n es inseguro». Todo software tiene fallos. La lección es que n8n concentra el radio de explosión. Un script que solo tiene la credencial que necesita, ejecutado por un usuario sin privilegios, compromete una cosa si cae. Una plataforma que centraliza todas las credenciales de la organización y expone una interfaz web lo compromete todo.

Tu lógica de negocio, en casa ajena

Cuando escribes un script en Python o en Go, tu lógica de negocio vive en un fichero de texto que entiende cualquier intérprete o compilador. Cuando la construyes en n8n, vive en un JSON cuyo único lector competente es n8n. Ese matiz, que parece menor, es una dependencia estructural.

Significa que tu ritmo de actualización lo marca otro. Que un cambio de versión puede romper un nodo del que dependían veinte flujos. Que migrar a otra herramienta no es refactorizar, es reescribir desde cero. Y que los nodos de la comunidad, que se instalan como paquetes npm, abren la puerta a riesgos de cadena de suministro que en un proyecto propio controlarías fijando tus dependencias.

Tampoco conviene olvidar la letra pequeña. n8n no es software libre en el sentido estricto de la OSI: se distribuye con una licencia propia de tipo fair-code que restringe ciertos usos comerciales. Y varias funciones que en un entorno serio son básicas, como el inicio de sesión único, los entornos con control de versiones o el envío de logs a sistemas externos, dependen del plan contratado. Que una empresa quiera cobrar es legítimo. Pero conviene saberlo antes de construir tu operación encima.

Concurrencia: un botón de volumen, no una mesa de mezclas

Aquí es donde, como aficionado a los sistemas distribuidos, más me chirría. En su modo normal, n8n no limita cuántas ejecuciones de producción corren a la vez: el control de concurrencia viene desactivado por defecto. Si lo activas, lo haces con una variable de entorno, N8N_CONCURRENCY_PRODUCTION_LIMIT, que fija un tope global para toda la instancia. Lo que sobra se encola y se atiende por orden de llegada, y las ejecuciones encoladas ni siquiera se pueden reintentar.

Para escalar de verdad hay que pasar al llamado modo cola, con Redis como intermediario y procesos worker aparte, cada uno con su propio límite de trabajos simultáneos. En la versión en la nube, ese modo solo está disponible en el plan Enterprise.

Es decir: tienes un botón de volumen, no una mesa de mezclas. Lo que un sistema concurrente serio necesita es otra cosa:

• Limitar a tres las llamadas simultáneas a una API concreta sin frenar todo lo demás.
• Garantizar que dos ejecuciones no procesen el mismo pedido a la vez.
• Que una operación sea idempotente si se reintenta.
• Aplicar contrapresión cuando el consumidor no da abasto.

Todo eso se puede aproximar en n8n con apaños y nodos auxiliares. En Go es un canal o un sync.Mutex; en Python, un asyncio.Semaphore; en Java, un ExecutorService bien dimensionado. Primitivas explícitas, visibles en el código y comprobables con tests.

Eficiencia y logs: lo que no se ve también cuesta

Cada ejecución de n8n arrastra una maquinaria considerable: un proceso Node.js, la serialización de cada paso en elementos JSON y, por defecto, el guardado de los datos de ejecución en base de datos para poder consultarlos después desde la interfaz. Para diez ejecuciones al día es irrelevante. Para decenas de miles, es memoria, disco y una base de datos que crece sin que nadie la haya diseñado para ello. El mismo trabajo, en un binario de Go de pocos megas o en un script de Python lanzado por un temporizador de systemd, consume una fracción de los recursos.

Con los logs pasa algo parecido, y aquí no hay matices: son la herramienta más importante que existe para depurar. n8n ofrece un historial visual de ejecuciones muy agradable para revisar un fallo concreto. Pero depurar sistemas no consiste en mirar un fallo, sino en correlacionar. ¿Qué pasó en este flujo, en la base de datos y en la API externa en el mismo minuto?

Responder a eso exige logs estructurados, con identificadores de correlación, que viajen a Loki, Elasticsearch o lo que uses, y que puedas filtrar con grep a las tres de la mañana. En un programa propio decides qué se registra, con qué nivel y en qué formato. En n8n dependes de lo que la plataforma decida exponer y, para algunas integraciones, del plan que pagues.

Una interfaz gráfica y una base de usuarios que mantener

n8n necesita un navegador para construir y modificar flujos. Parece una ventaja hasta que intentas trabajar como se trabaja en ingeniería: revisar cambios en una pull request, comparar dos versiones, buscar en todo el repositorio dónde se usa una credencial o desplegar lo mismo en preproducción y producción con un único comando. Un JSON de cientos de líneas con las coordenadas de cada caja en pantalla no es un diff que nadie quiera revisar.

Además, esa interfaz tiene que estar accesible para alguien, lo que obliga a exponer un servicio web y a gestionar usuarios. Y eso nunca sale gratis: altas y bajas cuando alguien entra o se va, roles y permisos, política de contraseñas, segundo factor, integración con el directorio corporativo y auditoría de quién cambió qué.

Cada cuenta es, además, una puerta más. Recordemos que la CVE-2025-68613 solo necesitaba un usuario con permiso para editar flujos. Un cron que ejecuta un script no tiene formulario de inicio de sesión que atacar.

Dos mitos que conviene desmontar

«Es low-code, así cualquiera lo entiende». Es parcialmente cierto. Un flujo de cinco cajas se lee de un vistazo, y eso tiene valor. Pero los flujos reales no tienen cinco cajas: tienen cuarenta, con ramas, bucles, expresiones incrustadas en cada campo y, casi siempre, algún nodo de código JavaScript porque lo visual no llegaba. En ese punto no es más legible que un programa; es un programa repartido en ventanas emergentes.

Y el argumento ha envejecido mal. Hoy cualquiera puede pegar un script de doscientas líneas en un asistente de IA y pedirle que le explique, línea a línea, qué hace. Puede pedirle incluso que lo escriba. La barrera de entrada al código tradicional nunca ha sido tan baja.

«n8n se integra mejor con la IA». Falso. Lo que n8n hace con los modelos de lenguaje es llamar a sus APIs, encadenar respuestas y darles herramientas. Todo eso se hace con cualquier lenguaje: los principales proveedores publican bibliotecas oficiales para Python, TypeScript, Go o Java, y hay marcos maduros para construir agentes. n8n ofrece nodos cómodos para empezar, no una capacidad que falte en otra parte.

La ironía es evidente: la IA hace más fácil que nunca escribir y entender código justo en el momento en que se nos dice que el código es demasiado difícil.

Alternativas: la herramienta adecuada para cada trabajo

Si no es n8n, ¿qué? No hay una respuesta única, pero sí criterios.

Alrededor, piezas que ya existen y funcionan: cron o los temporizadores de systemd para programar tareas; los CronJobs de Kubernetes si ya vives en un clúster; RabbitMQ o Kafka para desacoplar productores y consumidores. Y si de verdad necesitas orquestar flujos largos con reintentos y estado, hay motores pensados para ello, como Temporal o Airflow, que se programan en código. Un script de Bash de veinte líneas sigue siendo, a menudo, la mejor automatización del mundo.

Para qué sí es bueno n8n (y con qué condiciones)

n8n es una buena herramienta cuando se usa para lo que es: un sustituto de pequeños scripts de pegamento entre servicios. Pasar las respuestas de un formulario a una hoja de cálculo, avisar en un canal de chat cuando llega un correo con cierta etiqueta, prototipar en una hora una integración para comprobar si merece la pena construirla bien. Ahí brilla, y sería absurdo negarlo.

Mi propuesta es usarlo, pero con condiciones:

• Que no sea crítico. Si el negocio se para cuando el flujo falla, ese flujo merece ser código con tests.
• Que no esté expuesto a internet más allá de lo imprescindible, y siempre detrás de una VPN o un proxy con autenticación.
• Que se actualice sin demora. El historial de 2025 y 2026 demuestra que el margen se mide en horas.
• Que maneje credenciales mínimas, específicas para cada flujo y con el menor privilegio posible.
• Que se desactiven los nodos peligrosos, como Execute Command, si no son necesarios.
• Que haya pocos usuarios con permiso de edición, y todos de confianza.
• Que el volumen sea bajo y la concurrencia no sea un requisito.
• Que los flujos se exporten y se versionen fuera de la herramienta.
• Que exista un plan de salida: cuando un flujo crece, se reescribe en código antes de que sea tarde.

Entender lo que programamos

Queda una última objeción, menos técnica y más incómoda. Cada capa de abstracción nos ahorra esfuerzo, y eso es bueno. Pero cuando la abstracción sirve para no tener que entender lo que hacemos, el ahorro se paga más tarde.

Si delegamos en cajas visuales y en asistentes de IA la comprensión de nuestros propios sistemas, nos volveremos más torpes sin darnos cuenta. Y llegará el día en que algo falle a las tres de la mañana y nadie en la sala sepa leer lo que hay debajo. Ese día no colapsa un flujo: colapsa la capacidad de la organización para arreglarlo.

La automatización es de lo más bonito de este oficio. Precisamente por eso merece algo más que arrastrar cajas. n8n no es el enemigo. El enemigo es creer que una herramienta nos exime de pensar.

Referencias

• Aviso de seguridad de n8n sobre la CVE-2025-68613
• eSecurity Planet: 103.000 instancias expuestas
• Cyera: descubrimiento de Ni8mare (CVE-2026-21858)
• CSO Online: de la lectura de ficheros al control total
• Rapid7: Ni8mare, N8scape y el resto de CVE encadenables
• Horizon3: explotabilidad real de Ni8mare
• Prueba de concepto pública de la cadena completa
• Documentación de n8n: control de concurrencia
• Documentación de n8n: concurrencia en la nube