n8n o Make: Cuál Elegir para Automatizar tu Empresa
Cobro por operación frente a por ejecución, datos que salen o se quedan, y quién mantiene esto en seis meses. Las preguntas que deciden, sin precios que envejecen.
1. La pregunta que todo el mundo hace, y la que debería hacer
"¿Cuál es mejor, n8n o Make?" no tiene respuesta, porque resuelven el mismo problema desde lados opuestos. **Make** es un servicio alojado. Abres una cuenta, conectas tus aplicaciones y construyes el flujo en un lienzo visual. No hay servidor, no hay actualizaciones, no hay nada que mantener. Pagas por operaciones ejecutadas. **n8n** es software que además puedes alojar tú. Hay versión en la nube de pago, pero lo que lo distingue es poder ejecutar la versión comunitaria en tu propio servidor, sin límite de ejecuciones y con los datos sin salir nunca de tu infraestructura. La pregunta útil es otra: **¿qué te cuesta más, la factura mensual o las horas de mantenimiento?** Si es la factura y tienes con qué gestionar un servidor, n8n autoalojado gana por amplio margen. Si son las horas, Make. El resto de este artículo es el detalle que sostiene esa decisión.
2. Cómo cobra cada uno, y por qué eso lo cambia todo
Esta es la diferencia con más consecuencias prácticas. **Make** cobra por **operación**. Cada paso ejecutado en un escenario cuenta: leer un correo es una operación, filtrar es otra, escribir en la hoja es otra. Un flujo de diez pasos que corre cien veces al día consume mil operaciones diarias. Quien diseña sin contar operaciones descubre el coste en la primera factura. **n8n en la nube** cobra por **ejecución** — una ejecución es el flujo entero, tenga tres pasos o treinta. Para flujos largos la diferencia es enorme. **n8n autoalojado** no tiene recuento alguno. Pagas el servidor y ejecutas lo que quieras. No te doy precios: cambian, y ambas empresas han reestructurado planes más de una vez. Consulta las tablas oficiales el día que decidas. Lo que no cambia es el **modelo**, y es el modelo el que decide si tu caso sale caro o barato. Haz la cuenta antes: cuántos pasos tiene el flujo típico, cuántas veces corre al día, y multiplica. Es media hora que evita una sorpresa.
3. Comparación por criterio
La tabla compara lo que se mantiene estable. Cifras de integraciones y precios quedan fuera por envejecer de mes a mes.
| Criterio | Make | n8n (nube) | n8n (autoalojado) |
|---|---|---|---|
| Unidad de cobro | Por operação | Por execução | Nenhuma |
| Mantenimiento | Nenhuma | Nenhuma | Servidor é seu |
| Código dentro del flujo | Limitado | JavaScript e Python | JavaScript e Python |
| Dónde pasan los datos | Servidores do fornecedor | Servidores do fornecedor | Só pela sua máquina |
| Integraciones listas | Muito amplas | Amplas | Amplas |
| Conectar API sin integración | Módulo HTTP | Nó HTTP | Nó HTTP |
| Curva de aprendizaje | Mais suave | Média | Média, mais servidor |
| Control de versiones | Limitado | Exportação JSON | JSON em Git |
4. Cuándo Make es la elección correcta
**Cuando nadie en el equipo programa.** El editor de Make es más accesible, la biblioteca de integraciones listas es mayor, y una persona no técnica puede cambiar un flujo sin romper nada. **Cuando necesitas estar funcionando hoy.** No hay servidor que aprovisionar, ni certificado, ni copias de seguridad. Abres la cuenta y empiezas. **Cuando la integración que necesitas ya está.** Si Make tiene un módulo listo para la aplicación de nicho que usas, eso te ahorra horas — y probablemente no existe en ningún otro sitio. **Cuando el volumen es bajo.** Con pocas ejecuciones al día, el plan de entrada cuesta menos que cualquier VPS, y no gastas tiempo en mantenimiento. No hay nada de malo en pagar por no gestionar infraestructura. Es un intercambio legítimo, y para muchos negocios es el correcto.
5. Cuándo n8n es la elección correcta
**Cuando los flujos son largos.** Cobrar por operación penaliza justo el tipo de automatización que más trabajo ahorra. Un flujo de treinta pasos cuesta treinta veces más en Make y lo mismo que uno de tres en n8n. **Cuando los datos no pueden salir.** Autoalojado, nada pasa por servidores de terceros. Si procesas datos de clientes, contratos o registros internos, esto deja de ser preferencia y pasa a requisito — y simplifica bastante la conversación sobre RGPD. **Cuando necesitas código en medio.** n8n te deja escribir JavaScript o Python dentro del flujo. Transformaciones que en Make exigirían encadenar módulos se resuelven en diez líneas. **Cuando el volumen es alto y constante.** A partir de cierto punto, un VPS de pocos euros ejecuta lo que costaría mucho más en operaciones. **Cuando quieres los flujos en Git.** Exportas en JSON, versionas, revisas en pull request. Para quien trata la automatización como software, esto cambia la forma de trabajar. El coste es real: actualizaciones, copias de seguridad, monitorización y tiempo de caída pasan a ser tuyos.
6. Instalar n8n para probarlo
Antes de decidir, ejecútalo localmente media hora. Con Docker es inmediato, y probarlo responde mejor que cualquier comparativa. Para producción añade un proxy inverso con TLS, una base de datos PostgreSQL en lugar de SQLite, y copias de seguridad del volumen — el mismo patrón descrito en el artículo sobre ejecutar modelos en VPS propio.
services:
n8n:
image: docker.n8n.io/n8nio/n8n
restart: unless-stopped
ports:
- "127.0.0.1:5678:5678"
environment:
- N8N_HOST=automacao.seudominio.pt
- WEBHOOK_URL=https://automacao.seudominio.pt/
# Sem isto, qualquer pessoa que alcance a porta entra.
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=admin
- N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD}
- GENERIC_TIMEZONE=Europe/Lisbon
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:7. Errores que salen caros en ambos
**No gestionar los fallos.** Un flujo sin tratamiento de error falla en silencio, y solo te enteras cuando un cliente pregunta por lo que nunca llegó. Pon notificación de fallo desde el primer día. **Sondear en lugar de escuchar.** Revisar un buzón cada cinco minutos gasta ejecuciones todo el día para nada. Si la aplicación soporta webhooks, úsalos: reaccionan en tiempo real y no consumen nada mientras no hay trabajo. **Guardar credenciales dentro del flujo.** Claves de API pegadas en nodos acaban en exportaciones y capturas de pantalla. Ambos tienen gestión de credenciales propia. **Automatizar un proceso que nadie definió.** Automatizar caos da caos más rápido. Escribe los pasos en papel primero; la mitad de las veces descubres que el proceso en sí estaba mal. **No probar con datos reales.** Flujos que funcionan con el ejemplo perfecto se rompen con el primer campo vacío o acento inesperado.
8. Cambiar de uno al otro
No hay importación automática. Los formatos son incompatibles y la migración es reconstrucción manual. En la práctica la migración es menos mala de lo que parece, porque los flujos rara vez sobreviven intactos: al reconstruir, ves pasos que ya no hacen falta. Pero cuenta con el tiempo. Lo que reduce el coste de cambiar más tarde: documentar qué hace cada flujo y por qué, mantener la lógica de negocio fuera de la herramienta siempre que se pueda — en una API tuya que ambas llamen — y evitar depender de funciones que solo una tiene. Si estás empezando y no lo tienes claro, empieza por Make. Es más rápido para validar si el proceso merece automatizarse. Si luego el volumen o el coste lo justifican, migras sabiendo exactamente qué necesitas.
9. Cómo decidir en veinte minutos
Responde a cuatro preguntas por escrito. **¿Quién va a mantener esto dentro de seis meses?** Si no es alguien que programe, Make. **¿Los datos que pasan por el flujo son sensibles?** Si sí, y eso te obliga a justificar dónde se procesan, n8n autoalojado. **¿Cuántos pasos tiene el flujo típico y cuántas veces corre al día?** Multiplica. Si da miles de operaciones diarias, el modelo de Make va a doler. **¿Tienes dónde alojar y quién mantenga un servidor?** Si no, n8n autoalojado no es opción, por atractivo que parezca el coste. En la mayoría de los casos las respuestas convergen. Cuando no convergen, empieza por Make, valida que el proceso merece la pena, y migra cuando el coste lo justifique.
Preguntas Frecuentes (FAQ)
¿n8n es gratuito?
La versión comunitaria es gratuita para autoalojar, bajo una licencia de código abierto con restricciones de uso — léela antes de integrarla en un producto que revendes. La versión en la nube es de pago. "Gratuito" significa sin cuota de licencia, no sin coste: el servidor y el mantenimiento son tuyos.
¿Puedo usar ambos a la vez?
Puedes, y a veces tiene sentido: Make para lo que necesita integraciones listas con aplicaciones de nicho, n8n para lo voluminoso o que toca datos sensibles. El coste es mantener dos herramientas y saber siempre dónde está cada flujo.
¿Cuál conecta mejor con modelos de lenguaje?
Ambos conectan con las APIs habituales y ambos llaman a cualquier API por HTTP. La diferencia práctica es que n8n deja escribir código en medio, lo que ayuda cuando hay que tratar la respuesta del modelo antes de usarla.
¿Necesito saber programar para usar n8n?
Para flujos simples, no — el editor es visual. Pero la curva es más pronunciada que la de Make, y autoalojarlo exige soltura con Docker, DNS y certificados. Sin eso, la versión en la nube o Make te ahorran frustración.
¿Qué pasa si mi servidor n8n se cae?
Los flujos paran y los webhooks recibidos en ese periodo se pierden, salvo que quien los envía reintente. Es la contrapartida de autoalojar: la disponibilidad pasa a ser tuya. Monitorización y alerta dejan de ser opcionales.