Implementar n8n en tu Empresa: Guía Paso a Paso

Guía completa para implementar n8n en producción en tu empresa. Arquitectura, Docker, seguridad, backups, integraciones y mejores prácticas.

TodoAutomatizado 20 de agosto de 2026 15 min de lectura

Tener n8n funcionando en local con SQLite y cuatro workflows de prueba es una cosa. Implementar n8n en una empresa para que soporte procesos reales con datos sensibles, múltiples usuarios y alta disponibilidad es otra completamente distinta.

Este artículo cubre exactamente ese salto: llevar n8n de juguete a herramienta de producción. No la instalación básica con Docker que ya cubrimos, sino arquitectura real de empresa: reverse proxy con SSL, autenticación robusta, backups automatizados, monitorización y escalado. Todo con configuraciones que puedes copiar directamente.

¿Todavía no tienes claro qué es n8n? Empieza por el tutorial en español de primeros pasos o la comparativa con Zapier.

Por qué n8n self-hosted y no Zapier o Make

Antes de desplegar nada, las razones por las que n8n self-hosted merece el esfuerzo frente al SaaS:

Tus datos no salen de tu infraestructura. Los workflows empresariales procesan facturas, datos de clientes, credenciales de APIs. Con n8n self-hosted, nada pasa por servidores de terceros. RGPD resuelto, auditorías simplificadas.

El coste no escala con el uso. Zapier y Make cobran por ejecución. Con miles de ejecuciones diarias, la factura se dispara. Con n8n self-hosted pagas el servidor — entre 10 y 30 €/mes por un VPS que soporta volúmenes que en SaaS costarían cientos de euros.

Conectas con todo, incluido lo que está dentro de tu red. Bases de datos internas, ERPs, PLCs vía OPC-UA, APIs privadas. Ningún SaaS puede hacer eso sin exponer tus servicios a internet.

Cero límites artificiales. Sin tope de workflows, ejecuciones ni nodos por flujo. La única limitación es tu hardware.

Arquitectura de producción

Un despliegue empresarial de n8n no es un solo contenedor con SQLite. Es un stack de servicios coordinados:

Componentes del stack

n8n — Motor de automatización (contenedor principal)
PostgreSQL — Base de datos para workflows, credenciales y ejecuciones (obligatorio en producción; SQLite no es aceptable para múltiples usuarios ni para volúmenes altos)
Nginx — Reverse proxy con terminación SSL
Redis — Cola de trabajos para modo queue (necesario si se escala con workers)
Certbot / Let’s Encrypt — Certificados SSL automáticos

Requisitos de servidor

Para una empresa mediana con 20-50 workflows activos y varios usuarios:

Recurso	Mínimo	Recomendado
CPU	2 vCPU	4 vCPU
RAM	4 GB	8 GB
Disco	40 GB SSD	80 GB SSD
SO	Ubuntu 22.04/24.04 LTS	Ubuntu 24.04 LTS
Docker	24+	Última estable

Si usas nodos de IA (OpenAI, modelos locales, agentes IA con n8n), sube a 8-16 GB de RAM. Las respuestas de modelos grandes consumen más memoria de lo que esperas.

Diagrama lógico

Internet
    │
    ▼
[ Nginx + SSL ]  ← Puerto 443
    │
    ▼
[ n8n main ]  ← Puerto 5678 (interno)
    │
    ├──▶ [ PostgreSQL ]  ← Puerto 5432 (interno)
    ├──▶ [ Redis ]       ← Puerto 6379 (interno, modo queue)
    └──▶ [ APIs externas / servicios internos ]

Los puertos de PostgreSQL y Redis nunca se exponen al exterior. Solo Nginx escucha en 443. Si alguien te dice que da igual, no le hagas caso.

Docker Compose para producción empresarial

Este docker-compose.yml está listo para producción. No es el ejemplo mínimo de la documentación oficial — incluye PostgreSQL, Redis para modo queue, volúmenes persistentes y seguridad real.

