7. Dónde correrás tus agentes: self-hosted Community vs Cloud

Descripción

Al terminar esta lección vas a poder decidir, con números reales y no con intuición, dónde corre tu agente de n8n: en tu propia infraestructura (self-hosted, edición Community) o en la nube gestionada de n8n (Cloud). Y vas a dejar una instancia de n8n corriendo en tu máquina, lista para que en la próxima cápsula montes ahí el primer nodo AI Agent.

Esta decisión importa porque el bucle agéntico que viste en la lección anterior — el agente razonando, llamando herramientas, observando resultados — puede ejecutarse decenas o cientos de veces por cada tarea que le pidas. Si pagas por ejecución sin saber cuántas vas a correr, estás apostando a ciegas: un freelancer que automatiza tareas internas de tres clientes no tiene el mismo perfil de costo que una empresa de 200 personas que necesita que su equipo de soporte y el de ventas compartan credenciales bajo un solo inicio de sesión corporativo.

Conexión con el módulo: esta lección cierra el marco teórico que empezó en "agente vs chatbot vs IA procedural" y sigue en "cuándo usar un agente". Ya sabes qué construir y cuándo tiene sentido construirlo. Ahora resuelves dónde corre, para que el mini-proyecto de la próxima lección arranque directo sobre una instancia funcionando, sin fricción de infraestructura a mitad del ejercicio.

Community, Cloud y Enterprise: la misma aplicación, tres maneras de operarla

Imagina que necesitas un auto para repartos diarios. Puedes comprarlo (lo mantienes tú, es tuyo, el costo es el auto más la gasolina), puedes usar un servicio de conductor por viaje (pagas por cada entrega, cero mantenimiento) o puedes contratar una flota corporativa con gerente de flota, seguros y reportes consolidados (para cuando ya no es un auto, son cuarenta). n8n ofrece exactamente esas tres formas de operar el mismo software.

n8n se distribuye bajo la Sustainable Use License (SUL) v1.0. En términos prácticos, esa licencia te permite usar, copiar, modificar y auto-hospedar n8n gratis para uso interno de tu negocio o para uso no comercial — pero te prohíbe revenderlo o hospedarlo como servicio gestionado para terceros (eso sí requiere una licencia Enterprise, como le pasaría a alguien queriendo ofrecer "n8n as a service" a sus propios clientes). Los archivos con .ee. en el nombre dentro del repositorio son la excepción: pertenecen al paquete Enterprise y necesitan una licencia separada para activarse, incluso en una instalación self-hosted.

Las tres formas de correr n8n, entonces:

• Community (self-hosted): gratis, tú administras el servidor. Incluye prácticamente todo el conjunto de nodos — incluyendo los nodos de IA (AI Agent, modelos de chat, herramientas, memoria) — más logging básico y modo queue para escalar ejecuciones.
• Cloud: n8n administra la infraestructura por ti. Pagas una suscripción mensual con un límite de ejecuciones y, en los planes intermedios, con "créditos de IA" incluidos para el uso de modelos.
• Enterprise (self-hosted o Cloud Business/Enterprise): agrega lo que una organización necesita cuando ya no es una persona operando agentes, sino varios equipos: SSO/SAML/LDAP, proyectos con permisos por equipo, compartir workflows y credenciales entre usuarios, variables y secretos externos, log streaming, alta disponibilidad (multi-main) y control de versiones vía Git.

Fíjate en algo importante: los nodos de IA no aparecen en la lista de funciones exclusivas de Enterprise. No es una omisión — es la señal de que el bucle agéntico que construiste en la lección anterior no es una función premium. Es parte del core, disponible en la edición gratuita.

La decisión por defecto: Community self-hosted

Para el perfil de esta guía — una persona o un equipo chico construyendo sus primeros agentes — Community self-hosted es el punto de partida correcto, y no por dogma "open source primero", sino por los números:

