Cómo autoalojar n8n (guía 2026)

Autoalojar n8n te da la plataforma completa de automatización de workflows, sin límites de ejecución y con la propiedad total de tus datos. Esta guía repasa con honestidad la configuración real de Docker, Docker Compose y PostgreSQL, y después te muestra el atajo de 30 segundos si prefieres evitar por completo la administración del servidor.

¿Qué significa “autoalojar n8n”?

n8n es una herramienta de automatización de workflows de código disponible. A diferencia de n8n Cloud, el SaaS alojado que gestiona el equipo de n8n, autoalojar significa que tú ejecutas la aplicación n8n en una infraestructura que controlas. El software en sí es gratuito bajo una licencia fair-code, pero el cómputo, la base de datos, el almacenamiento y el ancho de banda para mantenerlo funcionando 24/7 no lo son. Autoalojar es la opción adecuada cuando quieres no tener límites de ejecución, control total sobre las credenciales y los datos, workflows ilimitados y la posibilidad de usar nodos de la comunidad y código personalizado sin que un nivel de SaaS los restrinja.

requisitos del sistema para n8n

n8n es ligero al empezar, pero escala según lo pesados que sean tus workflows. Una base realista:

• CPU: 1 vCPU basta para un uso ligero; 2+ vCPU para muchas ejecuciones simultáneas.
• RAM: De 1–2GB para n8n. Los workflows que procesan cargas grandes (archivos, imágenes, JSON grandes) necesitan más.
• Base de datos: Se recomienda encarecidamente PostgreSQL para producción. SQLite, la opción por defecto, sirve para pruebas, pero no gestiona bien la concurrencia y es más difícil de respaldar con seguridad.
• Almacenamiento: Unos pocos GB bastan para empezar; el historial de ejecuciones y los datos binarios crecen con el tiempo.
• Red: Un punto de acceso HTTPS público (puerto 443) para que funcionen los webhooks entrantes y las devoluciones de llamada de OAuth.

Para un desglose más detallado según el tamaño de los planes, consulta nuestra guía de requisitos de servidor para n8n.

Opción 1: despliega n8n con Docker

La forma más rápida de ejecutar n8n en tu propio equipo o VPS es la imagen oficial de Docker. Es ideal para una prueba local, pero ten en cuenta que usa SQLite y no tiene TLS, algo que no quieres en producción:

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Abre http://localhost:5678, crea la cuenta de propietario y tendrás un n8n funcional. Para cualquier uso real, pasa a Docker Compose con PostgreSQL.

Opción 2: Docker Compose con PostgreSQL

Una configuración de producción combina n8n con una base de datos PostgreSQL dedicada, una clave de cifrado y las URL correctas de host y webhook. Guarda esto como docker-compose.yml:

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pgdata:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      N8N_ENCRYPTION_KEY: a-long-random-string
    depends_on:
      - postgres
    volumes:
      - n8ndata:/home/node/.n8n

volumes:
  pgdata:
  n8ndata:

Después ejecuta docker compose up -d. Algunas cosas importantes: define una N8N_ENCRYPTION_KEY segura (cifra tus credenciales almacenadas; si la pierdes, tendrás que volver a introducir cada credencial), apunta WEBHOOK_URL a tu dominio HTTPS público real y nunca expongas el puerto 5678 directamente a internet sin un proxy inverso delante.

Lo que los tutoriales de autoalojamiento se saltan

Poner n8n en marcha es el 20% fácil. Mantenerlo funcionando de forma segura es el otro 80%, y ahí es donde un VPS sin gestionar te pasa factura:

• Certificados TLS: Necesitas HTTPS para los webhooks y OAuth. Eso significa Caddy, Traefik o Nginx más Let’s Encrypt, y una renovación de certificados que no debe fallar.
• Webhooks y proxy inverso: Los webhooks entrantes requieren una URL pública estable y cabeceras de proxy correctas, o los disparadores fallan en silencio.
• Copias de seguridad: Tus workflows, credenciales e historial de ejecuciones viven en PostgreSQL. Necesitas copias de seguridad de la base de datos automatizadas y probadas: una copia de seguridad que no se ha probado no es una copia de seguridad.
• Actualizaciones: n8n publica versiones con frecuencia. Eres responsable de descargar las imágenes nuevas, leer las notas de cambios incompatibles y migrar la base de datos.
• Tiempo de actividad: Un solo VPS es un único punto de fallo. Si el host se reinicia a las 2 a. m., tus workflows programados y tus webhooks se detienen hasta que lo notes.

Preguntas frecuentes