version: "3.8"

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      # Base de datos
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}
      # Modo queue (escalable)
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      # Seguridad
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=${N8N_USER}
      - N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD}
      - N8N_ENCRYPTION_KEY=${ENCRYPTION_KEY}
      # URL pública
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://${DOMAIN}/
      # Configuración de ejecuciones
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=168
      - GENERIC_TIMEZONE=Europe/Madrid
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started
    networks:
      - n8n-net

  postgres:
    image: postgres:16-alpine
    container_name: n8n-postgres
    restart: always
    environment:
      - POSTGRES_DB=n8n
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - n8n-net

  redis:
    image: redis:7-alpine
    container_name: n8n-redis
    restart: always
    command: redis-server --maxmemory 128mb --maxmemory-policy allkeys-lru
    volumes:
      - redis_data:/data
    networks:
      - n8n-net

volumes:
  n8n_data:
  postgres_data:
  redis_data:

networks:
  n8n-net:
    driver: bridge

Archivo .env

Crear un archivo .env en el mismo directorio que el docker-compose.yml:

# Credenciales de base de datos
DB_PASSWORD=una_contraseña_segura_de_32_caracteres

# Credenciales de acceso a n8n
N8N_USER=admin
N8N_PASSWORD=otra_contraseña_segura

# Clave de encriptación para credenciales almacenadas
# Generar con: openssl rand -hex 32
ENCRYPTION_KEY=tu_clave_de_encriptacion_hex

# Dominio público
DOMAIN=n8n.tuempresa.com

Importante: N8N_ENCRYPTION_KEY cifra todas las credenciales almacenadas en n8n. Si pierdes esta clave, pierdes todas las credenciales — tokens de API, contraseñas de servicios, todo. Guárdala en un gestor de secretos o en un lugar seguro fuera del servidor. Hemos visto equipos perder acceso a 30 integraciones por no hacer esto.

Reverse proxy con Nginx y SSL

n8n no debe exponerse directamente a internet. Punto. Nginx actúa como intermediario, gestiona SSL y añade cabeceras de seguridad.

Instalar Nginx y Certbot

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx

Configuración de Nginx

Crear el archivo /etc/nginx/sites-available/n8n.tuempresa.com:

upstream n8n_backend {
    server 127.0.0.1:5678;
}

server {
    listen 80;
    server_name n8n.tuempresa.com;

    # Redirigir todo HTTP a HTTPS
    location / {
        return 301 https://$host$request_uri;
    }

    # Certbot challenge
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }
}

server {
    listen 443 ssl http2;
    server_name n8n.tuempresa.com;

    # Certificados SSL (Certbot los genera)
    ssl_certificate /etc/letsencrypt/live/n8n.tuempresa.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.tuempresa.com/privkey.pem;

    # Configuración SSL robusta
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    # Cabeceras de seguridad
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Proxy a n8n
    location / {
        proxy_pass http://n8n_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket (necesario para el editor de n8n)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeouts generosos para workflows largos
        proxy_read_timeout 300s;
        proxy_connect_timeout 60s;
        proxy_send_timeout 300s;

        # Tamaño máximo de payload (subida de archivos)
        client_max_body_size 50m;
    }
}

Activar el sitio y obtener certificado SSL

# Activar configuración
sudo ln -s /etc/nginx/sites-available/n8n.tuempresa.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

# Obtener certificado SSL (el dominio debe apuntar al servidor)
sudo certbot --nginx -d n8n.tuempresa.com --non-interactive --agree-tos -m [email protected]

# Verificar renovación automática
sudo certbot renew --dry-run

Certbot configura automáticamente la renovación. No tienes que hacer nada más — se renueva solo cada 60-90 días.

Autenticación y control de acceso

La autenticación básica del .env es el mínimo absoluto. Para una empresa con múltiples usuarios, necesitas algo más.

Usuarios y roles (n8n Enterprise / Community)

Desde la versión 1.x, n8n Community soporta múltiples usuarios con roles básicos (owner + member). Esto se activa configurando el correo SMTP para las invitaciones:

# Añadir al bloque environment de n8n en docker-compose.yml
- N8N_EMAIL_MODE=smtp
- N8N_SMTP_HOST=smtp.tuempresa.com
- N8N_SMTP_PORT=587
- [email protected]
- N8N_SMTP_PASS=${SMTP_PASSWORD}
- [email protected]
- N8N_SMTP_SSL=false

Con esto configurado, invitas a otros usuarios desde la interfaz. Cada uno tiene sus propias credenciales y acceso limitado según su rol.