Si estás prototipando — que es exactamente lo que harás en el mini-proyecto de la próxima lección — pagar una suscripción recurrente antes de saber cuántas ejecuciones vas a necesitar es gastar por adelantado en algo que un servidor de unos dólares al mes ya resuelve. La cuenta cambia cuando el volumen de ejecuciones crece mucho (Cloud te ahorra la operación del servidor) o cuando el problema deja de ser técnico y pasa a ser organizacional (varios equipos necesitan compartir credenciales bajo un solo inicio de sesión corporativo — ahí ya estás hablando de Enterprise, sea self-hosted o Cloud Business).

Ejemplo trabajado: levantar tu instancia self-hosted con Docker

Vamos a dejar n8n corriendo localmente con Docker Compose, con dos decisiones de configuración que casi todos los tutoriales se saltan y que te van a ahorrar un dolor de cabeza real más adelante.

Primero, genera una clave de cifrado fija (sin esto, n8n genera una al azar en el primer arranque, y si algún día mueves o restauras la instancia sin esa clave, pierdes el acceso a todas las credenciales guardadas — API keys de tus modelos incluidas):

openssl rand -base64 32

Guarda el resultado en un archivo .env junto a tu docker-compose.yml:

# .env — clave de cifrado fija, no la generes cada vez
N8N_ENCRYPTION_KEY=pega_aqui_la_clave_generada

Ahora el archivo de Compose:

# docker-compose.yml
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - GENERIC_TIMEZONE=America/Mexico_City
      - TZ=America/Mexico_City
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_RUNNERS_ENABLED=true
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Levántalo:

docker compose up -d

Qué esperar: el comando descarga la imagen la primera vez (unos segundos a un par de minutos según tu conexión) y arranca el contenedor. En los logs (docker compose logs -f n8n) vas a ver una línea como:

Editor is now accessible via:
http://localhost:5678

Abre esa URL en el navegador. La primera vez te pide crear la cuenta del propietario de la instancia (nombre, correo, contraseña) — eso es local, no se envía a ningún servidor de n8n. Después entras al canvas vacío. Para confirmar que los nodos de IA están ahí sin costo extra, haz clic en "+" para agregar un nodo y busca "AI Agent" en el buscador: aparece junto a nodos como HTTP Request o Code, sin ningún candado ni aviso de plan pago. Esa instancia — con datos persistidos en el volumen n8n_data — es la que vas a usar en la próxima lección para montar tu primer agente.

Qué queda para Cloud o Enterprise

No es que Community sea "la versión pobre" — es que Cloud y Enterprise resuelven problemas distintos, que probablemente todavía no tienes:

• Operación: si no quieres administrar actualizaciones, backups ni el servidor mismo, Cloud te lo quita de encima a cambio de la suscripción mensual.
• Equipo, no persona: en cuanto necesitas que dos o más personas compartan credenciales y workflows con permisos distintos por proyecto, o que el acceso se controle desde tu proveedor de identidad corporativo (SSO/SAML/LDAP), eso vive en Enterprise — self-hosted con licencia Enterprise, o Cloud en el plan Business en adelante.
• Trazabilidad y cumplimiento: log streaming hacia un SIEM, control de versiones vía Git, alta disponibilidad con multi-main — funciones de organización, no de un agente individual.

Ninguna de estas resuelve algo que necesites para el mini-proyecto de la próxima lección. Las vas a necesitar el día que tu prototipo se convierta en un servicio que otras personas del equipo dependen.

Errores comunes

1. Pensar que self-hosted es una versión recortada de la IA (conceptual). Es fácil asumir que si algo es gratis, el motor de IA debe estar limitado o degradado respecto a Cloud. Ya lo viste en la tabla de funciones: los nodos de IA no están en la lista de exclusivos de Enterprise. El bucle agéntico — modelo, prompt, tools, memoria — es idéntico en Community y en Cloud. Lo que cambia es quién administra el servidor, no qué puede hacer el agente. Para detectarlo: si alguien te dice "en self-hosted el agente rinde menos", pídele que señale la línea exacta en la documentación de funciones — no la va a encontrar.

