n8n autoalojado: cómo ejecutar n8n en tu propio servidor

Llevas seis meses viendo cómo sube tu factura de Zapier.

Cada flujo de trabajo nuevo agrega una línea al recibo, y cada paso de acción completado con éxito cuenta como una tarea. La factura mensual ya cuesta más que tu herramienta de gestión de proyectos.

Empiezas a buscar alternativas en Google y das con n8n, una plataforma de automatización que puedes autoalojar en tu propio servidor privado virtual (VPS) por lo que cuesta un servidor pequeño.

Sin topes de ejecuciones. Sin cobros por tarea. Sin facturas sorpresa cuando tus automatizaciones despegan.

Y sí, aquí te acompañamos en todo el proceso, comando por comando: de un servidor Ubuntu recién entregado a una instancia funcionando con HTTPS, respaldos y una restauración ya probada.

¿Qué es n8n y por qué tanta gente lo autoaloja?

n8n es una plataforma de automatización de flujos de trabajo: te permite conectar aplicaciones, mover datos entre servicios y construir automatizaciones complejas desde un editor visual. Piensa en n8n como el motor detrás de “cuando pase X, haz Y y Z”, solo que en lugar de escribir código, arrastras nodos y trazas conexiones.

El proyecto ya superó las 200,000 estrellas en GitHub (en inglés), y su imagen oficial de Docker registra más de 100 millones de descargas (en inglés). Hay muchísimos servidores ejecutando n8n.

La plataforma se distribuye bajo la Sustainable Use License (licencia de uso sostenible, en inglés), y conviene entenderla antes de comprometerte. No es código abierto tradicional (la propia n8n dice que no usa ese término, porque las licencias aprobadas por la OSI no pueden restringir el uso), pero tampoco es un candado. Puedes ejecutarla libremente para los fines internos de tu negocio; lo que no puedes hacer es vender un producto, servicio o módulo cuyo valor derive total o sustancialmente de la funcionalidad de n8n.

“En la práctica, esto significa que todo uso está permitido, salvo que vendas un producto, servicio o módulo cuyo valor derive total o sustancialmente de la funcionalidad de n8n”, según las preguntas frecuentes de la licencia de n8n (en inglés).

La gente autoaloja n8n porque las cuentas cambian en cuanto superas el uso básico. n8n Cloud (en inglés) parte de €20 al mes (con facturación anual) por 2,500 ejecuciones en el plan Starter, y si manejas un volumen real, ese límite aparece rápido. Si el concepto te suena nuevo, tenemos una guía sobre qué es el autoalojamiento (en inglés).

¿Y en tu propio VPS? Sin tope de ejecuciones, con control sobre los datos que tu instancia de n8n almacena y sin factura de licencias ni de ejecuciones de n8n, aunque el servidor, el dominio, el almacenamiento para respaldos y la administración siguen teniendo su costo. Las ejecuciones en sí no cuestan nada extra; eso sí, un volumen mayor consume más memoria y almacenamiento, pero esa es una cuestión de dimensionamiento (la vemos más abajo), no de facturación.

¿Qué puedes automatizar con n8n?

Las más de 400 integraciones de n8n cubren un rango muy amplio, y los nodos creados por la comunidad extienden la lista todavía más. n8n es, además, una de tantas alternativas autoalojadas a las herramientas SaaS; la misma lógica aplica a todo, desde el CRM hasta la gestión de proyectos.

Algunas configuraciones comunes:

• CRM y distribución de leads. Sincroniza contactos entre tu CRM, tu plataforma de correo y Slack cuando lleguen prospectos nuevos.
• Flujos activados por webhooks. Responde en tiempo real a eventos de procesadores de pago, envíos de formularios o commits de GitHub.
• Automatización de pipelines de datos. Extrae datos mediante distintas API, transfórmalos y envíalos a bases de datos u hojas de cálculo según un calendario.
• Cadenas de agentes de IA. Conecta modelos de lenguaje de gran tamaño (LLM, por sus siglas en inglés) con tus herramientas internas para crear asistentes de IA a la medida que buscan, resumen y actúan sobre tus datos.

(En esa última configuración empiezan a importar los recursos de tu servidor; hablamos de eso en la sección de especificaciones.)

¿Cuánto cuesta autoalojar n8n?

La Community edition autoalojada no cobra licencias ni ejecuciones de n8n para los usos permitidos. Tu costo total incluye el servidor, más el dominio, el almacenamiento para respaldos y el tiempo de administración que apliquen. El desglose de costos 2026 de ExpressTech (en inglés) calcula $4–5 USD al mes para un VPS básico con Docker, $5–8 para un VPS administrado con Coolify, y $3–7 para las plataformas que instalan n8n con un clic.

Esas son las estimaciones de ExpressTech para hosting de terceros. Un dato de primera mano: el plan que recomendamos más abajo, DreamHost VPS Hosting Stack 4, cuesta $8.99 USD al mes durante los primeros 3 meses con facturación mensual y se renueva automáticamente a $15.99 USD al mes después, a agosto de 2026, y el periodo completo, más impuestos, se cobra al finalizar la compra (los precios vigentes están en la página de VPS con n8n).

