n8n vs Make: comparativa real para elegir tu plataforma de automatización

# n8n vs Make: comparativa real para elegir tu plataforma de automatización

Si buscas esta comparación, los dos primeros resultados que te va a devolver Google son la página en la que Make compara Make con n8n y la página en la que n8n compara n8n con Make. Las dos están muy bien escritas y las dos tienen el mismo problema de origen: las firma alguien que gana dinero con una de las dos respuestas.

Nosotros montamos automatizaciones en las dos, así que no tenemos plataforma que defender. Y después de hacerlo unas cuantas veces hemos aprendido que la comparación que importa no es la lista de funciones, que se parecen mucho más de lo que ambas admiten, sino tres cosas que casi nadie explica bien: cómo factura cada una de verdad, qué dice la letra pequeña de la licencia y quién va a mantener esto dentro de un año.

Este artículo va de eso. Con la documentación oficial de cada fabricante citada, sin precios en euros, porque cambian cada trimestre, y sin declarar un ganador, porque no lo hay.

La diferencia que ordena todas las demás

Antes de entrar en detalles, la distinción de fondo, porque de ella cuelga casi todo lo que viene después.

Make es un servicio. Se ejecuta en la infraestructura de Make. Tú entras por el navegador, montas el escenario, y el trabajo de que eso funcione a las tres de la mañana es de otro. No hay servidor que actualizar ni copia de seguridad que programar.

n8n te deja elegir. Su documentación describe dos caminos: la nube gestionada por ellos, sin instalación y con el mantenimiento de su lado, o la instalación en tu propia infraestructura mediante npm, Docker o un servidor, con lo que ellos llaman «control total sobre el despliegue». La edición Community es gratuita e incluye, en sus palabras, la mayoría de las funciones. A cambio, la frase que aparece en la misma comparación es la que hay que leer despacio: eres tú quien proporciona y gestiona la infraestructura.

Esa elección no es técnica, es organizativa. Si en tu empresa no hay nadie que sepa qué hacer cuando un contenedor de Docker se queda sin memoria, autoalojar n8n no es más barato: es más caro, solo que el coste aparece en forma de horas de alguien y de flujos parados, no en forma de factura.

Cómo factura cada una, y por qué comparar precios de lista engaña

Aquí está el apartado que puede ahorrarte más dinero, y es pura aritmética con las definiciones de cada fabricante.

Make cobra por operación, y las operaciones se multiplican

La ayuda oficial de Make define la operación como «una única ejecución de un módulo para procesar datos o comprobar si hay datos nuevos». Cada módulo consume una operación por cada paquete de datos que procesa. Si el módulo de enviar correo manda cinco correos, son cinco operaciones.

Los módulos de disparo son la excepción: se ejecutan una sola vez para comprobar o recuperar datos, sin importar cuántos paquetes devuelvan. Un disparador que trae diez registros consume una operación, no diez.

Y ahora la frase que decide el presupuesto, que está en su propia documentación: los paquetes de los módulos anteriores tienen un efecto multiplicador sobre las operaciones del resto del escenario.

Traducido a una servilleta: si tu disparador trae doscientos registros al día y el escenario tiene seis módulos después, no consumes seis operaciones ni doscientas. Consumes en torno a mil doscientas, porque cada uno de los seis módulos se ejecuta doscientas veces. Multiplica por treinta días y ya estás en un plan que no habías presupuestado.

Esto no es una crítica al modelo, que tiene la ventaja de ser transparente y de que pagas exactamente por lo que consumes. Es una advertencia sobre cómo hay que calcular: el número que importa no es cuántos escenarios tienes, es cuántos registros pasan por cuántos módulos.

n8n cobra por ejecución de flujo completo

En el lado opuesto, la página de precios de n8n lo dice sin rodeos: una ejecución es una sola pasada de tu flujo completo, y da igual cuántos pasos tenga el flujo o cuántos datos procese.

