n8n Cloud vs n8n self-hosted para empresas: coste, seguridad, mantenimiento y control

La respuesta corta: elige por responsabilidad, no por eslóganes

n8n Cloud suele ser el punto de partida razonable cuando nadie en la empresa debe operar servidores y las condiciones del servicio encajan. Self-hosted tiene sentido cuando existe una necesidad concreta de red, configuración o control y hay un equipo —interno o contratado— capaz de mantener y recuperar la plataforma.

La documentación oficial indica que ambos modelos pueden utilizarse en producción. Por tanto, la pregunta no es cuál es profesional y cuál no. La pregunta es qué modelo permite cumplir los requisitos del proceso con una asignación de responsabilidades verificable.

Si todavía estás eligiendo plataforma, empieza por la comparativa de n8n, Make y Zapier para empresas. Este artículo parte de una decisión distinta: n8n ya encaja y toca escoger quién opera su infraestructura.

Qué cambia entre Cloud y self-hosted —y qué sigue siendo tuyo

En Cloud, n8n se ocupa del alojamiento, la plataforma y sus actualizaciones. En self-hosted, esas tareas pasan al operador elegido por la empresa. Sin embargo, ningún modelo conoce por sí solo qué debe ocurrir con un lead duplicado, si una factura puede reintentarse o quién debe aprobar una respuesta. La lógica de negocio sigue siendo responsabilidad de la organización.

También conviene separar despliegue, plan y edición. La Community Edition es self-hosted, pero no contiene todas las funciones de gobierno de las ediciones comerciales. La propia documentación remite a la página de precios como fuente vigente para saber qué incluye cada nivel. Autohospedar no convierte automáticamente todas las funciones empresariales en gratuitas.

Seguridad: sigue el dato, no la etiqueta Cloud

Según su página de seguridad consultada el 21 de agosto de 2026, n8n aplica en Cloud cifrado en tránsito y en reposo, redes privadas y copias gestionadas. En self-hosted, n8n señala que el operador debe configurar TLS y el cifrado del almacenamiento. Son controles relevantes, pero no sustituyen el análisis del tratamiento ni garantizan por sí solos que un workflow concreto sea seguro.

Un n8n autohospedado puede enviar datos a un CRM, un modelo de IA, una plataforma de correo y un sistema contable. En cuanto los llama, los datos salen del servidor bajo las condiciones de esos proveedores. Del mismo modo, usar Cloud no elimina la posibilidad de aplicar minimización, permisos limitados, redacción de ejecuciones y plazos de conservación apropiados. Hay que dibujar el recorrido extremo a extremo.

1. 01

   Clasifica datos y finalidad

   Documenta qué campos entran, para qué se usan, quién puede verlos y cuánto tiempo deben conservarse. No guardes cuerpos completos solo porque facilitan depurar.

2. 02

   Revisa encargados y transferencias

   En Cloud, contrasta el DPA y la lista actual de subencargados. En ambos modelos, repite la revisión con cada servicio conectado al workflow.

3. 03

   Reduce el alcance de credenciales

   Prefiere OAuth y scopes mínimos cuando la aplicación lo permita, separa producción y pruebas, y establece revocación y rotación.

4. 04

   Controla ejecuciones y logs

   Decide qué éxitos y errores se guardan, redacta datos sensibles y ajusta pruning. Más historial no equivale automáticamente a mejor trazabilidad.

Disponibilidad, escalado y recuperación ante fallo

Cloud reduce el trabajo de operar la plataforma, pero la empresa todavía debe comprobar el estado de los workflows y de las APIs conectadas. Una instancia disponible no demuestra que el CRM haya recibido el registro esperado. Self-hosted permite diseñar la topología, aunque cada componente añadido amplía la superficie que hay que mantener.

La documentación de queue mode describe una instancia principal, Redis, workers y una base de datos compartida. Sirve para distribuir ejecuciones, pero no debe venderse como alta disponibilidad automática: siguen siendo necesarios health checks, capacidad, redundancia donde proceda y procedimientos ante fallos de Redis, DB, worker o red. Todos los componentes deben compartir correctamente la clave de cifrado.

• RTO: cuánto tiempo puede permanecer interrumpido el proceso antes de causar un impacto inaceptable.
• RPO: cuánto estado o cuántos eventos puede perderse y reconstruirse de forma segura.
• Owner: quién recibe la alerta, decide detener, restaura y valida el resultado de negocio.
• Fallback: cómo se reciben y procesan manualmente los casos mientras el sistema no está disponible.