Compáralo con los planes alojados y con licencia de n8n, tal como aparecen en la página de precios de n8n. n8n publica sus precios en euros; estas son las tarifas con facturación anual:

Plan	Costo mensual	Límite de ejecuciones
n8n Cloud Starter	€20/mes	2,500 ejecuciones
n8n Cloud Pro	€50/mes	10,000 ejecuciones
n8n Business (licencia autoalojada)	€667/mes	40,000 ejecuciones
Community edition autoalojada en un VPS	Sin licencias ni cobros por ejecución de n8n para los usos permitidos; el VPS, el dominio, el almacenamiento para respaldos y la administración pueden sumar costos	Sin tope

La brecha se amplía cuando consideras cómo mide el uso cada plataforma. n8n cobra una ejecución por cada corrida de un flujo de trabajo, “sin importar la complejidad”, y todos los planes incluyen pasos ilimitados. Zapier, en cambio, cuenta cada paso de acción exitoso como una tarea (en inglés).

Así, un flujo con cuatro pasos de acción que se ejecuta 100 veces al día suma 3,000 ejecuciones de n8n al mes, pero alrededor de 12,000 tareas de Zapier.

Los números lo respaldan. El análisis de ExpressTech desarrolla un ejemplo con cuatro flujos de trabajo que suman unas 7,000 ejecuciones al mes: esa carga rebasa el plan Starter de n8n Cloud y exige el nivel Pro (que ahí aparece a $60 USD mensuales con facturación mensual), mientras que una instalación autoalojada de $3–7 USD al mes la ejecuta sin límites. La diferencia que calculan: entre $636 y $684 USD al año.

Los costos ocultos del autoalojamiento

El ahorro en dinero es real. Pero autoalojar no es gratis en todos los sentidos.

Esto es lo que te cuesta:

Tu tiempo. El tiempo de mantenimiento varía según tu carga de trabajo y tu experiencia operando servidores, pero las actualizaciones, los respaldos, el monitoreo y las pruebas de restauración corren por tu cuenta. Las instalaciones más pesadas, con automatizaciones de IA, exigen más.

La fricción de configurar OAuth. Conectar servicios como Google Workspace o Microsoft 365 requiere configurar credenciales OAuth: reserva tiempo adicional para cada proveedor y sigue la documentación de su consola. (Si alguna vez has visto girar la ruedita de carga mientras una pantalla de consentimiento decide si confía en tu aplicación, sabes de qué hablamos.)

La renovación de TLS también necesita supervisión. El proxy Caddy de la configuración de abajo obtiene y renueva automáticamente un certificado de confianza pública, con un emisor como Let’s Encrypt o ZeroSSL. Automático no es lo mismo que irrompible: después de un cambio de DNS o de proxy, confirma que el certificado se siga renovando.

La curva de aprendizaje si no tienes experiencia con servidores. La guía de abajo asume que sabes entrar a un servidor por SSH, editar un archivo y ejecutar comandos. Si nunca lo has hecho, presupuesta tiempo de aprendizaje además del despliegue en sí.

¿Qué especificaciones de servidor necesita n8n?

n8n, por sí solo, es ligero. Lo más cercano a un dimensionamiento oficial son las cifras de ejemplo de la documentación OEM de n8n (en inglés), que n8n etiqueta como “solo con fines ilustrativos” y que se basan en n8n Cloud: un rango de memoria de 320 MB a 2 GB, una base de datos de 512 MB a 4 GB sobre SSD, y alrededor de 100 MB de memoria para una instancia inactiva. Como punto de partida prudente, no como un mínimo oficial de n8n, considera 2 GB para pruebas y 4 GB cuando sumes PostgreSQL y flujos de producción. Monitorea flujos representativos y agrega memoria cuando aparezca presión sostenida.

Recuerda además que n8n suele depender más de la memoria que de la CPU. La propia documentación lo dice sin rodeos: la plataforma “no es intensiva en CPU” y, “por lo general, los requisitos de memoria superan a los de CPU”. Lo que dispara la memoria son tus flujos de trabajo: el volumen de datos, los nodos Code (que copian los datos antes y después de procesarlos) y los archivos binarios grandes.

Nuestra regla rápida para dimensionar con holgura:

Dimensiona según la concurrencia de ejecuciones y el volumen de datos que procesa cada flujo, y luego observa el uso de memoria con una carga representativa. Los nodos Code y los archivos binarios pesados pueden elevar los requisitos de memoria, así que deja margen y escala el VPS cuando el monitoreo muestre presión sostenida.

¿Primera vez con un VPS? Empieza con la guía de VPS para principiantes de DreamHost (en inglés) para dominar lo básico antes de dimensionar tu servidor.

¿Qué VPS te conviene para autoalojar n8n?

n8n no publica niveles fijos de RAM por tipo de carga. Dimensiona según la concurrencia de ejecuciones y el volumen de datos, deja margen para Docker y PostgreSQL, y luego monitorea flujos representativos y escala cuando la presión de memoria sea sostenida.

Con esa lógica, así traducimos esos criterios a los planes de DreamHost:

Plan	Especificaciones	Cuándo elegirlo
DreamHost VPS Hosting Stack 4	4 GB de RAM, 2 vCPU, 75 GB NVMe SSD	Un punto de partida prudente de 4 GB para un primer servidor de n8n, aunque no está respaldado por pruebas propias.
DreamHost VPS Hosting Stack 8	8 GB de RAM, 2 vCPU, 150 GB NVMe SSD	La opción de 8 GB para más margen de memoria cuando el monitoreo muestra presión sostenida, con el doble de RAM y de almacenamiento.
DreamHost VPS Hosting Stack 16	16 GB de RAM, 4 vCPU, 250 GB NVMe SSD	La opción de 16 GB para más concurrencia, volúmenes de datos mayores o para sumar workers de Redis en modo de cola.

Un par de especificaciones que pesan más allá de la RAM: n8n señala el almacenamiento SSD como una buena práctica para la base de datos. La memoria suele importar más que la CPU, pero el cuello de botella real depende de la concurrencia de tus flujos, el volumen de datos y los nodos que uses. Y el ancho de banda sin medición importa si ejecutas cargas intensivas en webhooks, con un flujo constante de solicitudes HTTP entrantes.

Elige un entorno de hosting que te permita ejecutar Docker y configurar la base de datos, la red, el almacenamiento persistente y el proxy inverso. El hosting compartido convencional normalmente no ofrece ese nivel de control.

Los planes de VPS Hosting de DreamHost cumplen con todo lo esencial (almacenamiento NVMe SSD, ancho de banda sin medición, acceso root completo y soporte para Docker), y n8n está en la biblioteca de aplicaciones de un clic, preinstalado con PostgreSQL y SSL automático, por si prefieres saltarte la instalación manual que viene a continuación.

Nuestra elección para un primer servidor de n8n es Stack 4. A agosto de 2026, cuesta $8.99 USD al mes durante los primeros 3 meses con facturación mensual y se renueva automáticamente a $15.99 USD al mes, y el periodo completo, más impuestos, se cobra al finalizar la compra; la página de VPS con n8n siempre muestra las tarifas vigentes. Ese precio de renovación es el número honesto para comparar contra los €20 al mes del Starter de n8n Cloud.

Ah, y un dato que conviene guardar para más adelante: cuando tu uso crezca, n8n soporta el modo de cola (queue mode), una arquitectura de escalado que separa la instancia principal (interfaz, disparadores, webhooks) de la ejecución de los flujos, usando Redis como intermediario de mensajes e instancias worker que procesan los trabajos. La documentación de n8n (en inglés) lo describe como el modo que “ofrece la mejor escalabilidad”.

¿Cómo se instala n8n en un VPS?

Desplegar una instancia autoalojada de n8n toma 11 pasos: DNS, refuerzo de SSH, firewall, Docker, secretos, un archivo de Compose para el conjunto de tres contenedores (n8n, PostgreSQL y Caddy), el Caddyfile, arranque y verificación, actualizaciones, respaldos y una prueba de restauración. Caddy es nuestro proxy inverso: el servidor que se coloca entre internet y tu aplicación para encargarse del TLS y del enrutamiento. Incluimos los comandos del despliegue central y de una prueba manual de respaldo y restauración.

Los comandos están pensados para Ubuntu 22.04 o más reciente; sustituye el dominio de ejemplo, los valores secretos, el nombre del volumen y los nombres de respaldo con fecha donde se te indique. La documentación de Docker Compose de n8n (en inglés) cubre el mismo terreno con un proxy Traefik, por si prefieres seguir la plantilla de la propia n8n.

Lo que necesitas antes de empezar

• Un VPS con acceso root que ejecute Ubuntu 22.04 o más reciente, con al menos 2 GB de RAM (4 GB es nuestra recomendación prudente para producción)
• Un nombre de dominio que puedas apuntar a la dirección IP de tu servidor (para el TLS y para acceder al editor de n8n)
• Soltura básica en la terminal: saber entrar a un servidor por SSH, editar un archivo y ejecutar comandos

Un requisito más que no aparece en ninguna lista oficial: respalda tu N8N_ENCRYPTION_KEY en cuanto la generes. Por eso el paso 5 te pide crear la clave con openssl rand -hex 32 antes del primer arranque, en lugar de dejar que n8n genere una en silencio. Esta clave cifra todas tus credenciales almacenadas, incluida cada clave de API, cada token de OAuth y cada contraseña de base de datos que hayas conectado. La propia documentación de Docker de n8n advierte que, si la clave no aparece al arrancar, n8n crea una nueva y las credenciales existentes ya no se pueden descifrar. Es decir: a reconstruir cada integración desde cero (mientras lamentas tus decisiones de vida). Cópiala en un lugar seguro, separada de los respaldos de tu base de datos.

Si tu proveedor solo te entregó un acceso root, crea primero un usuario de despliegue, desde la consola del proveedor o desde una sesión SSH como root, antes de los comandos locales de SSH del paso 2:

adduser deploy
usermod -aG sudo deploy

Todo lo que sigue se ejecuta con ese usuario, con sudo donde haga falta.

Paso 1: apunta tu dominio al servidor