El mismo escenario de antes, con sus seis pasos, cuenta como una ejecución. No como seis. Para flujos largos y con mucho procesamiento, la diferencia entre los dos modelos deja de ser un matiz y pasa a ser un orden de magnitud.

A fecha de hoy, y según su propia página de precios, los planes de nube incluyen 2.500 ejecuciones mensuales en el nivel de entrada, 10.000 en el intermedio y 40.000 en el de empresa. Compruébalo antes de calcular nada, porque esas cifras son justamente lo que más cambia.

El matiz que decide la factura en n8n

Hay una trampa que no está en ninguna de las dos páginas de precios y que hemos visto costar dinero de verdad: en n8n, cómo estructures el flujo cambia la factura.

Un flujo que se dispara una vez por cada registro nuevo y procesa ese registro consume una ejecución por registro. Doscientos registros al día son doscientas ejecuciones. El mismo trabajo, montado como un flujo que se dispara una vez cada hora, recoge los registros pendientes y los recorre en bucle por dentro, consume veinticuatro ejecuciones al día.

Es el mismo resultado de negocio con una diferencia de factura de casi diez veces. La forma de montarlo importa tanto como la plataforma que elijas, y es exactamente el tipo de decisión que separa una automatización con n8n y Make bien planteada de una que funciona pero se come el presupuesto.

Cómo calcular tu consumo antes de firmar nada

Media hora de hoja de cálculo evita una sorpresa de doce meses. El método es este, y sirve igual para las dos.

Coge tu automatización más importante, la que de verdad vas a montar primero, y anota cuatro números. Cuántas veces se dispara al día. Cuántos registros trae cada disparo. Cuántos pasos hay después del disparador. Y cuántos de esos pasos se ejecutan para todos los registros, porque los que van detrás de un filtro solo corren para los que pasan.

Con eso, en el modelo por operación multiplicas registros por pasos afectados y sumas los disparos. En el modelo por ejecución cuentas cuántas veces arranca el flujo entero, que es un número mucho más pequeño y mucho más aburrido.

Después haz el mismo cálculo con dos escenarios más: el del día de más trabajo del año, y el de dentro de doce meses si el negocio crece como esperas. El primero te dice si vas a quedarte sin cuota justo el día que peor viene; el segundo, si vas a tener que renegociar el plan en el peor momento.

Y añade una línea que casi nadie añade: los reintentos. Un servicio externo que se cae y un flujo que reintenta cada cinco minutos durante una noche puede consumir más que una semana normal. Si tu modelo es por operación, esa línea no es teórica.

Al terminar tendrás dos números comparables y una conversación mucho más corta con el comercial de turno.

La licencia de n8n, el detalle que casi nadie lee

Este apartado no aparece en ninguna de las comparativas que hemos leído para preparar el artículo, y para una parte de quien busca esto es el dato que más pesa.

n8n no es software libre en el sentido estricto. Su repositorio se publica bajo la Sustainable Use License v1.0, una licencia que sus autores llaman fair-code. Permite usar, copiar, distribuir y hacer obras derivadas del software, pero acota para qué: para tus propios fines internos de negocio, o para uso personal y no comercial.

La restricción que hay que leer entera es esta: solo puedes distribuir el software o proporcionárselo a otros si lo haces de forma gratuita y con fines no comerciales.

Es decir, puedes instalar n8n en tu empresa y automatizar lo que quieras, incluida tu operación comercial. Lo que no puedes hacer es montar n8n en un servidor y vender a tus clientes el acceso a esa instalación como si fuera tu producto. Si eres una agencia o un consultor y tu modelo pasa por alojar automatizaciones para terceros, esa frase te afecta directamente y conviene resolverla con su equipo comercial antes de construir encima.

Hay además un segundo detalle técnico con consecuencias prácticas: los archivos del repositorio que llevan `.ee.` en el nombre quedan fuera de esa licencia y requieren una licencia Enterprise aparte. Son funciones de empresa que no vienen incluidas en lo gratuito, así que conviene comprobar si alguna de las que das por hechas está en ese grupo antes de diseñar la arquitectura.

