Por Fran Navoz en Nicalia, Productos y servicios
24 de agosto de 2026
Si tu agencia ha cruzado el umbral en el que la factura de automatización crece al mismo ritmo que los clientes, ya conoces el problema: en un modelo de pago por tarea, cada mejora técnica que introduces —un log, un paso de verificación, un reintento— tiene precio. El proceso no se vuelve más valioso. Solo más caro.
Llevar ese trabajo a un VPS propio es una respuesta razonable, pero circula demasiada literatura que promete ahorros del 90 % sin contar la letra pequeña. Este post intenta lo contrario: precios reales verificados, el ahorro que sale de verdad según volumen, las restricciones de licencia que casi nadie menciona (y que afectan de lleno a las agencias), y cómo dimensionar el servidor sin quedarte corto.
Un flujo de captación con seis pasos —entra un lead, se verifica el correo, se puntúa, se actualiza el CRM, se avisa por Slack y se registra en una hoja— gasta cinco tareas por ejecución. Cien ejecuciones diarias durante un mes son 15.000 tareas para un único workflow
La confusión más cara del sector es creer que una ejecución de workflow equivale a una tarea. No es así. En Zapier, cada paso de acción que se completa con éxito consume una tarea. El disparador no cuenta; los filtros, las rutas y el formateador tampoco. Todo lo que escribe o lee en una aplicación externa, sí.
La aritmética se vuelve incómoda enseguida. Un flujo de captación con seis pasos —entra un lead, se verifica el correo, se puntúa, se actualiza el CRM, se avisa por Slack y se registra en una hoja— gasta cinco tareas por ejecución. Cien ejecuciones diarias durante un mes son 15.000 tareas para un único workflow. Y en 2026 los pasos de IA, los pasos de código y las llamadas MCP salen de esa misma bolsa.
Estos son los tramos publicados del plan Professional con facturación anual. La facturación mensual sale aproximadamente un 50 % más cara, porque el descuento anual ronda el 33 %.
| Tareas/mes | Zapier Professional (anual) | Coste aproximado por tarea |
|---|---|---|
| 750 | 19,99 $ | 0,027 $ |
| 10.000 | 129 $ | 0,013 $ |
| 50.000 | 289 $ | 0,006 $ |
| 100.000 | 489 $ | 0,005 $ |
| 500.000 | 1.499 $ | 0,003 $ |
Conviene fijarse en algo que juega en contra del argumento fácil: el coste unitario baja al escalar. Quien más consume, menos paga por tarea. El problema no es que Zapier sea caro por unidad a volumen alto, sino que el importe absoluto se vuelve una partida fija considerable y, sobre todo, imposible de acotar. Si superas el límite, las tareas extra se facturan a aproximadamente 1,25 veces la tarifa de tu plan hasta un tope de tres veces tu volumen contratado.
Aquí es donde la mayoría de comparativas hace trampa: ponen el precio del VPS frente al precio del SaaS y declaran un 90 % de ahorro. Falta la mitad de la ecuación. Un stack self-hosted requiere actualizaciones, copias de seguridad, monitorización y resolución de incidencias, y esas horas tienen coste aunque las ponga alguien de plantilla.
La comparación honesta, con horas de mantenimiento incluidas, queda así:
| Escenario | Zapier | VPS + mantenimiento | Ahorro |
|---|---|---|---|
| Volumen bajo 10.000 tareas |
~129 $/mes | 70–130 €/mes VPS 4 GB + ~1 h/mes |
0–45 % |
| Volumen medio 50.000 tareas |
~289 $/mes | 90–260 €/mes VPS 8–16 GB + 1–2 h/mes |
10–70 % |
| Operación intensiva 500.000 tareas |
~1.499 $/mes | 180–600 €/mes VPS 8 vCPU / 24 GB + 2–3 h/mes |
60–88 % |
*Precios de Zapier en dólares con facturación anual; costes de infraestructura en euros sin IVA. La comparación es orientativa y no incorpora el tipo de cambio. Las horas de mantenimiento se valoran a tarifa de mercado para perfil técnico.
La lectura es incómoda pero útil: por debajo de unas 20.000 tareas al mes, el self-hosting rara vez compensa en dinero. Compensa por otras razones —soberanía del dato, control, ausencia de límites— pero no por coste. El punto de inflexión llega cuando el volumen crece lo suficiente como para que las horas de mantenimiento se diluyan sobre una factura SaaS de tres o cuatro cifras.
El coste que nadie presupuesta
Las horas de mantenimiento no son teóricas. n8n 2.0 eliminó por completo el soporte de MySQL y MariaDB: quien tuviera su instancia sobre esos motores ha tenido que migrar a PostgreSQL o SQLite. Añade a eso un ritmo de versiones semanal, cambios de sintaxis en expresiones y nodos de la comunidad que dejan de aparecer tras una actualización. Un stack self-hosted sin política de versiones fijadas y entorno de pruebas no es más barato: es más frágil.
Esta es la sección que suele faltar en las guías de migración, y es la que más importa si eres una agencia. Ni n8n ni Dify son software libre en el sentido clásico. Ambos publican su código, ambos permiten el autoalojamiento gratuito, y ambos restringen exactamente el escenario que muchas agencias tienen en mente.
n8n abandonó el modelo Apache 2.0 con Commons Clause en 2022 y adoptó su propia licencia fair-code, la Sustainable Use License. Permite usar, modificar y redistribuir el software, con tres limitaciones. La relevante aquí es la primera: el uso queda circunscrito a fines internos de tu propio negocio, a usos no comerciales o personales.
La propia documentación de n8n es explícita sobre dónde está la frontera:
| Permitido | No permitido sin licencia comercial |
|---|---|
| Sincronizar datos que controla tu empresa, por ejemplo del CRM a una base interna.
Prestar servicios de consultoría sobre n8n: construir workflows, desarrollar funcionalidades próximas al producto o código que n8n ejecuta. Instalar y mantener n8n en el servidor interno de una empresa. Crear nodos propios o integraciones entre tu producto y n8n. |
Alojar n8n y cobrar a terceros por acceder a él.
Hacer white-label de n8n y ofrecerlo a clientes como producto de pago. Flujos que recogen las credenciales del propio usuario final para acceder a sus datos en su nombre. |
Traducido a la práctica de una agencia: montar n8n en el servidor de tu cliente, cobrarle por la implantación y por el mantenimiento, está dentro. Montar una instancia tuya, dar acceso a diez clientes y facturarles una cuota mensual por ese acceso, está fuera. La diferencia entre ambos modelos de negocio es una decisión que conviene tomar antes de escribir el primer workflow, no después de la primera ronda de financiación o de la primera auditoría legal de un cliente grande.
Dify aparece etiquetada como Apache 2.0, lo que induce a error. Su licencia añade dos condiciones sobre la base Apache. La primera prohíbe operar un entorno multi-tenant con el código de Dify sin autorización escrita, definiendo tenant como espacio de trabajo. La segunda impide retirar o modificar el logotipo y la información de copyright de la consola cuando se usan sus componentes de frontend, restricción que no aplica si tu uso no los involucra.
El uso comercial sí está expresamente contemplado: puedes emplear Dify como backend de tus propias aplicaciones o como plataforma interna de desarrollo. Lo que no puedes es revenderlo como servicio alojado multi-inquilino.
Si tu modelo pasa por vender acceso multi-inquilino, hay opciones con licencias permisivas clásicas que evitan por completo la conversación: Flowise se distribuye bajo Apache 2.0 sin condiciones añadidas, y Langflow bajo MIT. Qdrant, Caddy y Ollama tampoco imponen restricciones de este tipo. La elección de orquestador, en un proyecto comercial, no es solo técnica.
Existe una idea extendida de que autoalojar elimina obligaciones. No las elimina; redistribuye el riesgo, que es distinto y sigue siendo valioso.
El artículo 28 sigue aplicando. Cuando alquilas un VPS a un proveedor, ese proveedor trata datos personales por cuenta tuya. La condición de encargado del tratamiento nace de la realidad funcional, no de cómo se llame el contrato: si un proveedor recibe datos y los trata conforme a tus instrucciones, es encargado. Necesitas contrato de encargo con tu proveedor de hosting igual que lo necesitabas con tu proveedor SaaS. La AEPD ha sancionado precisamente la ausencia de ese contrato y la autorización irregular de subencargados.
Lo que sí ganas es longitud de cadena. Al ejecutar la orquestación en tu propia infraestructura, los prompts, los registros de ejecución y el contenido de los índices vectoriales dejan de pasar por la plataforma de automatización y por sus subencargados. Pasas de una cadena con varios eslabones —plataforma SaaS, su nube subyacente, su proveedor de LLM, los subencargados de todos ellos— a una con uno solo: tu proveedor de VPS. Si además usas modelos locales, la cadena se detiene ahí.
El artículo 30 tampoco desaparece. El registro de actividades de tratamiento sigue siendo obligación tuya. Lo que mejora es la capacidad de documentarlo con precisión, porque conoces exactamente dónde reside cada dato y quién accede.
Transferencias internacionales. Ejecutar el stack en un centro de datos de la UE elimina el escenario de transferencia a tercer país regulado en los artículos 44 a 49, siempre que ningún componente del flujo llame a una API fuera del EEE. Ese matiz importa: un workflow autoalojado en Madrid que invoca un modelo alojado en Estados Unidos sigue generando una transferencia internacional.
Cualquier proyecto de IA que arranque ahora necesita ubicarse en el calendario del Reglamento (UE) 2024/1689, que acaba de cambiar. El Reglamento (UE) 2026/1744, conocido como Ómnibus Digital sobre IA y publicado en el DOUE el 24 de julio de 2026, ha reajustado los plazos:
Interpretar el aplazamiento como una moratoria general sería un error de lectura. Si tu automatización incluye un chatbot que atiende a clientes o genera contenido sintético, las obligaciones de transparencia te aplican desde este mes. Y la clasificación de un sistema como de alto riesgo no ha desaparecido: solo se ha movido su fecha de exigibilidad, lo que afecta a contratos que se firman ahora y seguirán vigentes en 2027.
El almacenamiento NVMe deja de ser un lujo en cuanto entra una base vectorial: el rendimiento de recuperación en Qdrant depende directamente de la latencia de disco cuando el índice no cabe entero en memoria.
| Perfil | vCPU | RAM | Stack |
|---|---|---|---|
| Básico | 2 | 4 GB | n8n + PostgreSQL + Caddy. Orquestación simple con modelos vía API. |
| Intermedio | 4 | 8–16 GB | n8n en modo cola con Redis + Dify + Qdrant. RAG corporativo. |
| Avanzado | 8 | 24+ GB | Stack completo + inferencia local de modelos pequeños en CPU. |
Como referencia mínima verificable, los instaladores comunitarios documentan 4 GB de memoria, 2 núcleos y 30 GB de disco para un despliegue reducido con n8n y Flowise. Es un suelo, no un objetivo.
Para modelos cuantizados en Q4_K_M, que es el estándar práctico de inferencia local, la aproximación de memoria es directa:
RAM ≈ 0,6 GB × (miles de millones de parámetros) + caché KV + margen del sistema
De ahí salen las cifras habituales: un modelo de 7B necesita entre 4 y 6 GB, uno de 13B entre 8 y 10 GB, y uno de la clase 70B entre 38 y 48 GB según la longitud de contexto. La caché KV es la variable que se suele olvidar y la que más crece: un modelo de 8B pasa de unos 0,3 GB con 2K de contexto a unos 5 GB con 32K y en torno a 20 GB con 128K. Si necesitas contextos largos, la caché puede pesar más que el propio modelo.
El catálogo se ha renovado por completo respecto al de hace año y medio. Las referencias actuales para autoalojamiento son Qwen 3, Gemma 3 y 4, Llama 4, gpt-oss y Phi-4 Mini. Buena parte de los modelos punteros de 2026 son arquitecturas de mezcla de expertos: activan solo una fracción de sus parámetros por token, así que corren más rápido que un modelo denso equivalente, pero siguen necesitando memoria suficiente para mantener todos los pesos residentes. La cifra de parámetros totales sigue mandando en el dimensionado.
Expectativas realistas sin GPU
Un VPS sin GPU ejecuta modelos locales, pero conviene saber a qué velocidad. En CPU, un modelo de 7B en Q4 rinde aproximadamente entre 2 y 15 tokens por segundo según el procesador; la misma carga sobre una GPU dedicada de 8 GB ronda los 40. Eso hace que la inferencia en CPU sea perfectamente válida para clasificación, extracción de entidades, triaje y procesamiento por lotes en segundo plano, y claramente insuficiente para chat interactivo con usuarios finales. Para un entorno solo CPU con memoria ajustada, un modelo de 3B a 4B ofrece una experiencia mucho más razonable que forzar un 7B.
La recomendación más rentable de este artículo: no ejecutes el motor de inferencia en la misma máquina que la orquestación. Cuando un modelo local satura la CPU durante veinte segundos, todos los workflows que compartan ese servidor se degradan a la vez, incluidos los que envían correo o escriben en el CRM y no tienen nada que ver con la IA.
El patrón sano es un VPS para n8n en modo cola con sus workers, PostgreSQL y Redis, y un segundo VPS —o un servicio externo— para la inferencia. Cuestan más que una sola máquina grande, pero aíslan el fallo. Y permiten escalar cada mitad según su propio cuello de botella, que rara vez es el mismo.
Aquí conviene distinguir entre lo oficial y lo comunitario, porque las expectativas de producción son muy distintas.
El Self-hosted AI Starter Kit de n8n es una plantilla de Docker Compose que incluye cuatro piezas: n8n autoalojado, Ollama, Qdrant y PostgreSQL. Es la vía más rápida para tener un entorno funcionando, y la propia n8n advierte que no está optimizado para producción: lo plantea como base para pruebas de concepto.
Los instaladores comunitarios —n8n-installer y sus derivados, a su vez forks de proyectos previos— van bastante más allá: un único comando prepara el sistema, instala Docker, configura cortafuegos y protección contra fuerza bruta, genera secretos y lanza los servicios, con un asistente que permite elegir qué desplegar sobre un núcleo fijo de Caddy, PostgreSQL y Redis. n8n arranca en modo cola con el número de workers que indiques. Son excelentes para acortar la puesta en marcha de días a una tarde.
Lo que ninguno de los dos resuelve es lo que viene después. El instalador te deja el stack en pie; la política de copias de seguridad, el entorno de preproducción, el fijado de versiones y la rotación de credenciales siguen siendo tuyos. Un despliegue profesional se distingue por eso, no por el número de contenedores.
La diferencia entre usar IA y tener una operación de IA está en la estructura. Una tarea es un encargo aislado; una habilidad es una tarea que has estabilizado lo suficiente como para reutilizarla; una rutina es una habilidad que se ejecuta sola según un calendario o un disparador. En un modelo de pago por tarea, las rutinas son precisamente lo que resulta prohibitivo: son las que más veces se ejecutan. En infraestructura propia, son gratis en el margen.
Un flujo de investigación que convierta una pauta suelta en un briefing estructurado —resumen ejecutivo breve, separación explícita entre hechos verificables e hipótesis, listado de afirmaciones que exigen comprobación contra fuente primaria, varios ángulos posibles y un esqueleto narrativo— consume muchas llamadas por documento procesado. Con cien pautas diarias, el coste por tarea decide si el proceso existe o no. Es el ejemplo canónico de trabajo que solo es viable cuando el límite lo pone el hardware y no la cuota.
Análisis de contratos, expedientes, historiales o nóminas. En estos casos la motivación rara vez es el ahorro: es que el flujo con procesamiento externo directamente no se aprueba en el comité de riesgos del cliente.
Un consultor honesto también señala los contraindicados:
Hay cuatro cosas que conviene exigir para este tipo de despliegue:
Infraestructura para tu stack de automatización con Nicalia
En Nicalia trabajamos con infraestructura alojada en España, almacenamiento NVMe y soporte técnico en español que entiende de servidores, no solo de tickets. Si estás valorando llevar tu automatización a servidor propio, podemos ayudarte a dimensionar la máquina antes de que contrates nada de más —o de menos.
No sin licencia comercial. La Sustainable Use License permite el uso interno de tu propio negocio y los servicios de consultoría alrededor de n8n, pero no alojar la herramienta y cobrar a terceros por acceder a ella ni ofrecerla con marca propia. Sí puedes implantar y mantener n8n en la infraestructura de tu cliente y facturar ese trabajo.
Como orden de magnitud, alrededor de 20.000 ejecuciones mensuales. Por debajo, el coste del mantenimiento suele igualar o superar el ahorro en licencias. Por encima, la diferencia se amplía rápidamente porque el coste de infraestructura crece mucho más despacio que la factura por tarea.
Depende del uso. Para clasificación, extracción de datos y procesamiento por lotes, un VPS con CPU y memoria suficiente cumple. Para chat interactivo con usuarios finales, la velocidad en CPU —del orden de unos pocos tokens por segundo— resulta insuficiente y necesitarás GPU o un modelo servido por API.
No. Tu proveedor de VPS trata datos personales por cuenta tuya y por tanto es encargado del tratamiento, con las obligaciones del artículo 28 del RGPD. Lo que consigues es acortar la cadena de subencargados, que es donde está el riesgo real de exposición.
Sigues realizando una transferencia internacional de datos y te aplican los artículos 44 a 49 del RGPD. La soberanía es una propiedad del flujo completo, no solo del servidor donde vive el orquestador.
Los precios de terceros citados corresponden a las tarifas publicadas en agosto de 2026 y pueden variar. Este artículo tiene finalidad informativa y no constituye asesoramiento jurídico; para decisiones de cumplimiento normativo, consulta con tu asesor legal o con tu delegado de protección de datos.
Fran Navoz