Crea un registro DNS de tipo A para un subdominio dedicado (n8n.example.com a lo largo de esta guía) que apunte a la dirección IP de tu servidor, tal como lo describe la guía de Docker Compose de n8n. Hazlo primero: si el DNS no se ha propagado, Caddy no puede obtener el certificado y tu navegador puede mostrar un error de seguridad en lugar del editor de n8n.

Paso 2: refuerza el acceso por SSH

En tu máquina local, genera un par de claves (la documentación de OpenSSH de Ubuntu, en inglés, recomienda ed25519) y cópialo al servidor:

ssh-keygen -t ed25519
ssh-copy-id deploy@your_server_ip

Confirma que puedes iniciar sesión con la clave. Luego, en el servidor, desactiva el acceso con contraseña y el acceso como root, y revisa qué va a aplicar sshd en realidad:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
EOF
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '

El prefijo 00- es deliberado. OpenSSH usa el primer valor que lee para cada directiva, según el manual de sshd_config (en inglés), y las imágenes de servidores en la nube suelen traer archivos previos en ese mismo directorio (cloud-init, por ejemplo, escribe su configuración de SSH en 50-cloud-init.conf). Si nombras tu archivo 99-hardening.conf, cualquiera de esos fragmentos puede ganarle sin que lo notes. sshd -t revisa que la configuración no tenga errores; sshd -T imprime la configuración efectiva después de combinar todos los archivos. Confirma que el último comando imprima passwordauthentication no y permitrootlogin no antes de seguir adelante. Después reinicia sshd:

sudo systemctl restart ssh.service

La documentación de Ubuntu advierte que una configuración de sshd defectuosa en un servidor remoto puede dejarte fuera. Mantén abierta tu sesión actual y prueba un inicio de sesión nuevo en una segunda terminal antes de cerrar nada.

Paso 3: activa el firewall

Ubuntu trae UFW (Uncomplicated Firewall) desactivado de fábrica. Permite el SSH antes de activarlo, para que el firewall no corte tu propia sesión:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo ufw status

Tres puertos y nada más. Una advertencia específica de Docker, tomada de su propia documentación de instalación (en inglés): las reglas de UFW no se aplican a los puertos que Docker publica en el host. Por eso el archivo compose del paso 6 solo publica puertos del host para Caddy: los únicos puertos de contenedor que Compose publica son el 80 y el 443 (el 22 de SSH también está abierto), y ni n8n ni PostgreSQL publican puerto alguno en el host.

Paso 4: instala Docker y Docker Compose

Instala Docker Engine desde el repositorio apt oficial de Docker, no con el script de conveniencia de get.docker.com, que la documentación de Docker recomienda solo para pruebas y desarrollo. Primero los prerrequisitos y la clave de firma de Docker:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Después registra el repositorio. Este comando escribe el archivo del repositorio según la guía de instalación de Docker para Ubuntu, completando tu versión de Ubuntu automáticamente:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Luego instala y verifica:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

Si hello-world imprime su mensaje de confirmación, Docker y el plugin de Compose están listos.

Paso 5: crea el directorio del proyecto y los secretos

Crea el directorio del proyecto y genera después tu clave de cifrado; no dejes que n8n invente una en silencio en el primer arranque:

sudo mkdir -p /opt/n8n-compose
cd /opt/n8n-compose
openssl rand -hex 32

Copia el resultado en un lugar seguro ahora mismo, fuera del servidor. Después ponlo, junto con una contraseña fuerte para la base de datos, en un archivo .env protegido junto a tu archivo compose (Docker Compose lo lee automáticamente). Sustituye ambos valores de ejemplo por los tuyos:

sudo tee /opt/n8n-compose/.env > /dev/null <<'EOF'
POSTGRES_PASSWORD=choose_a_strong_password
N8N_ENCRYPTION_KEY=paste_the_64_character_key_you_just_generated
EOF
sudo chmod 600 /opt/n8n-compose/.env

El chmod 600 importa: este archivo guarda secretos, así que solo su dueño (root) debe poder leerlo. En el archivo compose, N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true aplica la misma idea dentro del contenedor: según la referencia de variables de seguridad de n8n (en inglés), hace que n8n intente fijar permisos 0600 en su propio archivo de configuración.

Paso 6: escribe el archivo de Docker Compose

Crea /opt/n8n-compose/docker-compose.yml (por ejemplo, con sudo nano /opt/n8n-compose/docker-compose.yml) y pega lo siguiente, cambiando n8n.example.com por tu propio dominio en las dos líneas de URL y ajustando tu zona horaria (por ejemplo, America/Mexico_City):

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.36.7
    restart: unless-stopped
    expose:
      - "5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=America/New_York
      - TZ=America/New_York
      - EXECUTIONS_DATA_MAX_AGE=168
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - n8n_data:/home/node/.n8n

  postgres:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=n8n
      - PGDATA=/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  caddy_data:
  caddy_config:
  n8n_data:
  postgres_data:

Cinco detalles de ese archivo se ganan su lugar:

