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 añade otra línea a la factura, y cada paso de acción completado 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 el precio de un servidor pequeño.

Sin cuota de ejecuciones. Sin precios por tarea. Sin facturas inesperadas cuando tus automatizaciones despeguen.

Y sí, te guiamos por todo el proceso, comando a comando: desde un servidor Ubuntu recién instalado hasta una instancia en funcionamiento con HTTPS, copias de seguridad y una restauración probada.

¿Qué es n8n y por qué se autoaloja?

n8n es una plataforma de automatización de flujos de trabajo que te permite conectar aplicaciones, mover datos entre servicios y crear automatizaciones complejas con un editor visual. Piensa en ella como el motor de «cuando pase X, haz Y y Z», con la diferencia de que arrastras nodos y dibujas conexiones en lugar de escribir código.

El proyecto ha superado las 200.000 estrellas en GitHub y su imagen oficial de Docker acumula más de 100 millones de descargas. Hay muchos servidores ahí fuera ejecutando n8n.

La plataforma se distribuye bajo una Sustainable Use License, y conviene entenderla antes de lanzarte. No es código abierto en el sentido 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 cerrada. Puedes usarla libremente para los fines internos de tu negocio. Lo que no puedes es vender un producto, servicio o módulo cuyo valor derive total o sustancialmente de las funciones de n8n.

Mucha gente decide autoalojar n8n porque, en cuanto superas el uso básico, las cuentas cambian por completo. n8n Cloud empieza en 20 €/mes (con facturación anual) por 2500 ejecuciones en el plan Starter. Si mueves un volumen real, esos límites se te quedan cortos enseguida.

¿Y en tu propio VPS? No hay cuota de ejecuciones, controlas los datos que guarda tu instancia de n8n y no pagas licencias ni ejecuciones a n8n. Eso sí, el servidor, el dominio, el almacenamiento de copias de seguridad y la administración siguen teniendo un coste. Las ejecuciones en sí no cuestan nada extra. Un volumen mayor consume más memoria y almacenamiento, pero eso es una cuestión de dimensionamiento (lo vemos más abajo), no de facturación.

¿Qué puedes automatizar con n8n?

Las más de 400 integraciones de n8n cubren muchísimos casos, y los nodos creados por la comunidad amplían aún más la lista. Además, n8n es solo una de las muchas alternativas autoalojadas a las herramientas SaaS: la misma lógica se aplica a todo, desde el CRM hasta la gestión de proyectos.

Algunas configuraciones habituales:

• CRM y asignación de leads. Sincroniza los contactos entre tu CRM, tu plataforma de correo electrónico y Slack cuando entran leads nuevos.
• Flujos de trabajo activados por webhooks. Responde en tiempo real a eventos de pasarelas de pago, envíos de formularios o commits de GitHub.
• Automatización de canalizaciones de datos. Extrae datos de API, transfórmalos y envíalos a bases de datos u hojas de cálculo de forma programada.
• Cadenas de agentes de IA. Conecta LLM con tus herramientas internas para crear asistentes de IA a medida que busquen, resuman y actúen sobre tus datos.

(Con este último es cuando los recursos de tu servidor empiezan a importar. Lo vemos en la sección de especificaciones).

¿Cuánto cuesta autoalojar n8n?

La edición Community autoalojada no tiene licencias ni tarifas por ejecución de n8n en los usos permitidos. Tu coste total incluye el servidor, además de cualquier dominio, almacenamiento de copias de seguridad y tiempo de administración. El desglose de costes de 2026 de ExpressTech sitúa un VPS básico con Docker en 4–5 $ al mes, un VPS gestionado con Coolify en 5–8 $ y las plataformas administradas de n8n con un clic en 3–7 $.

Estas son las estimaciones de ExpressTech, un tercero. Si quieres una cifra de primera mano: el plan que te recomendamos más abajo, DreamHost VPS Hosting Stack 4, cuesta 8,99 $/mes durante los 3 primeros meses con facturación mensual y después se renueva automáticamente a 15,99 $/mes, según los precios de agosto de 2026. El periodo completo más los impuestos se cobra al pagar (consulta los precios actuales en la página de VPS para n8n).

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

La diferencia crece cuando tienes en cuenta cómo mide el uso cada plataforma. n8n cobra una ejecución por cada vez que se ejecuta un flujo de trabajo, regardless of complexity,, y todos los planes incluyen pasos ilimitados. Zapier, en cambio, cuenta cada paso de acción completado como una tarea.