Restricción por IP en Nginx

Si n8n solo debe ser accesible desde la red corporativa o desde direcciones IP conocidas:

# Añadir dentro del bloque location / de la configuración de Nginx
allow 203.0.113.0/24;    # Rango IP de la oficina
allow 10.0.0.0/8;        # Red interna
allow 100.64.0.0/10;     # Tailscale / VPN
deny all;

VPN como capa adicional (nuestra recomendación)

La opción más segura: no expongas n8n a internet en absoluto. Tailscale o WireGuard te permiten acceder al servidor como si fuera un recurso de red local, sin abrir puertos públicos. Es lo que recomendamos para la mayoría de empresas. El artículo sobre instalación self-hosted detalla cómo configurarlo.

Backups automatizados: lo que nadie configura hasta que es tarde

Un despliegue sin backups no es un despliegue de producción — es una bomba de relojería. Y sin embargo, la mayoría de instalaciones de n8n que hemos visto en empresas no tienen backup alguno. Esto es lo que debes respaldar:

Qué respaldar

Base de datos PostgreSQL — Contiene workflows, credenciales cifradas, historial de ejecuciones y configuración de usuarios
Volumen de n8n (n8n_data) — Archivos de nodos comunitarios y configuraciones locales
Archivo .env — Variables de entorno y secretos
Configuración de Nginx — Virtual hosts y certificados

Script de backup automatizado

Crear el archivo /opt/n8n-backup/backup.sh:

#!/bin/bash
set -euo pipefail

# Configuración
BACKUP_DIR="/opt/n8n-backup/backups"
RETENTION_DAYS=30
DATE=$(date +%Y-%m-%d_%H%M)
BACKUP_PATH="${BACKUP_DIR}/${DATE}"

mkdir -p "${BACKUP_PATH}"

# 1. Backup de PostgreSQL
echo "[$(date)] Iniciando backup de PostgreSQL..."
docker exec n8n-postgres pg_dump -U n8n -Fc n8n > "${BACKUP_PATH}/n8n_db.dump"

# 2. Backup del volumen de n8n
echo "[$(date)] Copiando volumen de n8n..."
docker run --rm \
  -v n8n_data:/source:ro \
  -v "${BACKUP_PATH}:/backup" \
  alpine tar czf /backup/n8n_volume.tar.gz -C /source .

# 3. Backup de configuración
echo "[$(date)] Copiando configuración..."
cp /opt/n8n/docker-compose.yml "${BACKUP_PATH}/"
cp /opt/n8n/.env "${BACKUP_PATH}/"

# 4. Comprimir todo
echo "[$(date)] Comprimiendo backup completo..."
tar czf "${BACKUP_DIR}/n8n-backup-${DATE}.tar.gz" -C "${BACKUP_DIR}" "${DATE}"
rm -rf "${BACKUP_PATH}"

# 5. Limpiar backups antiguos
find "${BACKUP_DIR}" -name "n8n-backup-*.tar.gz" -mtime +${RETENTION_DAYS} -delete

echo "[$(date)] Backup completado: n8n-backup-${DATE}.tar.gz"

Programar con cron

# Hacer el script ejecutable
chmod +x /opt/n8n-backup/backup.sh

# Añadir a crontab (backup diario a las 3:00 AM)
echo "0 3 * * * /opt/n8n-backup/backup.sh >> /var/log/n8n-backup.log 2>&1" | sudo tee -a /etc/crontab

Backup externo

Los backups en el mismo servidor que n8n no sirven de nada si el disco muere o el servidor se cae. Copia siempre a un segundo destino:

# Ejemplo con rclone a un bucket S3 / Backblaze B2
rclone copy /opt/n8n-backup/backups/ remote:n8n-backups/ --max-age 7d

# O simplemente rsync a otro servidor
rsync -avz /opt/n8n-backup/backups/ backup-server:/backups/n8n/

Restaurar un backup

# Parar n8n
cd /opt/n8n && docker compose down

# Restaurar PostgreSQL
docker compose up -d postgres
cat n8n_db.dump | docker exec -i n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists

# Restaurar volumen de n8n
docker run --rm \
  -v n8n_data:/target \
  -v $(pwd):/backup \
  alpine sh -c "rm -rf /target/* && tar xzf /backup/n8n_volume.tar.gz -C /target"