• La imagen está fijada a una versión específica (2.36.7 es la versión estable al momento de escribir esto, según la documentación de instalación de n8n), para que las actualizaciones solo ocurran cuando tú lo decidas.
• n8n no publica ningún puerto del host. Los contenedores de la red de Compose, incluido Caddy, pueden comunicarse con n8n, pero no hay puerto del host publicado, así que al editor solo se puede llegar a través del proxy inverso, nunca directamente desde internet.
• El healthcheck hace que n8n espere a PostgreSQL. Un depends_on a secas solo espera a que el contenedor arranque, no a que la base de datos acepte conexiones. El patrón condition: service_healthy viene directo del archivo compose de ejemplo con Postgres de n8n (en inglés), que también despliega PostgreSQL 18.
• El par N8N_WEBHOOK_URL / N8N_PROXY_HOPS importa detrás de un proxy. n8n normalmente construye las URLs de sus webhooks a partir del protocolo, el host y el puerto, y la documentación de n8n (en inglés) advierte que eso no funciona detrás de un proxy inverso. Por eso defines la URL de los webhooks a mano, para que n8n pueda “registrar las URLs de webhook correctas con los servicios externos”, fijas N8N_PROXY_HOPS en 1 y te aseguras de que el proxy pase los encabezados X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. (La misma página señala que N8N_WEBHOOK_URL sustituye a la antigua WEBHOOK_URL, obsoleta desde n8n 2.35.0.)
• TZ y GENERIC_TIMEZONE hacen trabajos distintos. Según la documentación de Docker de n8n, GENERIC_TIMEZONE gobierna los nodos de programación, como Schedule, mientras que TZ define la zona horaria del sistema dentro del contenedor (lo que reportan comandos como date). Asigna el mismo valor a ambas.

(Empieza con PostgreSQL desde el primer día. n8n usa SQLite de forma predeterminada, que sirve para pruebas, pero las plantillas de hosting de n8n recomiendan PostgreSQL para producción, y migrar después duele, de esos dolores de “ojalá lo hubiera hecho bien desde el principio”.)

Paso 7: escribe el Caddyfile

Crea /opt/n8n-compose/Caddyfile con tu dominio (otra vez, reemplaza n8n.example.com):

n8n.example.com {
    reverse_proxy n8n:5678
}

Esa es toda la configuración del proxy inverso. Según la documentación de HTTPS automático de Caddy (en inglés), Caddy obtiene y renueva automáticamente un certificado de confianza pública, con un emisor como Let’s Encrypt o ZeroSSL, y redirige el tráfico HTTP a HTTPS, siempre que tu registro DNS de tipo A apunte al servidor y los puertos 80 y 443 estén abiertos (pasos 1 y 3). Caddy es, además, uno de los proxies inversos de los ejemplos oficiales de hosting de n8n.

Paso 8: arranca y verifica

cd /opt/n8n-compose
sudo docker compose up -d
sudo docker compose ps

Espera a que ps muestre el contenedor de postgres como healthy y n8n en ejecución, y luego prueba la puerta de entrada desde cualquier máquina:

curl -fsS -o /dev/null -w '%{http_code}' https://n8n.example.com/

Un código 2xx (o una redirección 3xx) significa que Caddy gestionó la conexión TLS y n8n respondió; si curl termina con un error, hay que revisar el DNS, el certificado o los contenedores (sudo docker compose logs caddy y sudo docker compose logs n8n son los primeros lugares donde mirar). Abre https://n8n.example.com en un navegador y crea tu cuenta de propietario.

Paso 9: actualiza n8n con toda la intención

n8n publica una nueva versión menor casi cada semana, y sus instrucciones de actualización piden revisar el registro de cambios incompatibles antes de actualizar. Cuando estés listo: edita la etiqueta de versión en docker-compose.yml y luego

cd /opt/n8n-compose
sudo docker compose pull
sudo docker compose up -d

Con una etiqueta fijada, descargar la imagen no cambia nada por sí solo: cada actualización la eliges tú al cambiar la etiqueta, y ese es justamente el propósito de fijarla. Ejecuta un respaldo (paso 10) antes de las actualizaciones de versión mayor.

Paso 10: programa los respaldos

Para una restauración utilizable se requieren tres cosas: la base de datos PostgreSQL, el volumen n8n_data y el archivo .env que aporta la N8N_ENCRYPTION_KEY. La documentación de Docker de n8n es explícita: incluso cuando usas PostgreSQL, la carpeta /home/node/.n8n (nuestro volumen n8n_data) sigue guardando datos esenciales, incluido el material de la clave de cifrado. Respalda las tres cosas y conserva docker-compose.yml y el Caddyfile para poder reconstruir el conjunto. El script de abajo se encarga de la base de datos y del volumen; copiar los archivos de configuración fuera del servidor viene justo después. Crea el script como un archivo propiedad de root:

sudo tee /opt/n8n-compose/backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
cd /opt/n8n-compose
STAMP=$(date +%Y-%m-%d)
mkdir -p /opt/n8n-backups
docker compose exec -T postgres pg_dump -U n8n -d n8n > "/opt/n8n-backups/n8n-db-${STAMP}.sql"
docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  tar czf "/backup/n8n-data-${STAMP}.tar.gz" -C /data .
find /opt/n8n-backups -name 'n8n-db-*.sql' -mtime +30 -delete
find /opt/n8n-backups -name 'n8n-data-*.tar.gz' -mtime +30 -delete
EOF
sudo chmod 700 /opt/n8n-compose/backup.sh
sudo /opt/n8n-compose/backup.sh

