Cuándo no usar n8n

Hace un tiempo escribí sobre la primera vez que usé n8n. Terminaba diciendo que había flujos que crecieron demasiado y automatizaciones que funcionaban perfectamente hasta que alguien tenía que mantenerlas. Lo dejé ahí, en dos líneas.

Este artículo es esas dos líneas desarrolladas. Porque desde entonces he seguido usando n8n casi a diario, y lo que más me ha servido no es haber aprendido a construir flujos más grandes. Es haber aprendido cuándo no construirlos.

La pregunta que casi nadie hace

Cuando alguien evalúa una herramienta de automatización, la pregunta que se hace es “¿se puede hacer esto con n8n?”.

Casi siempre la respuesta es sí. n8n tiene cientos de integraciones, nodos de código, control de flujo, gestión de credenciales. Con suficiente paciencia puedes montar prácticamente cualquier cosa.

Y esa es exactamente la trampa. Que se pueda no significa que convenga.

La pregunta útil es otra: ¿quién va a mantener esto dentro de un año, y con qué herramientas va a averiguar por qué ha dejado de funcionar? Esa pregunta descarta bastantes flujos antes de abrir el editor, y ahorra los peores marrones.

La promesa que no se cumple

El argumento comercial del no-code es que cualquiera puede mantener el flujo. Que al ser visual, deja de ser cosa exclusiva del técnico.

En mi experiencia eso no pasa nunca.

Lo visual se entiende de un vistazo, es cierto. Alguien sin perfil técnico abre un flujo de seis nodos y capta la idea: llega esto, se transforma así, acaba allí. Perfecto. Pero entender lo que hace un flujo y ser capaz de tocarlo sin romperlo son dos capacidades distintas, y la segunda no viene incluida con la primera.

Llega el día de cambiar algo. La persona que no es técnica abre el editor, se encuentra treinta cajas conectadas con líneas que se cruzan, un par de nodos con expresiones dentro, un Switch con cuatro ramas, y cierra la pestaña. Y te escribe a ti.

Así que “lo mantiene cualquiera” acaba siendo “lo mantiene el de siempre”. Solo que ahora el de siempre lo mantiene en un entorno con peor control de versiones, peor trazabilidad y peor depuración que un script de veinte líneas.

Eso no es un fallo de n8n. Es un malentendido sobre qué problema resuelve n8n. No resuelve el problema de quién mantiene la lógica: resuelve el de cuánto tardas en conectar dos sistemas que no se hablan.

Los cinco casos en los que no lo uso

1. Cuando el flujo pasa de unos veinte nodos

Es mi regla más útil y la más discutible, así que la explico.

A partir de cierto tamaño, un flujo deja de ser un diagrama y pasa a ser un programa. Tiene ramas, condiciones, estado, manejo de errores. Es código. Solo que dibujado.

Y el código dibujado pierde todo lo que hace manejable al código escrito: no se lee de arriba abajo, no se busca con un grep, no se revisa en un pull request legible, no se prueba por partes. Un diff de un flujo grande es un JSON que no dice nada a nadie.

Veinte nodos no es una frontera mágica, es donde a mí se me empieza a torcer. Tu número puede ser otro. Lo importante es tener uno y respetarlo, porque el crecimiento de un flujo es siempre gradual: nunca decides construir un monstruo de cuarenta nodos, simplemente le añades uno más cada semana durante ocho meses.

2. Cuando el fallo tiene consecuencias

Aquí es donde más caro sale equivocarse.

La depuración visual es fantástica mientras construyes. Ves los datos pasar de nodo en nodo, corriges, vuelves a ejecutar. Para prototipar no hay nada mejor.

Es mucho peor a las tres de la mañana, cuando algo ha fallado y solo tienes el historial de ejecuciones para reconstruir qué pasó. Sin logs propios, sin un stack trace, sin poder reproducir el estado exacto en local. Y con la incómoda posibilidad de que el flujo se haya quedado a medias, con la mitad del trabajo hecho y sin forma limpia de reintentarlo.

Si un proceso mueve dinero, toca datos que no se pueden duplicar, o tiene que estar terminado antes de que alguien llegue por la mañana, lo escribo en código. Con sus reintentos, su idempotencia y sus alertas. Aburrido, pero se depura.

3. Cuando la integración ya viene hecha de fábrica

Este es el más tonto y el que más veces he visto.

Dos herramientas que ya se conectan entre ellas de forma nativa, y alguien mete un orquestador en medio “por tenerlo todo centralizado”.

Lo que has hecho es añadir una pieza más que se puede caer, unas credenciales más que caducan y un salto más que depurar cuando algo no llega. Si el fabricante mantiene la integración, que la mantenga él.

4. Cuando el trabajo es de datos, no de eventos

n8n brilla orquestando eventos: pasa algo, reacciona, mueve información de A a B.

Se defiende mucho peor procesando volumen. Bucles largos sobre miles de registros, transformaciones pesadas, cruces entre conjuntos grandes. Se puede hacer, va lento y consume memoria que no siempre tienes.

Eso es trabajo de una consulta SQL, un script con la librería adecuada o un proceso por lotes. Diez líneas de Python con pandas hacen en un segundo lo que un flujo tarda en recorrer nodo a nodo.

5. Cuando el volumen convierte la comodidad en factura

Si estás en la nube de n8n, cada ejecución cuenta. Un flujo que se dispara con cada evento de un sistema con mucho tráfico escala en coste de una forma que no se ve venir hasta que llega el recibo.

Autoalojarlo cambia esa cuenta, pero cambia el problema de sitio: ahora tienes un servicio más que actualizar, respaldar y vigilar. Que también es trabajo, aunque no lo factures.

Qué pongo en su lugar

Situación	Alternativa
Tarea periódica sencilla	Un cron y un script
Reacción a un evento externo	Una función serverless con su webhook
Procesado de volumen	Consulta a base de datos o proceso por lotes
Encadenar pasos que pueden fallar	Una cola con reintentos
Dos herramientas del mismo fabricante	Su integración nativa

Ninguna de estas opciones es más moderna que n8n. Varias son bastante más antiguas. Son simplemente más aburridas de mantener, que es justo lo que quieres de la parte que no debe fallar.

Dónde n8n sigue siendo imbatible

No quiero que esto suene a que hay que usarlo menos. Uso n8n casi a diario y no conozco nada que le gane en tres cosas:

Conectar sistemas que no se hablan entre ellos. Es su terreno. Lo que en desarrollo serían días de leer documentación de dos APIs, aquí son un par de horas.

Prototipar un proceso para ver si tiene sentido. Antes de invertir en construir algo bien, montarlo en una tarde y dejarlo correr una semana te dice más que cualquier reunión. Y si no sirve, has perdido una tarde.

Tareas periódicas sin consecuencias. Informes que se envían solos, sincronizaciones cómodas, avisos. Cosas que si un día no corren, no se entera nadie.

Fuera de eso, la pregunta vuelve a ser la del principio: quién lo mantiene dentro de un año.

El error de fondo

Confundir “visual” con “mantenible”.

Son cosas distintas y no van necesariamente juntas. Un diagrama es más fácil de leer que un fichero de código la primera vez. Y bastante más difícil de mantener a partir de la tercera.

Lo que hace mantenible a un sistema no es que se vea bonito, es que se pueda versionar, revisar, probar y depurar. Cuando una herramienta te da lo primero y te quita lo segundo, has hecho un cambio, no una mejora. A veces compensa. A veces no. Saber en qué lado estás es prácticamente todo el criterio.

Y sí, todo esto lo he aprendido rehaciendo flujos que había construido yo.