En self-hosted, un backup completo puede requerir base de datos, configuración, clave de cifrado, almacenamiento binario y estado externo asociado. La CLI permite exportar workflows, credenciales y entidades, pero un JSON de workflows no recupera por sí solo toda la instalación. En Cloud, conviene confirmar qué recuperación ofrece el plan y mantener una salida documentada para los activos que la empresa necesita conservar.

Cómo comparar el coste total sin inventar un punto de equilibrio

No existe un volumen universal a partir del cual self-hosted sea más barato. Una empresa con plataforma interna madura puede absorber tareas que otra tendría que contratar. Un workflow pesado puede consumir recursos muy distintos de otro con el mismo número de ejecuciones. La comparación debe utilizar facturas, tiempo y criticidad propios.

La guía de NAS sobre cuánto cuesta automatizar procesos en una empresa ayuda a separar construcción, herramientas, mantenimiento y soporte. Para esta decisión, añade el tiempo real de la persona que operará la plataforma y el trabajo necesario para probar una restauración.

Tres escenarios para decidir con criterio

1. 01

   Empresa de servicios con aplicaciones SaaS y sin DevOps

   Cloud suele reducir riesgo de plataforma y acelera el piloto. La comprobación pendiente es si límites, gobierno, soporte y tratamiento de datos encajan con los workflows previstos.

2. 02

   Equipo técnico con sistemas accesibles solo en red privada

   Self-hosted puede resolver conectividad y control de configuración. Debe presupuestarse la operación completa, no solo el contenedor de n8n.

3. 03

   Proceso sensible o regulado

   No decidas solo por ubicación. Compara finalidad, minimización, accesos, contratos, subencargados, registros, recuperación y capacidad humana. Puede encajar cualquiera de los dos si los controles son adecuados al riesgo.

Un proveedor puede operar un despliegue self-hosted en nombre de la empresa. Eso no crea una tercera arquitectura: cambia quién ejecuta tareas y qué debe recoger el contrato. Hay que dejar por escrito acceso, actualización, backup, restore, incidentes, propiedad y entrega al terminar el servicio.

Migración y salida: prueba cómo cambiar antes de necesitarlo

La portabilidad no termina al descargar un workflow. Los nodos pueden depender de credenciales, variables, versiones, archivos, tablas, dominios, URLs de webhook y callbacks OAuth. Además, un export puede representar el borrador guardado o la versión publicada; conviene registrar cuál se promueve y valida.

1. 01

   Inventaría dependencias

   Lista workflows publicados, subworkflows, credenciales, variables, tablas, binary data, dominios, colas y sistemas externos.

2. 02

   Prepara identidad y red

   Actualiza callbacks OAuth, secretos, allowlists, DNS y URLs de webhook sin dejar dos consumidores produciendo el mismo efecto.

3. 03

   Valida con coexistencia controlada

   Prueba entradas representativas, resultados, alertas e idempotencia. Define qué instalación recibe tráfico y cómo se vuelve atrás.

4. 04

   Conserva la evidencia necesaria

   Decide qué historial debe migrarse y qué puede eliminarse. Si exportas credenciales descifradas para una migración, trátalas como secretos de máxima sensibilidad y destruye la copia temporal de forma segura.

Después de elegir despliegue, la guía sobre mantenimiento de automatizaciones en producción concreta los controles de logs, alertas, reintentos, copias y fallback que siguen siendo necesarios.

Cuándo NO elegir self-hosted —y cuándo cuestionar Cloud

• No elijas self-hosted si nadie tiene nombre y tiempo asignados para actualizar, vigilar y recuperar.
• No lo elijas solo porque un VPS parezca barato o porque Community no tenga cuota de licencia.
• No lo elijas si la única copia no se ha restaurado o si la clave de cifrado depende de una sola persona.
• No lo elijas si los cambios se aplicarán directamente en producción sin prueba ni rollback.
• Cuestiona Cloud si necesitas conectividad o configuración que el servicio no permite, o si el contrato, el plan o el recorrido de datos no cumplen tus requisitos.
• Cuestiona ambos si el proceso aún cambia cada semana, carece de owner o no tiene una salida manual segura.

Si necesitas convertir esos requisitos en una arquitectura verificable, el servicio de automatización con IA para empresas puede diseñar el flujo, sus límites y su modelo operativo sin presuponer que una modalidad gana siempre.