Make, al ser un servicio, no tiene este debate: pagas la suscripción y usas la plataforma con las condiciones de su contrato. Más sencillo de entender, y también menos margen para hacer cosas raras.

Dónde viven tus datos

Para una empresa española que trate datos personales, este apartado a veces decide la comparación entera antes de mirar ninguna función.

Con Make, tus datos pasan por la infraestructura de Make. Eso implica un encargado del tratamiento externo, su contrato correspondiente, y comprobar en qué región se procesan. Es perfectamente gestionable y lo hace medio mercado, pero es una casilla que hay que rellenar y documentar.

Con n8n autoalojado, la respuesta es más corta: los datos no salen de donde tú los pongas. Si lo instalas en un servidor tuyo en la Unión Europea, no hay transferencia internacional que justificar ni un tercero al que auditar. Para sectores donde eso pesa, sanidad, legal, banca o administración, suele ser el argumento que zanja la discusión.

Con n8n en su nube gestionada vuelves al escenario del primer párrafo: un proveedor externo con su contrato.

Ojo con una conclusión demasiado rápida, porque es un error común. Autoalojar no te hace automáticamente más conforme con el reglamento. Te hace responsable. Los registros de actividad, el cifrado, los accesos, las copias de seguridad y la retención pasan a ser trabajo tuyo. Cambias un riesgo de proveedor por un riesgo de operación, y hay organizaciones para las que ese cambio es a peor.

Curva de aprendizaje y quién mantiene esto en un año

Las dos se manejan arrastrando bloques y conectándolos, y las dos tienen una curva razonable para alguien con perfil de marketing o de operaciones. La diferencia aparece más adelante.

Make es más fácil al principio. El editor visual es muy legible, el catálogo de aplicaciones listas para conectar es enorme, y una persona sin perfil técnico puede montar algo útil en una tarde. Cuando el escenario crece y hay que manipular datos con cierta lógica, aparecen las funciones y los iteradores, y ahí la cosa se complica de golpe.

n8n pide más al principio y devuelve más después. Deja escribir código dentro del flujo cuando la interfaz se queda corta, lo que evita el momento clásico de «esto ya no se puede hacer con bloques». A cambio, ese código lo tiene que mantener alguien.

La pregunta útil no es cuál es más fácil, es quién va a tocar esto cuando la persona que lo montó ya no esté. Si la respuesta es «alguien de marketing», Make suele envejecer mejor. Si es «tenemos perfil técnico dentro», n8n te dará más recorrido antes de tocar techo.

Si estás en la fase anterior a esta decisión y aún no tienes claro qué procesos merecen automatizarse, el criterio está en automatización vs IA, y hay casos desarrollados en automatizaciones con IA: 6 ejemplos reales y medibles.

Cuando falta el conector que necesitas

Las dos traen catálogos amplios de aplicaciones listas para conectar, y las dos van a cubrir sin problema lo evidente: correo, hojas de cálculo, los CRM conocidos, las tiendas más habituales, el chat interno. La comparación por número de integraciones es un deporte poco útil, porque lo que decide no es cuántas hay sino si está la tuya.

Haz la comprobación al revés. Antes de elegir, escribe la lista de las cinco herramientas que de verdad usas, incluida esa que solo se usa en tu sector, y búscalas en las dos. Ese cuarto de hora vale más que cualquier tabla de recuento.

Cuando falte alguna, las dos tienen la misma salida de emergencia: llamar a la interfaz de programación del servicio directamente con un paso genérico de peticiones HTTP. Funciona, y en la práctica es lo que acaba pasando con cualquier herramienta de nicho. Ahora bien, ese paso genérico ya no es arrastrar bloques: hay que entender la documentación de esa interfaz, autenticarse y tratar los errores a mano.