Notas sobre el script: n8n-compose_n8n_data es el nombre de volumen que Compose crea para un directorio de proyecto llamado n8n-compose; confirma el tuyo con sudo docker volume ls y ajústalo si difiere. Las dos líneas de find conservan 30 días de respaldos; define otra retención según tu almacenamiento y tus necesidades de recuperación.

Prográmalo desde el crontab de root. El cron de root solo debe ejecutar un script propiedad de root (chmod 700, con el .env en 600), nunca un archivo que otro usuario pueda editar. Ejecuta sudo crontab -e y agrega una línea para una corrida diaria a las 3 a.m.:

0 3 * * * /opt/n8n-compose/backup.sh

El script respalda la base de datos PostgreSQL y el volumen n8n_data según el calendario. Copia el .env (que contiene tu clave de cifrado) y los archivos de Compose y de Caddy fuera del servidor ahora y cada vez que cambien. En el servidor, crea un archivo comprimido temporal y protegido:

sudo tar -C /opt/n8n-compose -czf /home/deploy/n8n-config.tar.gz .env docker-compose.yml Caddyfile
sudo chown deploy:deploy /home/deploy/n8n-config.tar.gz
chmod 600 /home/deploy/n8n-config.tar.gz

Después, desde tu máquina local, descarga ese archivo de configuración junto con los respaldos y borra la copia temporal del servidor:

scp deploy@your_server_ip:/home/deploy/n8n-config.tar.gz .
scp -r deploy@your_server_ip:/opt/n8n-backups .
ssh deploy@your_server_ip 'rm /home/deploy/n8n-config.tar.gz'

Un respaldo que solo existe en el servidor que protege desaparece junto con el servidor.

Paso 11: prueba una restauración en un VPS desechable

Este es un procedimiento de respaldo y restauración para comprobar que tus respaldos sirven. Haz la prueba en un VPS desechable recién creado, nunca en tu servidor de producción. Contrata un servidor temporal, repite ahí el paso 4 (Docker) y copia tus archivos de proyecto (docker-compose.yml, Caddyfile, .env) y tus respaldos con fecha más recientes en las mismas rutas.

Primero, cambia el hostname: pon uno de prueba (digamos, n8n-restore-test.example.com, con un registro A apuntando al VPS desechable) en N8N_HOST, N8N_WEBHOOK_URL y el Caddyfile. Después, sustituyendo los nombres de archivo con fecha por los tuyos:

cd /opt/n8n-compose
sudo docker compose create
sudo docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  sh -c "cd /data && tar xzf /backup/n8n-data-2026-08-25.tar.gz"
sudo docker compose up -d --wait postgres
sudo docker compose exec -T postgres psql -U n8n -d n8n < /opt/n8n-backups/n8n-db-2026-08-25.sql
sudo docker compose run --rm n8n unpublish:workflow --all
sudo docker compose up -d

La línea unpublish:workflow --all usa la Server CLI integrada de n8n (en inglés) para despublicar cada flujo restaurado antes de que la instancia arranque, de modo que los horarios y disparadores restaurados no se activen contra tus sistemas de producción desde la máquina de prueba. Termina con la misma verificación de curl del paso 8, contra el hostname de prueba.

Sé honesto contigo sobre lo que significa una verificación exitosa: confirma que la base de datos y el volumen se restauraron y que el conjunto arranca correctamente. No ejercita tus flujos en el editor, así que inicia sesión en la instancia de prueba y revisa a mano los que no puedes darte el lujo de perder.

¿Cómo mantener segura una instancia autoalojada de n8n?

Una instancia autoalojada de n8n es tan segura como el servidor donde se ejecuta, y ese servidor lo controlas tú.

La seguridad se reduce a seis puntos. Ninguno es complicado por sí solo, pero saltarte cualquiera deja un hueco real. La configuración de arriba ya implementa los primeros tres.

1. HTTPS a través de un proxy inverso. Nunca entres al editor de n8n por HTTP simple. La configuración de Caddy del paso 7 obtiene y renueva automáticamente un certificado de confianza pública, con un emisor como Let’s Encrypt o ZeroSSL, y redirige HTTP a HTTPS.
2. Firewall bien cerrado. UFW solo permite SSH (22), HTTP (80) y HTTPS (443). Nunca expongas el puerto predeterminado de n8n, el 5678, directamente a internet. El archivo compose de arriba lo garantiza al no publicar ningún puerto del host para n8n, así que solo los contenedores de la red de Compose pueden alcanzarlo.
3. Aislamiento de red en Docker. PostgreSQL y n8n se comunican por la red interna de Compose. El puerto de tu base de datos nunca se publica en el host, así que nunca es accesible desde afuera.
4. Autenticación fuerte. Usa una contraseña de propietario fuerte y activa la autenticación de dos factores; la guía de seguridad de n8n (en inglés) incluye el 2FA entre sus protecciones recomendadas para instancias autoalojadas.
5. Actualizaciones regulares. Actualiza la etiqueta de versión en tu archivo compose, descarga la imagen y reinicia (paso 9). Lee primero el registro de cambios, porque las actualizaciones de n8n pueden incluir cambios incompatibles.
6. Respaldos que ya restauraste. Los pasos 10 y 11 te dan el calendario y la prueba. Un respaldo que nunca has probado es una esperanza, no un plan.

