Qué cuenta como herramienta open source de automatización (y qué no)
Una herramienta open source de automatización es un motor que orquesta flujos —dispara, conecta apps, mueve datos, decide entre pasos— y cuyo código puedes alojar en tu propia infraestructura en lugar de en la nube de un tercero. La diferencia con Zapier o Make no es lo que hacen, es dónde vive el motor y quién controla el dato: en un SaaS cerrado, en sus servidores; en una herramienta open source, donde tú digas.
Conviene deshacer una confusión de nombre. "IA open source" suele referirse a los modelos de lenguaje que puedes autoalojar (Llama, Mistral y compañía), y de eso va otra decisión distinta —la de modelo abierto vs. API cerrada—. Aquí hablamos de la orquestación: la herramienta que ejecuta el flujo y llama al modelo, sea el que sea. Son dos capas separadas y se eligen por criterios distintos.
Las tres que importan: n8n, Activepieces y Windmill
El mercado open source es amplio, pero para automatización con IA en empresa la conversación real gira en torno a tres. Las tres se pueden autoalojar; se diferencian en licencia, enfoque y a quién están hechas.
| Herramienta | Licencia | Enfoque | Para quién encaja |
|---|---|---|---|
| n8n | Sustainable Use License (fair-code) | Editor visual de nodos + código donde haga falta | Equipos mixtos; la comunidad más grande y más integraciones |
| Activepieces | MIT (la más permisiva) | No-code visual, sencillo | Equipos poco técnicos que quieren libertad total de licencia |
| Windmill | AGPLv3 | Code-first (TypeScript, Python, Go, Bash, SQL) con UIs autogeneradas | Equipos de ingeniería que quieren tooling interno como código |
La licencia no es un detalle de abogados: cambia lo que puedes hacer. La de n8n es abierta para uso interno pero restringe revenderlo como servicio gestionado a terceros. Activepieces, bajo MIT, no te ata a casi nada. Windmill, bajo AGPLv3, solo te obliga a publicar tus cambios si distribuyes el software —no si lo usas de puertas adentro—. Para el 90% de las empresas, que lo alojan para su propia operación, las tres funcionan como open source de verdad.
Cuándo compensa alojarlo tú (y cuándo no)
El self-host no es gratis ni superior por defecto. Compensa cuando una de estas presiones es real —y no compensa cuando ninguna lo es.
Compensa si:
- El dato no puede salir de casa. Sector regulado, información sensible o una política de RGPD que exige que el dato viva en tu perímetro. Es la razón número uno y la que más peso tiene.
- El volumen dispara el precio. Los SaaS cobran por operación o por tarea; a partir de cierto volumen, el coste por ejecución de un plan cloud crece más rápido que el de un servidor tuyo.
- Necesitas lógica a medida o código. Cuando el flujo pide algo que el no-code no cubre, poder meter código en cualquier paso deja de ser un lujo.
- Quieres evitar el lock-in. Controlar el motor significa que un cambio de precios o de condiciones del proveedor no te pone contra la pared.
No compensa si:
- Solo conectas un par de apps y el plan cloud te vale: cambiar cuesta más de lo que ahorra.
- No tienes quien mantenga la infraestructura (ver el coste real más abajo).
- Tu cuello de botella no es la ejecución, es el criterio: leer texto libre, entender intención, decidir sobre lo ambiguo. Eso no lo arregla cambiar de herramienta; es poner una capa de IA encima.
El coste real del self-host, más allá de la licencia
"0€ de licencia" es cierto y engañoso a la vez. El coste no está en la licencia; está en operar el sistema. Esto es lo que aparece en la factura de verdad:
- Servidor y hosting: la máquina donde corre, su ancho de banda y su almacenamiento.
- Backups y alta disponibilidad: un flujo crítico que se cae sin copia es una incidencia, no una automatización.
- Actualizaciones y parches de seguridad: cada versión trae correcciones que hay que aplicar; un motor abierto y sin parchear es una puerta abierta.
- Monitorización y logs: sin observabilidad no sabes si el flujo falla hasta que alguien se queja.
- La persona que lo mantiene: el coste dominante. No es el software, es el tiempo técnico de tenerlo sano.
Self-host y RGPD: soberanía del dato, no una casilla
Alojar la herramienta tú mantiene el motor y su base de datos dentro de tu perímetro. Eso es un buen punto de partida para RGPD, pero no cierra el tema. La soberanía del dato la decide la cadena entera del flujo, no la etiqueta del panel.
El punto ciego habitual: el motor está en tu casa, pero el flujo llama a una API de LLM alojada en Estados Unidos, o dispara un webhook a un tercero, o guarda un adjunto en un almacenamiento cloud. En cada uno de esos saltos el dato sale de tu perímetro igual que si usaras un SaaS. Autoalojar el orquestador y mandar el contenido sensible a un modelo externo sin control es soberanía a medias. Hay que mirar dónde vive cada salto —y ahí es donde n8n autoalojado brilla frente a las alternativas cloud, precisamente porque puedes mantener toda la cadena bajo tu techo.
Cómo elegir en una frase
Equipo poco técnico y libertad total de licencia → Activepieces (MIT). Equipo mixto que valora comunidad e integraciones → n8n (fair-code). Equipo de ingeniería que quiere todo como código y versionado en Git → Windmill (AGPLv3). Y una advertencia que ahorra proyectos: si tu problema real es que el flujo necesita criterio, ninguna de las tres lo resuelve sola —eso es una capa de IA encima, no un cambio de herramienta—.