De aquí sale una advertencia útil. Si la mitad de tu automatización va a apoyarse en pasos genéricos, la ventaja de facilidad que tenía la plataforma más sencilla se evapora, porque el trabajo se ha vuelto técnico igualmente. En ese punto es mejor elegir por las otras razones del artículo, no por el catálogo.

Y hay un tercer camino que conviene conocer: n8n admite nodos de la comunidad, componentes escritos por terceros que amplían lo que trae de serie. Es potente y ahorra trabajo, con la contrapartida obvia de que estás instalando código de otro en tu flujo. Merece la misma revisión que cualquier dependencia externa: quién lo mantiene, cuándo se actualizó por última vez y qué pasa si mañana deja de actualizarse.

Trabajo en equipo, versiones y paso a producción

Este apartado no sale en casi ninguna comparativa y es el que separa una automatización que aguanta de una que se rompe el día que entra alguien nuevo.

Cuando la automatización deja de ser un experimento de una persona, aparecen tres preguntas que ninguna captura de pantalla responde.

¿Quién puede editar qué? En cuanto hay más de dos personas tocando, hace falta saber quién puede publicar cambios en algo que está en producción y quién solo puede mirar. Compruébalo en el plan que vayas a contratar, no en el catálogo general, porque el control de accesos suele vivir en los niveles altos.

¿Qué pasa si dos personas editan a la vez? La respuesta honesta en herramientas visuales suele ser «gana el último que guarda». Si eso te suena a problema, es porque lo es. La solución práctica no es técnica sino de acuerdo: una persona responsable por flujo, y avisar antes de tocar.

¿Cómo se prueba un cambio sin romper lo que funciona? Aquí n8n autoalojado tiene una ventaja real para equipos con perfil técnico: puedes levantar una segunda instancia de pruebas, exportar los flujos como ficheros y versionarlos junto al resto del código, con lo que un cambio pasa por revisión antes de llegar a producción, igual que cualquier otro. En una plataforma de servicio ese ciclo existe pero es más rígido, y muchos equipos acaban duplicando el escenario y renombrándolo, que funciona hasta que deja de funcionar.

La recomendación, valga la plataforma que valga: deja escrito quién es el dueño de cada flujo, qué hace y a quién avisar si falla. Un documento de media página evita la situación clásica de la automatización huérfana que nadie se atreve a tocar porque nadie sabe qué rompe.

La IA dentro del flujo, y dónde está el coste de verdad

Las dos plataformas han incorporado pasos para llamar a modelos de lenguaje, y esa parte de la comparación cambia cada pocos meses, así que cualquier cosa que escribamos aquí sobre funciones concretas envejecerá mal. Lo que no cambia es lo siguiente.

El coste del modelo va aparte. La plataforma te cobra por mover el dato, y el proveedor del modelo te cobra por procesarlo. Son dos facturas distintas y la segunda no aparece en ninguna comparativa de automatización. Un flujo que resume mil correos al día tiene un coste de plataforma modesto y un coste de modelo que conviene calcular antes.

La clave de la interfaz de programación es tuya. En las dos la introduces tú y en las dos hay que tratarla como una credencial de verdad: guardada en el almacén de credenciales de la plataforma, nunca escrita dentro de un paso, y con un límite de gasto configurado en el panel del proveedor. Ese límite es la única red de seguridad real contra un bucle que se dispara de madrugada.

El paso de IA es el que más falla, y falla distinto cada vez. Devuelve texto plausible, no un dato validado. Poner una comprobación determinista después, que verifique que la salida tiene la forma esperada antes de escribirla en ningún sitio, no es opcional. Lo hemos desarrollado entero en automatización vs IA, y la regla es la misma aquí: el modelo nunca es el último paso antes de una acción irreversible.

Qué pasa cuando un flujo falla

Ninguna comparativa de funciones te prepara para esto, y es donde se pierde la confianza en una automatización.

Los flujos fallan siempre. Una interfaz de programación cambia, un servicio se cae, alguien renombra una columna en una hoja de cálculo, llega un dato con un formato imposible. La pregunta buena no es si va a fallar, es qué ocurre cuando falle.

