Este es el primer artículo de una serie en Iberasync sobre n8n, automatizaciones e IA. Las automatizaciones llevan en el mundo de las empresas muchísimos años, aunque la fiebre exagerada de la IA ha puesto sobre el foco este tipo de aplicaciones. ¿Tienen sentido? Como todo en esta vida, depende.
n8n, ¿por qué es una buena elección?
n8n suele aparecer por un motivo muy poco glamuroso: había demasiados trabajos pequeños que no justificaban montar un servicio a medida, pero que tampoco podían seguir haciéndose a mano.
En ocasiones aparece también en una conversación automatismo con Power Automate que alguien quiere cambiar porque, no nos engañemos, son una autentica castaña, con todos mis respetos a las castañas.
El patrón se repite:
- Tenemos esto y queremos mejorarlo.
- Un SaaS nuevo entra por compras (“es barato y trae integración con todo”).
- La integración “con todo” es… un webhook y un PDF con ejemplos.
- Se monta una ñapa con Zapier/Make/lo-que-sea.
- Crece. Se vuelve crítica. Nadie sabe dónde está. Y un día falla, es muy caro, etc.
n8n suele aterrizar cuando alguien dice: “necesito automatizar, pero quiero control y suficiente potencia, sin desarrollar algo a medida”. Control de datos, de red, de credenciales, de costes, de lógica. Y sí, también control de “no quiero pagar 14 integraciones distintas para hacer lo mismo” o «tampoco quiero desarrollar un stack de código para procesos manuales secundarios que cambian a menudo».
¿Por qué sí a n8n? Te da control, es fiable, es barato (CE) y puedes hacer viguerías con bastante autonomía.
Ahora bien: automatizar no es magia. Automatizar es convertir trabajo humano en software (si low code, pero no te olvides que por debajo esos dibujitos son puro código). Y el software también se rompe, se mantiene y da otra serie de problemas que tendrás que afrontar.
Qué es n8n y para qué sirve
n8n (se suele leer “en-eight-en”) es una plataforma de automatización basada en workflows (flujos) compuestos por nodos. Cada nodo hace una cosa: recibir un evento, llamar a una API, transformar datos, decidir una rama, escribir en una base de datos, mandar un Slack, Teams, etc.
Si vienes del mundo dev, piensa en n8n como un runtime que ejecuta grafos de tareas con estado mínimo. Si vienes del mundo ops, piensa en un “orquestador de integraciones” con UI. Si vienes del mundo negocio, piensa en “dejar de hacer copy-paste” o repitiendo muchas veces lo mismo.
¿Para qué sirve de verdad?
- Integración entre herramientas: CRM → ERP, formularios → tickets, pagos → facturación, etc.
- Notificaciones y alertas: cuando pasa X, avisa por Slack/email/Teams.
- ETL ligero: extraer datos de una API, transformarlos y cargarlos en Sheets/DB/BI.
- Backoffice: automatizar tareas internas repetitivas (altas, validaciones, reportes).
- Automatizaciones con IA: resumir, clasificar, extraer entidades, generar borradores…
¿Para qué NO sirve (o no debería)? Para esconder un sistema core detrás de 40 nodos sin control de cambios, sin tests y sin observabilidad. Eso no es “low-code”, eso es ser un chapucero.
Ediciones y despliegue: Cloud vs self-hosted
La primera elección que vas a tener que tomar es esta (aparte de probarlo en tu portátil, para esto tienes 200 tutoriales y chat GPT te lo monta en 2 segundos, aqui hablamos de cosas mas serias).
Todos dicen que elegir es fácil: “Cloud si quieres rapidez, auto alojado si quieres control”. Más o menos. El tema es que la decisión no va de gustos; va de responsabilidades.
Además debes tener en cuenta de que dispones a nivel de infraestructura, que nivel de SLA quieres etc. Si tienes un sistema on-prem de virtualización con sus copias etc, lo tienes facil, sino tendrás que plantearte la parte On-Prem. E insisto, desplegarlo en tu portátil o en el ordenador ese de la esquina de la oficina que todos usan para escanear no es profesional.
n8n Cloud
La opción Cloud es la ruta del ascensor: te subes y llegas. Te olvidas de servidores, backups, upgrades (bueno esto depende también) y de pelearte con Docker. A cambio:
- Pagas por plan/uso.
- Tienes límites por plan (ejecuciones, concurrencia, retención de logs, etc.).
- Dependes de su disponibilidad y de su política de cambios.
- Los datos “pasan por fuera” .
Aqui tienes las condiciones de N8N y los precios: n8n Plans and Pricing – n8n.io
¿Cuándo lo elegiría yo? Cuando necesito validar valor rápido, el dato no es ultra sensible, y el equipo no quiere (o no puede) operar otra pieza de infraestructura.
n8n self-hosted
Aqui nuevamente se abren dos rutas, sevidores on-prem o servidores en la nube (puedes consultar Fundamentos Computacion en la nube para saber mas ), ambas llevan mantenimiento del sistema solo que si te va s ala nube, puedes ahorrarte el mantener el hierro.
Aqui el tema va de me lo monto yo (en cualquiera d elas modalidades). Puedes desplegarlo en tu red, cerca de tus sistemas internos, con tu control de acceso, tus secretos, tu SIEM y tu paranoia (paranoia sana).
Pagas con:
- Mantenimiento: actualizaciones, CVEs, compatibilidad de nodos, seguridad, seguridad y más seguridad.
- Operación: backups, alta disponibilidad si lo necesitas, monitorización.
- Disciplina: control de cambios, gestión de credenciales, segregación de entornos.
- Usuarios: No puedes compartir flujos y otras funciones premium, tienes que tener una cuenta de servicio para producción.
¿Cuándo lo elegiría? Cuando hay sistemas internos sin salida a internet, cuando necesitas control fino de red o cuando el coste es un problema. Ten también en cuenta que necesitas servidores, backups y técnicos para mantener todo.
Este último punto es importante; la gente cree que los sistemas se instalan y a otra cosa. Ten en cuenta que cuando instalas algo en tu infraestructura, TÚ eres el responsable de mantenerlo, de actualizarlo, de controlar vulnerabilidades, de los backups (no de hacerlos, sino de hacerlos, probarlos, mantenerlos).
Community vs Enterprise (si aplica)
n8n tiene un modelo con edición “Community” (autogestionada) y opciones comerciales orientadas a empresa (Enterprise) con soporte y características típicas de gobernanza: SSO/SAML, controles de acceso más granulares, auditoría, etc.
Regla práctica: si n8n va a tocar procesos críticos o datos sensibles y hay más de 5-6 personas creando flujos, empieza a pensar en gobierno desde el día 1. Si no puedes permitirte Enterprise, procedimenta todo bien, añade controles, vigila bien las ejecuciones. Si ves que se convierte en crítico y se justifica, plantéate pagar.
Cómo funciona n8n por dentro: workflows, nodos, triggers, credenciales y ejecuciones
Vamos a lo que importa: cómo se ejecuta esto.
Workflows: un grafo
Un workflow en n8n es un grafo dirigido, la base de todo: nodos conectados por líneas que transportan datos (normalmente JSON). Cada nodo recibe items, hace algo, y produce items para el siguiente. Puedes ramificar (IF/Switch), combinar (Merge), mapear, filtrar, etc.
El editor es visual, sí, pero lo que corre por dentro es bastante “de ingeniería”: entradas, salidas, estados y errores. Si vienes de colas y pipelines, te sonará. Si no, piensa en una cadena de montaje donde cada estación transforma una caja.
Nodos: triggers y acciones
Hay dos familias:
- Triggers: inician el flujo. Ejemplos: Webhook, Cron, triggers de apps (cuando llega un email, cuando se crea un issue, etc.).
- Acciones: hacen trabajo. Llamar a una API, escribir en Sheets, mandar un Slack, ejecutar código, etc.
Ojo a la fiabilidad; no siempre son 100% fiables.
Credenciales: el sitio donde se muere la inocencia
n8n gestiona credenciales para conectar con servicios: tokens OAuth, API keys, usuarios/contraseñas, etc. En self-hosted, esas credenciales se cifran con una clave (la famosa N8N_ENCRYPTION_KEY). Si pierdes esa clave… bueno, no exactamente “pierdes todo”, pero te vas a acordar de ella.
Consejos de colega pesado:
- No metas secretos en nodos como texto plano “porque es rápido”.
- Usa un gestor de secretos si puedes (Vault, AWS Secrets Manager, etc.).
- Separa credenciales por entorno (dev/staging/prod) y por propósito.
Ejecuciones: manual vs producción, logs y reintentos
n8n distingue entre ejecutar manualmente (para probar) y ejecutar activado (producción). Cada ejecución genera un registro: qué entró, qué salió, dónde falló. Esto es oro para depurar… y también un riesgo si guardas datos sensibles en logs. Es importante en los planes Cloud ya que las pruebas no cuentan como ejecuciones.
Sobre reintentos: algunos nodos permiten reintentar, otros no. Y aunque puedas reintentar, cuidado con efectos secundarios (duplicar filas, mandar dos emails, crear dos tickets). Idempotencia: esa palabra que nadie quiere oír hasta que la necesita.
Qué puedes y qué no puedes hacer: límites, mantenimiento y seguridad
Voy a ser honesto: n8n me mola, pero no es un unicornio. Es un motor de automatización. Y los motores tienen límites.
Lo que sí puedes hacer
- Automatizaciones de negocio con lógica moderada: reglas, transformaciones, ruteos.
- Integración con APIs y SaaS sin montar un servicio por cada caso.
- Procesos internos que cambian a menudo (n8n facilita iterar).
- Prototipado de integraciones: validar en días lo que en “proyecto” serían semanas.
Lo que puedes hacer… pero te va a pasar factura
- Convertir n8n en tu backend principal “porque ya funciona”.
- Meter lógica compleja sin versionado, sin tests y con 12 ramas IF.
- Operar a gran escala sin pensar en concurrencia, colas y rate limits.
Lo que directamente no es buena idea
- Procesamiento muy masivo (millones de eventos/hora) sin arquitectura adicional.
- Flujos ultra críticos con SLAs duros si no tienes HA, observabilidad y gobernanza.
- Exponer webhooks sin autenticación/validación, porque total, es interno. Bueno, yo tampoco soy quién para impedir la eutanasia laboral.
Mantenimiento: el coste
En self-hosted, hay que actualizar n8n, revisar cambios de nodos, y estar atento a vulnerabilidades/actualizaciones. También hay dependencias externas: Google cambia scopes, Slack cambia permisos. Y tú te enteras cuando el workflow falla.
Seguridad: donde se separa el juguete del sistema
La seguridad es inerente a todos los sistemas, yo por lo menos lo veo así, algo sin seguridad directamente no es profesional. N8N no es una excepción, le vas a dar credenciales para que haga cosas, muchas cosas, se diligente con esto para no tener sorpresas.
Riesgos típicos:
- Webhooks sin control: si aceptas cualquier payload, te pueden spamear, forzar costes o colarte datos maliciosos.
- SSRF y llamadas internas: nodos HTTP mal configurados pueden convertirse en “puente” a redes internas.
- Credenciales: tokens con permisos excesivos, reutilizados, o compartidos entre equipos.
- Logs: ejecuciones que almacenan PII/secretos sin retención y sin control de acceso.
Si tu organización se toma en serio la seguridad, te va a encajar leer (o recordar) cosas como análisis de riesgos y controles. En Iberasync tengo una pieza sobre análisis de riesgos y seguridad de la información que aplica sorprendentemente bien a “automatizaciones inocentes”.
Y si vas a mezclar IA, ojo con los modelos: prompt injection, fuga de datos, y entradas no confiables. Sí, suena peor de lo que es… hasta que lo sufres. También tengo un artículo sobre LLMs y vulnerabilidades con un título poco sutil: ¿Podemos hacer que un T800 nos haga la colada?.
Reflexión: n8n vs software a medida, coste/beneficio y señales de uso
Hay una guerra cultural bastante absurda: “low-code vs ingeniería”. Como si el objetivo fuera ganar un debate y no entregar valor.
Cuándo n8n es una buena decisión
- Time-to-value: necesitas algo en días, no en un trimestre.
- Backoffice cambiante: reglas que se ajustan cada semana.
- Integraciones “pegamento”: mover y transformar datos entre herramientas.
- Equipo pequeño que no quiere mantener 20 scripts sueltos.
Cuándo software a medida gana
- Core del negocio: si eso falla, la empresa se para, la gente deja de trabajar durante x tiempo.
- SLAs y rendimiento: latencias, throughput, control fino.
- Lógica compleja que pide tests, versionado y revisiones serias.
- Solidez: si necesitas algo duro como una piedra, tienes que arremangarte, no lo puedes dejar en manos de N8N.
- Gobernanza: auditoría, segregación, cambios controlados, trazabilidad.
Y aquí viene el matiz: puedes empezar con n8n y luego “bajar” a software a medida cuando el flujo madura. Eso es una estrategia sensata. Lo que no es sensato es eternizar un prototipo porque “funciona”. Funciona… hasta que deja de hacerlo o se convierte en algo que no se pued emantener.
Coste/beneficio (el de verdad)
El coste no es solo licencia. Es:
- Horas de operación (self-hosted) o coste por ejecución (cloud).
- Riesgo operacional (quién responde cuando falla).
- Riesgo de seguridad (webhooks, credenciales, logs).
- Deuda de diseño (workflows inentendibles).
Si quieres hilar fino, piensa en “coste total de propiedad” y en riesgos. Si te interesa esa parte, tengo otra lectura complementaria sobre testing unitario e integración. Sí, también aplica a automatizaciones: probar que “manda un Slack” es fácil; probar que no lo manda dos veces es donde empieza la fiesta.
Open source: libertad y responsabilidad
Que sea open source no significa “gratis y ya”. Significa que puedes auditar, adaptar, autoalojar y no depender tanto de un vendor. Pero también significa que, si lo operas tú, lo operas tú. Actualizaciones, backups, hardening, y ese “pequeño detalle” de que un webhook es una puerta de entrada.
Señales de sí lo necesitas vs no lo necesitas
Sí lo necesitas si:
- Tu equipo pierde horas semanales en tareas repetitivas y manuales.
- Tienes 5+ herramientas SaaS que no se hablan bien entre sí.
- Necesitas integrar sistemas internos sin montar un proyecto gigante.
- Te importa tener trazabilidad de ejecuciones (quién, cuándo, qué falló).
No lo necesitas (o no todavía) si:
- Solo quieres “un script” que corre una vez al mes y nadie lo toca.
- Tu problema real es de datos/definición de proceso, no de automatización.
- No puedes dedicar ni una hora al mes a mantenimiento y seguridad.
Una frase que repito mucho: si no puedes operar la solución, no tienes solución.
Cierre y próximos temas de la serie
n8n es una herramienta muy potente para automatizar integraciones y procesos sin montar un servicio por cada cosa. Te da velocidad y control (sobre todo en self-hosted), pero también te exige disciplina: credenciales bien gestionadas, webhooks protegidos, límites, observabilidad y un mínimo de gobierno.
Si te quedas con una idea, que sea esta: automatizar no elimina problemas, los desplaza. Pasas de “Juan hace copy-paste” a “un workflow corre 24/7”. Eso es mejor… siempre que lo trates como software.
Próximos temas que vienen en la serie:
- n8n en Docker: rápido de montar, serio de mantener.
- Seguridad práctica: webhooks, autenticación, redes, secretos y hardening.
- N8N Arquitectura al detalle.
- Patrones de workflows: idempotencia, reintentos, DLQ, y cuándo meter colas.
- Observabilidad.
- IA aplicada con n8n: prompts robustos, control de costes y mitigación de prompt injection.
Y ya. Ve a automatizar algo pequeño, mide el impacto, y luego decides si esto es una herramienta… o el inicio de tu próximo dolor de cabeza.
Sobre todo, piensa en tu proceso, diseña tu flujo de trabajo, piensa en eliminar lo inútil, no acumules datos porque sí, ni automatices porque sí, piensa bien tus pasos, céntrate en el proceso; luego ya, si eso, te pones con este juguete.
