Self-Hosted a Cloud: cuando tiene sentido el cambio en n8n

El cambio de una instancia n8n self-hosted al n8n Cloud merece la pena sobre todo cuando el esfuerzo dedicado a servidores, actualizaciones y copias de seguridad supera el beneficio de un entorno totalmente controlado. Sin embargo, no todo se traslada automaticamente: segun la documentacion de n8n, los community nodes no verificados y los nodos creados por uno mismo solo funcionan en self-hosted, las ejecuciones estan limitadas numericamente segun el plan Cloud, y las credenciales deben volver a crearse manualmente tras la mudanza, porque los archivos de workflow exportados solo contienen nombres e ID de las credentials, no sus valores. Quien conoce estos puntos de antemano evita sorpresas desagradables tras la migracion. Estado: julio de 2026.

Cuando merece la pena el cambio al Cloud

En self-hosted, segun el propio n8n, usted asume toda la responsabilidad: proporciona la infraestructura, la gestiona y es responsable de las actualizaciones, los parches de seguridad y las copias de seguridad. El n8n Cloud invierte esta relacion. Segun la vision general oficial de las opciones de uso, esta completamente gestionado, no se necesita configuracion, y n8n se encarga del mantenimiento y la operacion. Para equipos sin capacidad informatica propia o con poco tiempo para el cuidado de servidores, esto es una ventaja real. El precio de ello: usted cede parte del control que se gano conscientemente con el self-hosting, y paga una suscripcion continua en lugar de costes de infraestructura puros.

Que no se traslada automaticamente con la mudanza

La mayor diferencia afecta a los nodos. En el n8n Cloud, segun la documentacion sobre la instalacion de community nodes, solo se pueden instalar community nodes verificados a traves del panel de nodos. Los nodos no verificados y la instalacion mediante npm solo son posibles en self-hosted. Quien utilice nodos propios o poco comunes debe comprobar antes de la mudanza si esos nodos estan verificados, porque de lo contrario desaparecen sin mas en el Cloud.

• Nodos: Solo los community nodes verificados funcionan en el Cloud, las instalaciones via npm y los nodos creados por uno mismo permanecen en self-hosted.
• Credenciales: Segun la documentacion de exportacion e importacion, los archivos JSON de workflow exportados solo contienen nombres e ID de las credentials, no sus valores. Tras la importacion debe volver a introducir manualmente todas las credenciales.
• Configuracion: El ajuste fino mediante variables de entorno, que en self-hosted constituye la base de la configuracion, solo es posible de forma limitada en el Cloud, ya que la instancia esta gestionada.

Limites de ejecucion y recursos comparados

En self-hosted, el numero de ejecuciones esta practicamente limitado solo por su propio hardware de servidor. En el Cloud se aplican cuotas fijas segun el plan. Segun la lista de precios de n8n, el plan Starter incluye 2.500 ejecuciones al mes con 5 ejecuciones simultaneas, el plan Pro 10.000 ejecuciones con 20 ejecuciones simultaneas, el plan Business 40.000 ejecuciones ademas de SSO, SAML, LDAP y entornos basados en Git. El almacenamiento de los registros de ejecucion tambien esta limitado: segun la informacion de la gestion de datos en el Cloud, el plan Starter almacena como maximo 2.500 ejecuciones con 7 dias de retencion, Pro hasta 25.000 con 30 dias, Enterprise hasta 50.000 con retencion ilimitada. A partir del 85 por ciento de uso de almacenamiento, n8n puede limpiar automaticamente los datos de ejecucion mas antiguos. La memoria tambien esta escalonada, desde 320 MiB en el plan Starter y de prueba hasta 4.096 MiB en Enterprise, mientras que en self-hosted usted mismo elige el tamano del servidor.

Que hay que hacer concretamente para la migracion

Los workflows se pueden exportar como JSON e importar a la instancia Cloud. Antes de hacerlo, merece la pena hacer un breve inventario: que nodos estan en uso, y si todos ellos figuran como verificados en el Cloud. Despues, las credentials se crean a mano en el nuevo entorno, ya que, como se ha descrito, los archivos exportados no contienen secretos. Quien haya trabajado hasta ahora con variables de entorno o con su propia configuracion de base de datos deberia documentar esta configuracion antes de la mudanza, porque no existe de la misma forma en el entorno Cloud gestionado. Para los equipos que quieran planificar la mudanza de forma tecnicamente limpia y con una priorizacion clara, se ofrece una consultoria de n8n que comprueba de antemano que workflows funcionan sin cambios y donde son necesarios ajustes.

Preguntas frecuentes sobre la migracion de self-hosted a Cloud en n8n

Todos los workflows self-hosted funcionan sin cambios en el Cloud?

Solo si todos los nodos utilizados estan entre los community nodes verificados o son nodos estandar de n8n. Los workflows con nodos no verificados o creados por uno mismo deben adaptarse o sustituirse antes de la mudanza, porque, segun la documentacion de n8n, no se pueden instalar en el Cloud.

Que ocurre con mis credenciales durante la mudanza?

Deben volver a crearse. La exportacion del workflow solo contiene nombres e ID de las credentials, ninguna contrasena, token o clave. Esto tiene sentido desde el punto de vista de la seguridad, pero supone un esfuerzo manual tras la importacion.

Puedo volver mas adelante a self-hosted?

En principio, los workflows se pueden volver a exportar e importar en una instancia self-hosted. Las restricciones especificas del Cloud desaparecen entonces, pero a cambio usted vuelve a asumir toda la responsabilidad de la operacion, las actualizaciones y las copias de seguridad.

Cuantas ejecuciones incluye el plan Cloud mas economico?

Segun la lista de precios actual, el plan Starter ofrece 2.500 ejecuciones al mes con un maximo de 5 ejecuciones simultaneas. Quien necesite mas debe pasar a Pro o Business, o permanecer en self-hosted, donde el limite depende del propio hardware de servidor.