Así, un flujo de trabajo con cuatro pasos de acción que se ejecuta 100 veces al día supone 3000 ejecuciones de n8n al mes, pero unas 12.000 tareas de Zapier.

Las cifras reales lo confirman. El análisis de ExpressTech plantea un ejemplo con cuatro flujos de trabajo que suman unas 7000 ejecuciones al mes. Esa carga supera el plan Starter de n8n Cloud y obliga a pasar al Pro (que allí figura a 60 $/mes con facturación mensual), mientras que una instalación autoalojada de 3–7 $/mes la ejecuta sin límites. Según sus cálculos, la diferencia es de 636–684 $ al año.

Los costes ocultos de autoalojar

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

Esto es lo que te cuesta:

Tu tiempo. El tiempo de mantenimiento depende de tu carga de trabajo y de tu experiencia, pero tú serás responsable de las actualizaciones, las copias de seguridad, la monitorización y las pruebas de restauración. Las instalaciones más pesadas, con automatizaciones basadas en IA, te exigirán más.

La configuración de OAuth. Para conectar servicios como Google Workspace o Microsoft 365 tienes que configurar credenciales OAuth. Reserva tiempo extra para cada proveedor y sigue la documentación de su consola. (Si alguna vez te has quedado mirando un icono de carga mientras una pantalla de consentimiento decide si se fía de tu app, ya sabes de qué hablamos).

TLS: confía, pero comprueba. El proxy Caddy de la configuración que verás más abajo obtiene y renueva automáticamente un certificado de confianza pública, mediante un emisor como Let’s Encrypt o ZeroSSL. Automático no significa infalible: después de cualquier cambio en el DNS o en el proxy, comprueba que el certificado se sigue renovando.

La curva de aprendizaje si eres nuevo con los servidores. La guía de más abajo da por hecho que sabes conectarte a un servidor por SSH, editar un archivo y ejecutar comandos. Si nunca lo has hecho, reserva tiempo para aprender, además del que dediques al despliegue.

¿Qué especificaciones de servidor necesita n8n?

n8n en sí es ligero. Lo más parecido a un dimensionamiento oficial son las cifras de ejemplo de la documentación de despliegue OEM de n8n, que la propia n8n califica de for illustrative purposes only, y que se basan en n8n Cloud: entre 320 MB y 2 GB de memoria, una base de datos en SSD de entre 512 MB y 4 GB y unos 100 MB de memoria para una instancia inactiva. Como asignación inicial prudente (no como mínimo oficial de n8n), plantéate 2 GB para pruebas y 4 GB cuando añadas PostgreSQL y flujos de trabajo en producción. Monitoriza flujos de trabajo representativos y añade memoria cuando veas una presión sostenida.

Recuerda también que a n8n suele limitarlo más la memoria que la CPU. La propia documentación de n8n lo dice claramente: la plataforma isn’t CPU intensive, y usually, memory requirements supersede CPU requirements.. Lo que dispara el consumo de 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.

Este es nuestro cálculo rápido para dimensionar el margen:

Dimensiona en función de las ejecuciones simultáneas y del volumen de datos que procesa cada flujo de trabajo, y después monitoriza el uso de memoria con una carga representativa. Los nodos Code y las cargas binarias grandes pueden aumentar las necesidades de memoria, así que deja margen y amplía el VPS cuando la monitorización muestre una presión sostenida.

¿Es la primera vez que usas un VPS? Empieza por la guía de VPS para principiantes de DreamHost para entender lo básico antes de dimensionar tu servidor.

¿Qué VPS elegir para n8n autoalojado?

n8n no publica niveles fijos de RAM según la carga de trabajo. Dimensiona en función de las ejecuciones simultáneas y del volumen de datos, deja margen para Docker y PostgreSQL, y después monitoriza flujos de trabajo representativos y amplía cuando la presión sobre la memoria sea sostenida.

Así es como lo trasladaríamos a los planes de DreamHost:

Más allá de la RAM, hay algunas especificaciones a las que conviene prestar atención: n8n señala el almacenamiento SSD como buena práctica para la base de datos. Las necesidades de memoria suelen pesar más que las de CPU, pero el cuello de botella real depende de la simultaneidad de los flujos de trabajo, el volumen de datos y los nodos que uses. El ancho de banda sin límite importa si ejecutas cargas con muchos webhooks y un flujo constante de peticiones 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 no suele ofrecer ese nivel de control.