Lo que hay que comprobar en las dos, antes de decidir, es siempre lo mismo:

• Si te avisa. Un fallo silencioso es peor que un fallo ruidoso, porque descubres el problema semanas después con los datos ya mal cargados.
• Si reintenta. Muchos fallos son temporales y se resuelven solos al segundo intento.
• Si el flujo se reanuda o hay que relanzarlo entero. No es lo mismo reprocesar un registro que reprocesar el día completo.
• Cuánto histórico de ejecuciones guarda, porque sin él no puedes averiguar qué pasó.
• Si el reintento consume presupuesto. En un modelo por operación, un flujo que reintenta en bucle puede gastarse el mes en una tarde. Merece la pena poner un límite y una alerta desde el primer día.

Las dos plataformas tienen mecanismos para todo esto. La diferencia práctica es cuánto trabajo te da dejarlos bien puestos, y en ninguna de las dos viene resuelto de fábrica.

La tabla de decisión

Ninguna fila decide sola. Si al leerla te salen seis de ocho hacia el mismo lado, ya tienes la respuesta. Si te sale cuatro y cuatro, tu problema no es de plataforma sino de que aún no has decidido qué quieres automatizar.

Seis situaciones reales y qué elegiríamos

Una tienda que quiere sincronizar pedidos con su facturación y avisar por chat. Pocos registros, flujo corto, nadie técnico dentro. Make, sin dudarlo. Está funcionando en una tarde y no hay nada que mantener.

Una empresa que procesa miles de líneas de un fichero cada noche. Aquí el modelo por operación se vuelve caro deprisa por el efecto multiplicador. n8n, y montado como una ejecución que recorre el fichero por dentro.

Una clínica que quiere automatizar la gestión de citas. Datos de salud. n8n autoalojado en un servidor propio en la Unión Europea, siempre que exista alguien que asuma el mantenimiento y los registros de acceso. Si no lo hay, es preferible Make con su contrato firmado que un servidor propio mal administrado.

Una agencia que quiere ofrecer automatizaciones a sus clientes. Lee la licencia de n8n antes de decidir nada. Si el plan es alojar tú las automatizaciones de terceros, esa vía necesita una conversación con su equipo comercial. Con Make no hay ambigüedad.

Un equipo de marketing que quiere probar ideas rápido. Make. La velocidad de prototipado es su punto fuerte y el coste de equivocarse es bajo.

Una empresa que ya tiene desarrolladores y quiere que la automatización viva junto al resto de su código. n8n autoalojado, con los flujos versionados como cualquier otro repositorio.

Los tres errores de elección más caros

Comparar precios de lista en vez de calcular tu consumo. Los dos modelos son tan distintos que el precio del plan no dice nada. Coge tu flujo real, cuenta registros por módulos, y calcula. Media hora de hoja de cálculo antes de firmar.

Elegir por lo que sabes hacer hoy y no por quién lo mantendrá. La automatización que monta el becario brillante en julio es la que nadie sabe tocar en marzo. Elige la plataforma que pueda mantener el equipo que tendrás, no el que tienes esta semana.

Autoalojar por ahorrar. Es la decisión que más veces sale mal. Un servidor tiene coste, tiene actualizaciones y tiene noches malas. Autoaloja por control o por cumplimiento normativo, que son razones sólidas. Por precio, casi nunca lo es.

Qué probar durante la prueba gratuita

Las dos ofrecen una forma de probarlas sin pagar, y casi todo el mundo desaprovecha ese periodo montando el flujo más bonito en lugar del más peligroso. Haz lo contrario.

Monta el flujo que más te preocupa, no el más fácil, y con datos reales aunque sea sobre una copia. El fácil va a funcionar en las dos y no te va a enseñar nada.

Después, provoca los problemas a propósito. Desconecta una credencial a mitad de escenario y mira qué hace. Métele un dato malformado, una fecha imposible o un campo vacío que debería venir relleno. Corta la conexión con un servicio externo y comprueba si reintenta, si avisa y dónde queda el registro de lo ocurrido.