# Levantar todo
docker compose up -d

Monitorización: enterate antes que tus usuarios

Desplegar n8n y olvidarse no es una opción. Cuando un workflow crítico falla en silencio, te enteras por el cliente enfadado. Mejor monitorizar:

Health check de n8n

n8n expone un endpoint de salud en /healthz. Un script simple con cron resuelve la monitorización básica:

#!/bin/bash
# /opt/n8n-monitoring/healthcheck.sh

RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" https://n8n.tuempresa.com/healthz)

if [ "$RESPONSE" != "200" ]; then
    echo "[$(date)] n8n no responde (HTTP $RESPONSE). Reiniciando..." >> /var/log/n8n-monitor.log
    cd /opt/n8n && docker compose restart n8n
    # Notificar (webhook, email, Telegram)
    curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
      -d "chat_id=${CHAT_ID}&text=⚠️ n8n se ha reiniciado automáticamente (HTTP $RESPONSE)"
fi

Monitorizar recursos del servidor

# Uso de disco (crítico si no se podan ejecuciones)
df -h /var/lib/docker

# Memoria de los contenedores
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

# Logs de errores de n8n
docker logs n8n --since 1h 2>&1 | grep -i error

Poda automática de ejecuciones

El historial de ejecuciones crece rápidamente. Las variables de entorno del docker-compose.yml ya incluyen la poda automática:

EXECUTIONS_DATA_PRUNE=true       # Activar poda
EXECUTIONS_DATA_MAX_AGE=168      # Borrar ejecuciones de más de 7 días (en horas)

Para empresas que necesitan mantener un historial más largo, se puede subir EXECUTIONS_DATA_MAX_AGE a 720 (30 días), pero hay que dimensionar el disco del servidor en consecuencia.

Escalar n8n cuando te queda pequeño

Cuando el volumen de ejecuciones crece, un solo proceso de n8n se convierte en cuello de botella. El modo queue separa la recepción de webhooks del procesamiento de workflows.

Cómo funciona

El proceso main recibe webhooks, evalúa triggers y encola trabajos en Redis
Los workers toman trabajos de la cola y ejecutan los workflows
Se pueden añadir tantos workers como el hardware permita