Hay un detalle más que vigilar; no es estrictamente de seguridad, pero marca una gran diferencia. De forma predeterminada, n8n guarda en su base de datos la entrada y la salida de cada ejecución. La limpieza automática viene activada (en inglés): n8n borra las ejecuciones con más de 336 horas, es decir, 14 días, o cuando superas las 10,000 ejecuciones almacenadas. Aun así, una instancia con mucho movimiento puede inflar PostgreSQL entretanto.

Si tus flujos son parlanchines, ajusta la limpieza: define EXECUTIONS_DATA_MAX_AGE=168 para borrar los datos de ejecución con más de siete días (el archivo compose de arriba ya lo hace), o deja de guardar por completo las ejecuciones exitosas con EXECUTIONS_DATA_SAVE_ON_SUCCESS=none.

¿Qué sacrificas al autoalojar frente a usar n8n Cloud?

Autoalojar n8n te da una instancia sin tope de ejecuciones y con control sobre los datos que almacena, por el costo de un VPS pequeño más tu propia administración. n8n Cloud te da cero mantenimiento de servidor, con topes de ejecuciones según el nivel. La decisión se reduce a si quieres ser dueño de tu infraestructura de automatización o pagarle a alguien más para que la administre.

La documentación de n8n lo plantea así: “n8n recomienda el autoalojamiento para usuarios expertos. Los errores pueden causar pérdida de datos, problemas de seguridad y tiempo de inactividad. Si no tienes experiencia administrando servidores, n8n recomienda n8n Cloud”.

Así se comparan las dos opciones:

Factor	Autoalojado	n8n Cloud
Costo mensual	Tu factura de VPS, más el dominio, el almacenamiento para respaldos y la administración que apliquen (DreamHost Stack 4: $8.99 USD/mes por 3 meses y luego $15.99 USD/mes, a agosto de 2026; estimaciones de terceros de ExpressTech para 2026: $4–8 USD/mes)	€20–50 (facturación anual), según el nivel
Ejecuciones	Sin tope; la capacidad depende de los recursos de tu servidor	2,500 (Starter) o 10,000 (Pro)
Instalación	La guía de 11 pasos de arriba	Minutos
Mantenimiento	Las actualizaciones, los respaldos y el monitoreo corren por tu cuenta	Lo maneja n8n
Ubicación de los datos	Tu servidor	La infraestructura de n8n
Actualizaciones	Manuales (cambias la etiqueta, descargas la imagen y reinicias)	Automáticas
TLS	Caddy obtiene y renueva los certificados automáticamente (con un emisor como Let’s Encrypt o ZeroSSL)	Incluido
Escalado	Agrega RAM o usa el modo de cola con workers de Redis	Sube de nivel de plan

También existe un punto intermedio que vale la pena conocer. Plataformas administradas como PikaPods (alrededor de $3.80 USD al mes) y Elestio (alrededor de $17 USD al mes, según la comparación de ExpressTech) ejecutan n8n autoalojado sin que tú administres el servidor. Estos servicios pueden reducir el trabajo de administración, aunque conviene verificar quién se encarga de las actualizaciones de n8n, los respaldos, el monitoreo y la seguridad.

Pero mira el panorama completo. En cualquier plan alojado, tu capacidad de ejecución es un nivel de facturación, y los niveles los define la plataforma. Los precios, los topes y las funciones pueden cambiar después de que ya construiste flujos que dependen de la plataforma.

Con el autoalojamiento, la instancia y los datos que almacena se alojan en infraestructura que tú controlas (los servicios conectados siguen recibiendo lo que tus flujos les envían). Control total, responsabilidad total.

La decisión final: ¿te conviene autoalojar?

Autoalojar tiene sentido cuando se alinean tres cosas:

1. Ejecutas suficientes automatizaciones como para que los topes de ejecuciones de la nube te aprieten
2. Quieres los datos de tus flujos de trabajo en infraestructura que tú controlas
3. Tú, o alguien de tu equipo, está dispuesto a encargarse de las actualizaciones, los respaldos y el monitoreo

Si no, n8n Cloud es una opción razonable. Pagar el plan Starter para no pensar nunca en los registros de Docker es un intercambio justo, sobre todo para un equipo pequeño que solo quiere que sus automatizaciones funcionen.

Pero cuando estés listo para cruzar el umbral del autoalojamiento, la ventaja económica se vuelve clara muy rápido. Un VPS de 4 GB es un punto de partida práctico, aunque no está respaldado por pruebas propias; la capacidad de producción depende de la concurrencia, el volumen de datos y los nodos que uses, así que monitorea la instancia y escálala conforme crezca la demanda. Empieza pequeño, mejora el plan cuando tus flujos crezcan y conserva el control total de tu stack.