2. No fijar N8N_ENCRYPTION_KEY antes de guardar la primera credencial. Si dejas que n8n genere la clave sola y después mueves el contenedor a otro servidor, restauras desde un backup del volumen sin la clave, o reconstruyes el contenedor sin el mismo archivo .env, todas las credenciales guardadas (incluidas las API keys de tus modelos) quedan indescifrables. Se detecta porque n8n arranca pero los nodos con credenciales guardadas fallan con errores de autenticación que antes no pasaban. Se corrige fijando la clave desde el primer arranque, como en el ejemplo de arriba, y respaldando el archivo .env junto con el volumen.

3. Confundir "self-hosted" con "gratis del todo" (conceptual). Self-hosted elimina el costo de la licencia de n8n, no el costo total de operar un agente. Sigues pagando el servidor (aunque sea un VPS de pocos dólares) y, sobre todo, sigues pagando cada llamada al modelo de lenguaje si usas un proveedor por API. La cuenta real para comparar contra Cloud no es "$0 contra $20/mes" — es "VPS + consumo del modelo" contra "suscripción de Cloud + sus créditos de IA incluidos". Ignorar esto lleva a subestimar el costo real de un agente que hace muchas llamadas al modelo por ejecución.

Ejercicios

Ejercicio 1. Eres freelancer y automatizas tareas internas para tres clientes tuyos: un agente que resume correos, otro que clasifica tickets de soporte. Entre los dos, estimas unas 500 ejecuciones al mes. Nadie más que tú va a tocar esa instancia. ¿Community self-hosted o Cloud Starter? Justifica con al menos un número de la tabla de la lección.

Ejercicio 2. Una empresa de 40 personas quiere que el equipo de soporte y el de ventas compartan ciertos workflows y credenciales, con acceso controlado desde el proveedor de identidad corporativo (Google Workspace vía SSO). ¿Alcanza con Community self-hosted? Si no, ¿qué falta y dónde vive esa función?

Ejercicio 3. Completa el docker-compose.yml de abajo agregando la línea que falta para que las credenciales guardadas sobrevivan si alguna vez reconstruyes el contenedor en otro servidor, y explica en una frase por qué es necesaria.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    ports:
      - "5678:5678"
    environment:
      - GENERIC_TIMEZONE=America/Mexico_City
      # falta una línea aquí
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}

Resumen y siguiente paso

Aprendiste que n8n se distribuye bajo la Sustainable Use License, que Community self-hosted incluye el bucle agéntico completo sin costo de licencia, y que Cloud y Enterprise resuelven problemas de operación y de equipo — no de capacidad del agente. Levantaste una instancia local con Docker Compose, con una clave de cifrado fija desde el primer arranque, y confirmaste que el nodo AI Agent está ahí, disponible.

Antes de avanzar deberías poder: explicarle a un colega, con números, por qué Community alcanza para prototipar tus propios agentes; identificar en qué momento un equipo necesita pasar a Enterprise; y tener esa instancia de n8n corriendo en http://localhost:5678, lista para recibir un workflow.

Esa instancia es exactamente donde arranca la próxima lección: vas a abrir el canvas, arrastrar el nodo AI Agent, conectarle un modelo vigente, y probar el bucle agéntico completo — razonar, actuar, observar — respondiéndote en el chat interno de n8n.

Recursos

• Choose how to use n8n — comparación oficial entre Cloud, self-hosted y licenciamiento.
• Community Edition features — lista exacta de qué funciones quedan fuera de Community.
• Sustainable Use License v1.0 (n8n en GitHub) — texto legal completo de la licencia.
• Install n8n with Docker — comando oficial actualizado, imagen y variables recomendadas.
• Set a custom encryption key — por qué y cómo fijar N8N_ENCRYPTION_KEY.
• n8n Pricing — planes de Cloud vigentes, límites de ejecuciones y créditos de IA.