Los planes de Hosting VPS de DreamHost cumplen lo esencial (almacenamiento SSD NVMe, ancho de banda sin límite, acceso root completo y compatibilidad con Docker), y n8n está en la biblioteca de aplicaciones de un clic, preinstalado con PostgreSQL y SSL automático, por si prefieres saltarte la configuración manual que verás a continuación.

Para un servidor de n8n con flujos de trabajo en producción, nos quedamos con Stack 8, el plan que nuestras páginas indican para apps en producción. Stack 4 cubre la asignación inicial de 4 GB para un primer servidor ligero. En agosto de 2026 cuesta 8,99 $/mes durante los 3 primeros meses con facturación mensual y se renueva automáticamente a 15,99 $/mes; el periodo completo más los impuestos se cobra al pagar. La página de VPS para n8n siempre muestra las tarifas actuales. Ese precio de renovación es la cifra honesta que debes comparar con los 20 €/mes del plan Starter de n8n Cloud.

Ah, y algo que conviene que guardes en la recámara para más adelante: cuando tu uso crezca, n8n admite el modo de cola, una arquitectura de escalado que separa la instancia principal (interfaz, disparadores, webhooks) de la ejecución de los flujos de trabajo. Usa Redis como intermediario de mensajes e instancias worker para ejecutar las tareas. La documentación de n8n lo describe como el modo que provides the best scalability..

¿Cómo se configura n8n en un VPS?

Desplegar una instancia de n8n autoalojada lleva 11 pasos: DNS, refuerzo de la seguridad de SSH, un cortafuegos, Docker, secretos, un archivo de Compose para el conjunto de tres contenedores (n8n, PostgreSQL y Caddy), el Caddyfile, el arranque y la verificación, las actualizaciones, las copias de seguridad y una prueba de restauración. Caddy es nuestro proxy inverso: el servidor que se sitúa entre internet y tu aplicación y se encarga del TLS y del enrutamiento. Incluimos los comandos del despliegue principal y de una prueba manual de copia de seguridad y restauración.

Los comandos están pensados para Ubuntu 22.04 o posterior, pero sustituye el dominio de ejemplo, los valores secretos, el nombre del volumen y los nombres de archivo de copia de seguridad con fecha donde se indique. La documentación de Docker Compose de n8n cubre lo mismo 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 con Ubuntu 22.04 o posterior y 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 TLS y para acceder al editor de n8n)
• Soltura básica con la terminal: deberías saber conectarte a un servidor por SSH, editar un archivo y ejecutar comandos

Un requisito más que no aparece en ninguna lista oficial: haz una copia de seguridad de tu N8N_ENCRYPTION_KEY en cuanto la generes. Por eso, en el paso 5 creas la clave con openssl rand -hex 32 antes del primer arranque, en lugar de dejar que n8n genere una sin avisar. Esta clave cifra todas tus credenciales almacenadas, incluidas todas las claves de API, tokens de OAuth y contraseñas de bases de datos que hayas conectado. La propia documentación de Docker de n8n advierte de que, si no encuentra la clave al arrancar, n8n crea una nueva y las credenciales existentes ya no se pueden descifrar. Es decir, tendrás que reconstruir cada integración desde cero (y arrepentirte de tus decisiones vitales). Guárdala en un lugar seguro, separada de las copias de seguridad de tu base de datos.

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

adduser deploy
usermod -aG sudo deploy

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

Paso 1: apunta tu dominio al servidor

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

Paso 2: refuerza el acceso SSH