Añadir workers al Docker Compose

  n8n-worker:
    image: n8nio/n8n:latest
    container_name: n8n-worker-1
    restart: always
    command: worker
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      - N8N_ENCRYPTION_KEY=${ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=Europe/Madrid
    depends_on:
      - postgres
      - redis
    networks:
      - n8n-net

Para añadir más capacidad, se replica este bloque cambiando container_name a n8n-worker-2, n8n-worker-3, etc. O se usa docker compose up --scale n8n-worker=3.

Cuándo escalar

Si las ejecuciones tardan más de lo esperado por esperar cola
Si el servidor principal supera el 80% de CPU de forma sostenida
Si hay workflows críticos que no pueden retrasarse (procesamiento de pedidos, alertas)

Para la mayoría de empresas medianas, un main + un worker sobra. Solo cuando superas los cientos de ejecuciones por hora vale la pena añadir más workers. No sobredimensiones por anticipación.

Qué automatizar primero

Con n8n desplegado, estos son los casos de uso que más valor aportan desde el primer día:

Automatización de procesos de negocio

CRM → ERP: Sincronizar contactos y oportunidades de HubSpot/Pipedrive con el ERP
Facturación: Generar y enviar facturas automáticamente desde datos del ERP o de hojas de cálculo
Onboarding de empleados: Crear cuentas en todos los servicios cuando RRHH registra un alta
Reporting: Generar informes periódicos y enviarlos por email o Slack

Integración con sistemas industriales

Si tienes planta de producción, n8n conecta directamente con sistemas OT:

Lectura de datos de PLCs vía API REST o nodos HTTP
Envío de alertas de producción a Telegram o Teams
Sincronización de datos de producción con dashboards de Grafana

IA y automatización inteligente

La combinación de n8n con modelos de IA es donde las cosas se ponen realmente interesantes:

Clasificación automática de emails y tickets de soporte
Generación de resúmenes de documentos largos
Análisis de sentiment en feedback de clientes
Chatbots internos con contexto empresarial

Las guías sobre n8n con OpenAI GPT y agentes IA con n8n cubren estas integraciones en detalle.

Checklist de despliegue en producción

Antes de dar por bueno el despliegue, revisar cada punto:

Infraestructura:

Servidor dimensionado según carga esperada
Docker y Docker Compose instalados y actualizados
Firewall configurado (solo puertos 80, 443 y SSH abiertos)
DNS del dominio apuntando al servidor

Seguridad:

HTTPS con certificado válido y renovación automática
N8N_ENCRYPTION_KEY generada y almacenada fuera del servidor
Autenticación activa (básica como mínimo, SSO recomendado)
PostgreSQL y Redis sin puertos expuestos al exterior
Cabeceras de seguridad en Nginx configuradas
Acceso restringido por IP o VPN si es posible

Resiliencia:

Backup diario automatizado con script y cron
Backup externo (segundo servidor, S3 o similar)
Restauración de backup probada al menos una vez
Health check con reinicio automático y notificación
Poda de ejecuciones antiguas configurada
restart: always en todos los servicios de Docker Compose

Operación:

Monitorización de disco, CPU y memoria
Proceso documentado para actualizar n8n
Credenciales de acceso documentadas en gestor de secretos
Equipo formado en uso básico de n8n

Actualizar n8n en producción sin romper nada

Las actualizaciones son el momento de mayor riesgo. Este proceso minimiza el impacto:

cd /opt/n8n

# 1. Backup antes de cualquier actualización
/opt/n8n-backup/backup.sh

# 2. Revisar changelog de la nueva versión
# https://docs.n8n.io/reference/release-notes/

# 3. Descargar nueva imagen
docker compose pull

# 4. Reiniciar con la nueva versión
docker compose up -d

# 5. Verificar que todo funciona
curl -s https://n8n.tuempresa.com/healthz
docker logs n8n --since 5m 2>&1 | grep -i error

Consejo: No usar la etiqueta latest en producción si se quiere control estricto. Fijar la versión en el docker-compose.yml (n8nio/n8n:1.52.0) y actualizarla manualmente tras revisar los cambios.

Errores frecuentes al implementar n8n en empresa

Estos son los problemas que aparecen una y otra vez en despliegues empresariales:

Usar SQLite en producción. Lo vemos constantemente. SQLite no soporta escrituras concurrentes — dos usuarios editando workflows al mismo tiempo y la base de datos se bloquea. PostgreSQL es obligatorio, sin excepciones.

No configurar N8N_ENCRYPTION_KEY. Si n8n genera una clave aleatoria y luego recreas el contenedor sin volumen persistente, pierdes todas las credenciales. Defínela explícitamente y guárdala en un sitio seguro.

Exponer n8n sin reverse proxy. n8n en el puerto 5678 directamente a internet, sin SSL ni cabeceras de seguridad. Lo hemos visto. No lo hagas. Siempre detrás de Nginx o Caddy.

No podar ejecuciones. El historial crece a varios gigabytes en semanas. Sin poda automática, el disco se llena y n8n deja de funcionar. Es de los fallos más tontos y más frecuentes.

Olvidar los webhooks en las actualizaciones. Si tus workflows usan webhooks, verifica que las URLs siguen respondiendo después de cada actualización. Un cambio en WEBHOOK_URL puede romper todas tus integraciones externas de golpe.

El siguiente paso

El stack de este artículo — n8n con PostgreSQL, Redis, Nginx con SSL y backups automatizados — cubre al 90% de empresas. El 10% restante escala horizontalmente con workers sin cambiar la arquitectura base.

Una vez desplegado, toca construir los workflows que aportan valor real. Las guías sobre automatización con OpenAI GPT y agentes IA son el punto de partida más productivo.

Sigue leyendo

Automatización 2 de septiembre de 2026

n8n Agentes de Larga Duración: Arquitectura y Escala

Diseña agentes n8n que corran 24/7 con estado persistente, reintentos inteligentes y observabilidad. Patrones escalables para producción industrial.

Leer artículo

Automatización 25 de agosto de 2026

n8n + Twilio: Automatizar SMS y Llamadas

Conecta n8n con Twilio para automatizar SMS, llamadas y verificaciones. Tutorial con workflows reales y ejemplos de código.

Leer artículo