Mira también lo aburrido, que es lo que se paga después: cuántas operaciones o ejecuciones ha consumido esa prueba, dónde se ve ese contador, y si puedes ponerle una alerta antes de llegar al límite.

Y por último, la prueba que más información da y que nadie hace: enséñaselo a la persona que lo va a mantener cuando tú no estés y pídele que cambie algo pequeño delante de ti. Si tarda quince minutos en encontrar dónde se toca, ya tienes tu respuesta, y no la ha dado ninguna tabla comparativa.

Con esas cinco pruebas en las dos plataformas sabrás más que leyendo veinte artículos, incluido este.

Preguntas frecuentes

¿Cuál es más barata, n8n o Make? Depende por completo de la forma de tus flujos. Make cobra por operación y las operaciones se multiplican por cada registro que atraviesa cada módulo; n8n cobra por ejecución de flujo completo sin importar los pasos. Para pocos registros en flujos cortos, Make suele salir bien. Para muchos registros en flujos largos, n8n suele salir mucho mejor.

¿n8n es gratis? La edición Community es gratuita e incluye, según su documentación, la mayoría de las funciones, pero la infraestructura la pones y la mantienes tú. Gratis en licencia no es gratis en coste total.

¿Puedo revender automatizaciones montadas en n8n? Usarlo para tu propio negocio, sí. Alojar el software y proporcionárselo a terceros con ánimo de lucro es justo lo que su licencia restringe. Antes de construir un producto encima, resuélvelo con ellos.

¿Se puede migrar de una a otra? No de forma automática. Los conceptos se parecen lo bastante como para rehacer el trabajo sin volver a pensarlo, pero es rehacerlo. Cuenta con ello al elegir, porque el coste de cambiar no es cero.

¿Y Zapier? Es la tercera opción evidente y juega en otro terreno: aún más fácil, aún más caro por volumen y con menos margen de personalización. Si tu duda real es entre n8n y Make, probablemente ya has descartado ese perfil.

¿Puedo usar las dos a la vez? Sí, y es más común de lo que parece. Make para lo que monta el equipo de negocio y n8n para lo que necesita procesamiento serio. El riesgo es tener dos sitios donde mirar cuando algo falla, así que si lo haces, deja escrito qué vive en cada una.

Cómo decidirlo en una tarde

Si te quedas con una idea: no elijas plataforma, elige modelo de facturación y modelo de responsabilidad. Todo lo demás es preferencia de interfaz.

El orden que funciona es este. Primero, coge tu flujo más importante y cuenta cuántos registros pasan al día y por cuántos pasos. Segundo, aplica las dos definiciones de este artículo y calcula el consumo en cada modelo. Tercero, responde a quién va a mantener esto dentro de un año, y sé honesto con la respuesta. Cuarto, si tratas datos personales sensibles, comprueba si necesitas que no salgan de tu servidor. Y si vas a construir un negocio encima, léete la licencia antes que la lista de funciones.

Con esas cuatro respuestas, la elección se hace sola. Y si prefieres que alguien haga ese cálculo contigo y monte el primer flujo bien desde el principio, es exactamente el trabajo que hacemos, y el punto de partida está en cómo automatizar tareas repetitivas con IA y en cómo elegir herramientas de automatización con IA.

Elegir plataforma es el segundo paso. El primero es saber qué flujo vas a montar y si de verdad merece la pena: lo tenemos resuelto en diez workflows con su veredicto de automatización.

Si el flujo que vas a montar genera contenido publicable, antes conviene leer qué castiga Google del contenido producido a escala: está en penalizaciones por contenido con IA.

Elegida la plataforma queda lo otro, que es saber qué hay dentro de un flujo. Medimos 199 plantillas públicas de n8n y la mediana es de 13 nodos: los ejemplos, con su cadena de nodos completa, están en doce automatizaciones con n8n.