Esa última parte importa más de lo que parece. Siempre puedes pasarte a un servidor más grande. Desvincularte de una plataforma SaaS después de que cambió los precios de los que dependen los flujos que ya construiste es mucho más difícil.

Preguntas frecuentes sobre el autoalojamiento de n8n

¿De verdad es gratis autoalojar n8n?

El software de n8n es gratuito en tu propio servidor bajo la Sustainable Use License. La Community edition autoalojada (la versión estándar que n8n publica en GitHub) no cobra licencias ni ejecuciones de n8n para los usos permitidos, como la automatización interna de un negocio. Lo “gratis” es el software: el servidor lo sigues pagando tú, más el dominio, el almacenamiento para respaldos y el tiempo de administración que apliquen.

La licencia restringe vender un producto, servicio o módulo cuyo valor derive total o sustancialmente de la funcionalidad de n8n. Revisa las preguntas frecuentes de la licencia de n8n si planeas ofrecer funciones basadas en n8n a tus clientes.

¿Cuáles son los requisitos mínimos del sistema para n8n?

n8n publica ejemplos de dimensionamiento en lugar de un mínimo estricto, y etiqueta esas cifras como ilustrativas (salen de su documentación de despliegue OEM): unos 100 MB de memoria en reposo, un rango de ejemplo de 320 MB a 2 GB, y una base de datos de 512 MB a 4 GB sobre SSD. Como punto de partida prudente, no como un mínimo oficial de n8n, considera 2 GB para pruebas y 4 GB cuando sumes PostgreSQL y flujos de producción; después monitorea y agrega memoria cuando aparezca presión sostenida.

El plan Stack 4 de DreamHost VPS Hosting ofrece 4 GB de RAM con almacenamiento NVMe SSD y acceso root completo para ejecutar aplicaciones autoalojadas como n8n. Consulta los planes de VPS Hosting para ver los detalles.

Usa PostgreSQL en lugar de SQLite para producción, y da preferencia al almacenamiento SSD, que n8n señala como buena práctica para la base de datos.

¿Puedo ejecutar n8n en mi computadora en lugar de un VPS?

Sí: un solo comando de Docker ejecuta n8n en tu propia máquina, y es una excelente manera de probar flujos de trabajo antes de comprometerte con un servidor. El problema son los webhooks: los flujos activados por servicios externos necesitan que tu instancia sea accesible desde internet, y una laptop detrás del router de tu casa no lo es de forma predeterminada. El reenvío de puertos, las VPN y los túneles pueden resolverlo, cada uno con su propia configuración y sus propios sacrificios de seguridad.

n8n ofrece un servicio de túnel para reenviar webhooks a una instancia local, pero su documentación de Docker es tajante: el túnel “está pensado únicamente para desarrollo local y pruebas” y no debe usarse en producción. Para algo que funciona las 24 horas, usa un VPS.

¿Puedo migrar de Zapier a n8n?

No esperes una importación con un clic. Planea reconstruir tus flujos de trabajo en el editor visual de n8n, en lugar de importarlos desde Zapier.

La buena noticia: n8n tiene más de 400 integraciones, pero revisa cada aplicación, disparador y acción que usan tus flujos actuales antes de planear la migración. Los flujos simples se rearman rápido; las secuencias complejas de varios pasos tardan más.

¿Cómo actualizo una instancia autoalojada de n8n?

Edita la etiqueta de versión en tu docker-compose.yml a la versión que quieras, y luego ejecuta docker compose pull seguido de docker compose up -d. Con una etiqueta fijada como docker.n8n.io/n8nio/n8n:2.36.7, descargar la imagen no cambia nada por sí solo: cada actualización la eliges tú al cambiar la etiqueta, y para eso mismo sirve fijarla. (Si usas la etiqueta latest, basta con descargar y reiniciar, pero cada reinicio se convierte en una actualización sorpresa.)

Respalda tu base de datos PostgreSQL antes de una actualización de versión mayor. El script de respaldo de la guía de arriba se encarga de eso, o ejecuta pg_dump directamente en el contenedor de PostgreSQL.

Las actualizaciones descuidadas rompen cosas, y n8n publica una nueva versión menor casi cada semana. Las propias instrucciones de actualización de n8n piden revisar el registro de cambios incompatibles antes de actualizar: léelo antes de descargar. El reinicio en sí es rápido; leer el registro de cambios es la parte que merece tu tiempo.

¿Es n8n autoalojado lo bastante seguro para datos empresariales?

El autoalojamiento te da control sobre dónde guarda n8n las definiciones de flujos, las credenciales y los datos de ejecución. Eso sí: los servicios conectados siguen recibiendo los datos que tus flujos les envían, y asegurar el servidor sigue siendo tu responsabilidad.

Sigue la lista de seis puntos de la sección de seguridad de arriba: HTTPS, firewall, aislamiento en Docker, autenticación fuerte con 2FA, actualizaciones regulares y respaldos ya probados. El equipo de n8n mantiene una guía de seguridad con consideraciones adicionales para producción, desde auditorías de seguridad hasta autenticación de dos factores.