En tu equipo local, genera un par de claves (la documentación de OpenSSH de Ubuntu 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. Después, en el servidor, desactiva el inicio de sesión con contraseña y como root, y comprueba qué aplicará realmente sshd:

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 intencionado. Según el manual de sshd_config, OpenSSH usa el primer valor que lee para cada palabra clave, y las imágenes de servidores en la nube suelen incluir archivos de configuración adicionales que se leen antes en el mismo directorio (cloud-init, por ejemplo, escribe sus ajustes de SSH en 50-cloud-init.conf). Si llamas a tu archivo 99-hardening.conf, uno de esos fragmentos puede imponerse sin avisar. sshd -t comprueba si hay errores en la configuración; sshd -T muestra los ajustes efectivos tras combinar todos los archivos. Confirma que el último comando muestra passwordauthentication no y permitrootlogin no antes de seguir. Después, reinicia sshd:

sudo systemctl restart ssh.service

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

Paso 3: activa el cortafuegos

Ubuntu incluye UFW (Uncomplicated Firewall) desactivado por defecto. Permite SSH antes de activarlo, para que el cortafuegos 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, nada más. Una advertencia específica de Docker, sacada de la propia documentación de instalación de Docker: los puertos que Docker publica en el host se saltan por completo las reglas de UFW. Por eso, el archivo de Compose del paso 6 solo publica puertos en el host para Caddy: el 80 y el 443 son los únicos puertos de contenedor que publica Compose (el 22 de SSH también está abierto), y n8n y PostgreSQL no tienen ningún puerto publicado 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 get.docker.com, que la documentación de Docker recomienda solo para pruebas y desarrollo. Primero, los requisitos previos 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

A continuación, registra el propio repositorio. Esto escribe el archivo del repositorio de la guía de instalación de Docker para Ubuntu y rellena automáticamente tu versión de Ubuntu:

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

Después, 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 muestra 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 tu clave de cifrado. No dejes que n8n se invente una sin avisar 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, guárdalo junto con una contraseña de base de datos segura en un archivo .env protegido, al lado de tu archivo de Compose (Docker Compose lo lee automáticamente). Sustituye los dos 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

chmod 600 es importante: este archivo contiene secretos, así que solo su propietario (root) debería poder leerlo. En el archivo de Compose, N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true aplica la misma idea dentro del contenedor: según la referencia de variables de seguridad de n8n, hace que n8n intente establecer 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, sustituyendo n8n.example.com por tu propio dominio en las dos líneas de URL y configurando tu zona horaria:

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:

Hay cinco detalles que se ganan su sitio:

• La imagen está fijada a una versión concreta (2.36.7 es la versión estable actual en el momento de escribir esto, según la documentación de instalación de n8n), así que las actualizaciones solo se producen cuando tú lo decides.
• n8n no publica ningún puerto en el host. Los contenedores de la red de Compose, incluido Caddy, pueden acceder a él, pero no a través de un puerto publicado en el host. Así, al editor solo se puede llegar mediante el proxy inverso, nunca directamente desde internet.
• La comprobación de estado (healthcheck) hace que n8n espere a PostgreSQL. Un simple depends_on solo espera a que se inicie el contenedor, no a que la base de datos acepte conexiones. El patrón condition: service_healthy viene directamente del archivo de Compose de ejemplo con Postgres de n8n, que también despliega PostgreSQL 18.
• La pareja N8N_WEBHOOK_URL / N8N_PROXY_HOPS es importante detrás de un proxy. n8n normalmente construye las URL de webhook a partir de su protocolo, host y puerto, y la documentación de n8n indica que eso no funciona detrás de un proxy inverso. Por eso, defines la URL del webhook manualmente para que n8n pueda register the correct webhook URLs with external services, estableces N8N_PROXY_HOPS en 1 y te aseguras de que el proxy transmita las cabeceras X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. (La misma página indica que N8N_WEBHOOK_URL sustituye a la antigua WEBHOOK_URL, obsoleta desde n8n 2.35.0).
• TZ y GENERIC_TIMEZONE cumplen funciones distintas. Según la documentación de Docker de n8n, GENERIC_TIMEZONE controla los nodos de programación como Schedule, mientras que TZ establece la zona horaria del sistema del contenedor (la que muestran comandos como date). Asigna el mismo valor a ambas.

(Empieza con PostgreSQL desde el primer día. n8n usa SQLite por defecto, que sirve para pruebas, pero las plantillas de hosting de n8n recomiendan PostgreSQL para producción, y migrar más adelante es doloroso, del tipo ojalá lo hubiera hecho bien desde el principio).

Paso 7: escribe el Caddyfile

Crea /opt/n8n-compose/Caddyfile con tu dominio (de nuevo, sustituye 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, Caddy 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, siempre que tu registro DNS A apunte al servidor y los puertos 80 y 443 estén abiertos (pasos 1 y 3). Caddy también es 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 hasta que ps muestre el contenedor de postgres en estado healthy y n8n en ejecución. Después, comprueba la puerta de entrada desde cualquier equipo:

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

Un código 2xx (o una redirección 3xx) significa que Caddy ha terminado TLS y n8n ha respondido. Si, en cambio, curl sale con un error, toca revisar el DNS, el certificado o los contenedores (sudo docker compose logs caddy y sudo docker compose logs n8n son los primeros sitios donde mirar). Abre https://n8n.example.com en un navegador y crea tu cuenta de propietario.

Paso 9: actualiza n8n con cabeza

n8n publica una nueva versión menor casi todas las semanas, y sus instrucciones de actualización te piden que consultes el registro de cambios incompatibles antes de actualizar. Cuando estés listo, edita la etiqueta de versión en docker-compose.yml y después ejecuta

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

Con una etiqueta fijada, hacer pull por sí solo no cambia nada: tú eliges cada actualización cambiando la etiqueta, que es precisamente el objetivo de fijarla. Haz una copia de seguridad (paso 10) antes de las actualizaciones de versión principal.

Paso 10: programa las copias de seguridad

Para que una restauración sea útil hacen falta tres cosas: la base de datos PostgreSQL, el volumen n8n_data y el archivo .env que proporciona N8N_ENCRYPTION_KEY. La documentación de Docker de n8n deja claro que, aunque uses PostgreSQL, la carpeta /home/node/.n8n (nuestro volumen n8n_data) sigue guardando datos esenciales, incluido el material de la clave de cifrado. Haz copia de seguridad de los tres y conserva docker-compose.yml y Caddyfile para poder reconstruir el stack. 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 cuyo propietario sea 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 del volumen que crea Compose para un directorio de proyecto llamado n8n-compose. Confirma el tuyo con sudo docker volume ls y ajústalo si es diferente. Las dos líneas find conservan 30 días de copias de seguridad; establece otra retención según tus necesidades de almacenamiento y recuperación.

Prográmalo desde el crontab de root. El cron de root solo debería 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 añade una línea para que se ejecute cada día a las 3 de la madrugada:

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

El script hace copias de seguridad programadas de la base de datos PostgreSQL y del volumen n8n_data. Copia fuera del servidor el archivo .env (que contiene tu clave de cifrado) y los archivos de Compose y Caddy, ahora y cada vez que cambien. En el servidor, crea un archivo comprimido temporal 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 equipo local, descarga el archivo comprimido de configuración junto con las copias de seguridad y elimina 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'

Una copia de seguridad que solo existe en el servidor que protege desaparece con el servidor.

Paso 11: prueba una restauración en un VPS de pruebas

Este es un procedimiento de copia de seguridad y restauración para que compruebes que tus copias de seguridad sirven. Prueba esta restauración en un VPS de pruebas nuevo, nunca en tu servidor de producción. Crea un servidor desechable, repite allí el paso 4 (Docker) y copia en las mismas rutas los archivos del proyecto (docker-compose.yml, Caddyfile, .env) y tus copias de seguridad con fecha más recientes.

Primero, cambia el nombre de host: pon un nombre de host de prueba (por ejemplo, n8n-restore-test.example.com, con un registro A que apunte al VPS de pruebas) 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 CLI de servidor integrada de n8n para despublicar todos los flujos de trabajo restaurados antes de que arranque la instancia. Así, las programaciones y los disparadores restaurados no se activan contra tus sistemas de producción desde el servidor de pruebas. Termina con la misma comprobación de curl del paso 8, contra el nombre de host de prueba.

Sé sincero contigo mismo sobre lo que significa una comprobación correcta: confirma que la base de datos y el volumen se han restaurado y que el stack arranca sin problemas. No pone a prueba tus flujos de trabajo desde el editor, así que inicia sesión en la instancia de prueba y revisa los que no te puedes permitir perder.

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

Una instancia de n8n autoalojada es tan segura como el servidor en el que se ejecuta, y eres tú quien controla ese servidor.

La seguridad se reduce a seis cosas. Ninguna es complicada por separado, pero saltarte cualquiera de ellas deja un hueco real. La configuración anterior ya aplica las tres primeras.

1. HTTPS a través de un proxy inverso. No accedas nunca al editor de n8n por HTTP sin cifrar. 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. Cortafuegos bien cerrado. UFW solo permite SSH (22), HTTP (80) y HTTPS (443). Nunca expongas directamente a internet el puerto predeterminado de n8n, el 5678. El archivo de Compose anterior lo garantiza al no dar a n8n ningún puerto publicado en el host, así que solo los contenedores de la red de Compose pueden acceder a él.
3. Aislamiento de red de Docker. PostgreSQL y n8n se comunican a través de la red interna de Compose. El puerto de tu base de datos nunca se publica en el host, así que nunca es accesible desde fuera.
4. Autenticación sólida. Usa una contraseña de propietario segura y activa la autenticación en dos factores. La guía de seguridad de n8n incluye la 2FA entre las protecciones recomendadas para instancias autoalojadas.
5. Actualizaciones periódicas. Actualiza la etiqueta de versión en tu archivo de Compose y después haz pull y reinicia (paso 9). Lee antes el registro de cambios, porque las actualizaciones de n8n pueden incluir cambios incompatibles.
6. Copias de seguridad que hayas restaurado de verdad. Los pasos 10 y 11 te dan la programación y la prueba. Una copia de seguridad que nunca has probado es una esperanza, no un plan.

Una cosa más que vigilar: no es estrictamente de seguridad, pero marca una gran diferencia. Por defecto, n8n guarda en su base de datos la entrada y la salida de cada ejecución. La depuración está activada por defecto: n8n elimina las ejecuciones de más de 336 horas (14 días) o cuando superas las 10 000 ejecuciones almacenadas. Aun así, una instancia con mucha actividad puede inflar PostgreSQL mientras tanto.

Si tus flujos de trabajo generan mucha actividad, ajústalo: establece EXECUTIONS_DATA_MAX_AGE=168 para eliminar los datos de ejecución de más de siete días (el archivo de Compose anterior ya lo hace) o deja de guardar por completo las ejecuciones correctas con EXECUTIONS_DATA_SAVE_ON_SUCCESS=none.

¿Qué ventajas e inconvenientes tiene autoalojar frente a n8n Cloud?

Autoalojar n8n te da una instancia sin cuota de ejecuciones y control sobre los datos que almacena, por el coste de un VPS pequeño más tu propio trabajo de administración. n8n Cloud te libra de todo el mantenimiento del servidor, con límites de ejecuciones según el plan. La decisión se reduce a si quieres ser dueño de tu infraestructura de automatización o pagar a otro para que la gestione.

La documentación de n8n lo expresa así: n8n recommends self-hosting for expert users. Mistakes can lead to data loss, security issues, and downtime. If you aren’t experienced at managing servers, n8n recommends n8n Cloud.

Así se comparan las dos opciones:

También hay un término medio que conviene conocer. Plataformas administradas como PikaPods (unos 3,80 $/mes) y Elestio (unos 17 $/mes, según la comparativa de ExpressTech) ejecutan n8n autoalojado sin que tengas que administrar el servidor tú mismo. Estos servicios pueden reducir el trabajo de administración del servidor, aunque deberías comprobar quién se encarga de las actualizaciones de n8n, las copias de seguridad, la monitorización y la seguridad.

Pero veamos el panorama general. En cualquier plan alojado, tu capacidad de ejecución es un nivel de facturación, y es la plataforma quien fija esos niveles. Los precios, las cuotas y las funciones pueden cambiar en torno a flujos de trabajo que ya has creado.

Si lo autoalojas, la instancia y los datos que almacena residen en una infraestructura que controlas tú (los servicios conectados siguen recibiendo todo lo que tus flujos de trabajo les envíen). Control total, responsabilidad total.

La decisión final

Autoalojar tiene sentido cuando se cumplen tres condiciones:

1. Ejecutas tantas automatizaciones que los límites de ejecución en la nube se te quedarían cortos
2. Quieres que los datos de tus flujos de trabajo estén en una infraestructura que controlas
3. Tú (o alguien de tu equipo) estás dispuesto a encargarte de las actualizaciones, las copias de seguridad y la monitorización

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

Pero, en cuanto estés listo para dar el salto al autoalojamiento, las cuentas se inclinan rápidamente a tu favor. Un VPS de 4 GB es un punto de partida práctico, aunque sin pruebas de rendimiento; la capacidad en producción depende de la concurrencia, el volumen de datos y los nodos que uses, así que monitoriza la instancia y escálala a medida que crezca la demanda. Empieza con poco, amplía a medida que crezcan tus flujos de trabajo y mantén el control total de tu stack.

Eso último importa más de lo que parece. Siempre puedes pasarte a un servidor más grande. Lo que cuesta mucho más es desvincularte de una plataforma SaaS después de que cambie sus precios en torno a los flujos de trabajo que ya has creado.

Preguntas frecuentes sobre autoalojar n8n