n8n autoalojado vs cloud: un flujo con webhook en producción
Comparativa por criterios de n8n autoalojado vs cloud para un flujo con webhook: instalación, payload, credenciales, actualizaciones, retención, escalado y monitorización.
Comprobado con las fuentes citadas el .
Alcance: un flujo, dos caminos de alojamiento
Imagina la automatización útil más simple: un nodo Webhook recibe un payload JSON, un nodo HTTP Request llama a una API externa y una pequeña transformación de datos da forma a la respuesta. Funciona en tu portátil. La pregunta en n8n autoalojado vs cloud no es si ese flujo se ejecuta —n8n documenta ambas opciones de despliegue como aptas para producción— sino qué lo rodea cuando llega tráfico real.
La documentación es tajante sobre la diferencia inicial: Cloud no necesita instalación ni conocimientos técnicos para ponerse en marcha, mientras que autoalojar exige una instalación mediante npm, Docker o un servidor, además de la experiencia para configurarlo. Los docs también recomiendan el autoalojamiento para usuarios expertos, señalando que los errores pueden provocar pérdida de datos, problemas de seguridad y caídas. Eso es una guía, no una medición, pero marca el tono de cada criterio siguiente.
Una nota más sobre el alcance. No había cifras de precios, benchmarks ni comparaciones de latencia disponibles para este artículo, así que la comparación se mantiene cualitativa y centrada en los mecanismos. Consulta la página de precios actual de n8n para los números por plan en lugar de fiarte de cifras citadas en otro sitio.
Instalación, base de datos y la propia URL del webhook
Para el autoalojamiento, n8n enumera varias vías de instalación y recomienda Docker Compose para despliegues de producción con bases de datos y servicios adicionales. Por defecto, una instancia autoalojada guarda las credenciales, las ejecuciones pasadas y los flujos en SQLite, con PostgreSQL configurable mediante variables de entorno. Ese valor por defecto está bien para una única instancia de evaluación y se convierte en una restricción más adelante, por lo que la decisión sobre la base de datos corresponde antes de tu primera publicación en producción, no después.
El nodo Webhook se comporta igual en ambos entornos. Te da una URL de prueba y una URL de producción separada, y n8n registra el webhook de producción cuando publicas el flujo. En la práctica, eso significa que un flujo prototipado en otro sitio debe volver a probarse tras publicarlo en el entorno de destino, porque la URL que usa quien te llama no es la que pulsaste durante el desarrollo.
El tamaño del payload es donde ambos caminos se separan. El payload máximo del webhook es de 16MB, y solo los usuarios autoalojados pueden cambiarlo con la variable de entorno N8N_PAYLOAD_SIZE_MAX. Si tu integración con la API recibe subidas grandes o documentos JSON voluminosos, ese único ajuste puede decidir por sí solo la cuestión del alojamiento. La documentación aportada no sugiere valores máximos seguros ni describe el impacto en memoria de aumentarlo, así que trata cualquier incremento como algo que hay que probar.
Credenciales, claves de cifrado y el paso de una a otra
Una instancia autoalojada crea una clave de cifrado aleatoria en el primer arranque y la guarda en la carpeta home de n8n; esa clave cifra tus credenciales, y en modo cola cada worker debe compartirla. Saber dónde vive esa clave —y asegurarte de que sobrevive a una reconstrucción del contenedor— es la diferencia entre un reinicio rutinario y una mañana reintroduciendo tokens de API. Las fuentes aportadas no documentan un procedimiento de copia de seguridad o rotación, así que diseña tu propio manejo de forma deliberada.
La portabilidad es asimétrica. No existe migración automatizada de Cloud a autoalojado: los flujos se exportan e importan manualmente, y las credenciales no pueden exportarse desde Cloud por motivos de seguridad, por lo que después hay que reintroducirlas a mano. Las instancias autoalojadas, en cambio, tienen comandos CLI de exportación e importación, incluida una exportación de credenciales en texto plano pensada para moverse entre instalaciones con claves secretas distintas. Esa comodidad también es un riesgo, ya que la CLI del servidor se salta los controles de acceso y la exportación deja los valores sensibles al descubierto.
Si una mudanza es siquiera plausible, planíficala como un ejercicio manual: exporta los flujos, reintroduce cada credencial y luego verifica cada conexión de API antes de reapuntar el webhook.
Actualizaciones, datos de ejecución y retención
La responsabilidad de las actualizaciones es una de las líneas más marcadas en n8n autoalojado vs cloud. En Cloud, la versión del runtime, el canal de publicación Beta o Stable, la cadencia de actualización y la ventana de mantenimiento son ajustes que gestiona el propietario de la instancia, y cambiar la versión provoca un reinicio corto de aproximadamente uno o dos minutos. Con independencia de la cadencia que elijas, n8n siempre aplica automáticamente las actualizaciones de seguridad y estabilidad. Cambias fijar la versión por que otro se encargue de los parches.
Los equipos autoalojados son dueños por completo del calendario de actualizaciones, lo que es una ventaja cuando un nodo de la comunidad o una configuración personalizada es sensible a los cambios de versión, y un lastre cuando nadie tiene asignada esa tarea.
Los datos de ejecución siguen el mismo patrón. Cloud purga los registros de ejecución automáticamente según el plan: los planes Pro, por ejemplo, guardan como máximo 25000 ejecuciones con 30 días de retención. Las instancias autoalojadas controlan la retención con las variables EXECUTIONS_DATA, con purgas por defecto de 336 horas y 10.000 ejecuciones. Una advertencia que afecta a quienes usan SQLite: las filas purgadas no liberan espacio en disco sin un VACUUM.
Escalado, monitorización y funciones limitadas por plan
Cloud aplica límites de RAM y CPU por plan, documentados desde 320MiB en Trial y Starter hasta 4096MiB en Enterprise, y aplica un control de concurrencia a nivel de instancia a las ejecuciones de producción —precisamente las que inicia tu webhook—, encolando todo lo que supere el límite. Las cifras de concurrencia por plan están en la página de precios y no en el texto de la documentación utilizado aquí.
Escalar en autoalojado significa modo cola con Redis y procesos worker. Las configuraciones distribuidas no están soportadas en SQLite, que es la segunda razón para elegir PostgreSQL pronto. En modo cola, las respuestas del webhook se retransmiten a través de Redis con un límite de tamaño por defecto de 64 MiB, configurable mediante N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX; descargar cuerpos más grandes requiere una versión reciente de n8n en cada instancia main más almacenamiento compartido. El modo multi-main es exclusivo de Enterprise y no está disponible en Cloud.
La monitorización es la separación más clara en n8n autoalojado vs cloud. El endpoint /metrics es exclusivo del autoalojamiento en todas las ediciones y está desactivado hasta que lo habilitas explícitamente; /healthz está disponible en ambos. El streaming de logs a sistemas externos es Enterprise tanto en Cloud como en autoalojado, así que autoalojar por sí solo no lo desbloquea.
Las funciones limitadas por edición merecen una lectura aparte. La edición Community autoalojada gratuita excluye SSO, entornos, proyectos, secretos externos, streaming de logs y control de versiones con Git, pero sí incluye el modo cola. Registrar esa edición gratuita por correo desbloquea carpetas, depuración en el editor y datos de ejecución personalizados. Las listas de funciones cambian, y los propios docs señalan la página de precios como fuente de verdad.
Sources: S7, S8, S5, S14, S15, S3
n8n autoalojado vs cloud: compromisos, incógnitas y cómo decidir
Aplicada a un único flujo de webhook y API, la comparación entre n8n autoalojado y cloud se reduce a unos pocos compromisos honestos. Cloud te da actualizaciones gestionadas, purga automática y ninguna propiedad de infraestructura, a cambio de un techo fijo de payload, recursos ligados al plan, encolado de concurrencia a nivel de instancia y ningún endpoint de métricas. El autoalojamiento te da el tamaño de payload, la política de retención, las métricas y el escalado en modo cola que quieras, a cambio de ser dueño de la base de datos, la clave de cifrado, las actualizaciones y los modos de fallo sobre los que los docs advierten a los usuarios expertos.
Varias cosas siguen siendo desconocidas a partir de la documentación disponible. Aquí no hay cifras de precios, ni números de concurrencia por plan, ni un procedimiento de copia y restauración para instancias autoalojadas, ni un benchmark que compare el mismo flujo en ambos entornos. Trata esas lagunas como tus propias tareas de evaluación en lugar de asumir paridad.
Una secuencia viable: prototipa donde puedas empezar más rápido, decide la base de datos, el volumen persistente y el manejo de la clave de cifrado antes de la primera publicación en producción si autoalojas, vuelve a probar tras publicar porque es entonces cuando se registra la URL de producción, y confirma los límites actuales en la página de precios antes de comprometerte.
