n8n autoalojado frente a Make y Zapier: cuándo conviene cada uno

La diferencia que importa: dónde viven los datos

Las tres herramientas hacen conceptualmente lo mismo: escuchan un suceso, mueven datos entre sistemas y ejecutan lógica en medio. La diferencia estructural no está en las funciones, está en por dónde pasan tus datos.

Con Make o Zapier, cada dato que atraviesa un flujo pasa por la infraestructura del proveedor. Con n8n autoalojado, el motor corre en un servidor que controlas tú y los datos no salen de ahí salvo cuando el propio flujo llama a un servicio externo.

Para muchos procesos eso da igual. Para otros lo decide todo. Si el flujo toca historiales de pacientes, nóminas, datos bancarios o cualquier cosa que en un contrato de encargado de tratamiento habría que declarar, la pregunta «¿por dónde pasa esto?» deja de ser técnica. No es que las plataformas gestionadas sean ilegales —no lo son, y tienen sus garantías y sus cláusulas—; es que cada proveedor por el que pasa un dato es un proveedor más que hay que declarar, evaluar y mantener declarado.

Nuestra doctrina es que el servidor y los datos son del cliente. No porque las alternativas estén mal, sino porque cuando el proyecto termina queremos poder irnos sin llevarnos nada: los flujos siguen corriendo en su infraestructura, con su documentación, y si algún día dejamos de trabajar juntos no hay nada que migrar ni ninguna cuenta nuestra de la que dependan.

El coste no se compara por el precio de la lista

El segundo factor es cómo escala la factura, y aquí las comparativas suelen equivocarse mirando el precio del plan de entrada.

Make y Zapier cobran por operaciones o tareas ejecutadas. El plan inicial es barato y a bajo volumen es imbatible: no hay servidor que mantener, ni actualizaciones, ni nada que se caiga un domingo. El problema aparece cuando un flujo se vuelve central y su volumen crece, porque el coste crece con él, y no linealmente en la percepción del que paga: se salta de plan.

n8n autoalojado invierte la estructura. Tiene un coste fijo —el servidor, y sobre todo el tiempo de alguien que lo mantenga— y a partir de ahí el volumen es prácticamente gratis. A bajo volumen sale caro; a volumen alto, mucho más barato.

El punto de cruce depende del caso, así que la forma honesta de decidirlo es estimar el volumen a doce meses, no el de hoy. Un flujo que ejecuta cien veces al mes no justifica mantener un servidor. Uno que ejecuta cien mil, sí, y con holgura.

Hay un tercer coste que casi nunca se pone en la tabla: quién arregla el flujo cuando falla. En una plataforma gestionada, si el motor falla es su problema. Autoalojado, es tuyo. Eso es una ventaja o un inconveniente según si tienes a alguien.

Qué cuesta más de lo que parece en cada opción

• n8n autoalojado: el mantenimiento real. Actualizaciones, copias de seguridad, certificados, vigilar que el disco no se llene. Nada difícil, todo constante. Y una particularidad que nos ha mordido más de una vez: cuando se crea un nodo por API en lugar de a mano, nace sin credencial asignada, y un flujo con un nodo sin credencial falla en el primer uso real, no al guardarlo.
• Make: la depuración de flujos grandes. La interfaz visual es excelente hasta cierto tamaño y empieza a estorbar después. Y el modelo de operaciones hace que un bucle mal planteado se note en la factura antes que en el rendimiento.
• Zapier: la lógica condicional. Es la más sencilla de las tres para empezar y la más limitada en cuanto el flujo deja de ser lineal. Muchos «zaps» encadenados para simular una bifurcación acaban siendo más difíciles de mantener que un solo flujo bien hecho en otra herramienta.

Cuándo recomendamos cada uno

Aunque nuestro trabajo esté sobre n8n, hay casos claros en los que decimos otra cosa:

• Zapier o Make si el proceso es sencillo, el volumen bajo y nadie en la empresa va a mantener un servidor. Empezar con una plataforma gestionada y migrar después si el volumen lo justifica es una decisión perfectamente sensata, y bastante más barata que montar infraestructura para tres flujos.
• Make si el equipo quiere ver y tocar los flujos por su cuenta. Su editor visual es el más accesible de los tres para alguien no técnico.
• n8n autoalojado cuando hay datos que no deberían salir de la empresa, cuando el volumen es alto, o cuando el flujo es lo bastante crítico como para no querer depender de la disponibilidad y la política de precios de un tercero.
• Ninguno de los tres si el proceso no está definido. Ninguna herramienta arregla un proceso que dos personas hacen de forma distinta.

Y un aviso sobre las migraciones entre plataformas: se venden como fáciles y no lo son. Los flujos no se traducen uno a uno, porque cada herramienta resuelve los errores, los reintentos y los datos intermedios a su manera. Migrar es rehacer con la lógica ya conocida, que es más rápido que empezar de cero pero no es un botón.