De desarrollo local a producción estable
Ejecutar n8n en local con docker run es trivial, pero desplegarlo en producción requiere considerar persistencia de datos, seguridad, rendimiento y alta disponibilidad. En esta guía detallamos cómo montar un entorno n8n robusto usando Docker y PostgreSQL, listo para manejar cientos de workflows en paralelo.
Nota de actualización (julio de 2026): hemos revisado esta guía a fondo. Los principios del despliegue no han cambiado, pero n8n sí: la rama 2.x es la actual desde enero de 2026, la autenticación básica por variables de entorno desapareció hace tiempo en favor del gestor de usuarios integrado, y hay piezas nuevas — task runners, nodo AI Agent, soporte MCP — que conviene tener en cuenta al dimensionar el servidor. Hemos corregido lo obsoleto y añadido secciones de escalado, hardening, decisión Cloud vs self-hosted y errores comunes.
n8n en 2026: del 1.x al 2.x
Si montaste tu instancia siguiendo la versión original de este artículo (finales de 2025), probablemente estés en la rama 1.x. Desde entonces n8n ha publicado la versión 2.0 (enero de 2026) y sus sucesivas 2.x, con cambios relevantes para producción: el nodo AI Agent y el soporte nativo de MCP (Model Context Protocol) convierten a n8n en una plataforma para orquestar agentes de IA además de integraciones clásicas, y los task runners ejecutan el código JavaScript de los nodos Code en procesos aislados, mejorando seguridad y estabilidad. Nada de esto cambia la arquitectura base de esta guía — sigue siendo contenedor + PostgreSQL + proxy — pero sí el consumo de recursos: una instancia que además ejecuta agentes con LLMs agradece más CPU y memoria que la que solo mueve webhooks.
El salto de mayor a mayor exige leer las notas de migración: la 2.x retiró variables de entorno y comportamientos heredados de la 1.x. Si tus workflows conectan APIs y bases de datos, tenemos una guía específica de n8n para conectar APIs REST y bases de datos, y otra sobre sincronización de CRM y ERP con n8n.
Arquitectura recomendada
El stack mínimo para producción consta de tres componentes: el contenedor n8n (aplicación principal), una base de datos PostgreSQL para persistir workflows y ejecuciones, y un reverse proxy (Nginx o Traefik) para SSL y routing. Opcionalmente, puedes añadir Redis para queue mode si necesitas escalar workers horizontalmente.
La configuración se gestiona mediante variables de entorno en un archivo docker-compose.yml. Las más importantes son: DB_TYPE=postgresdb, las credenciales de conexión a PostgreSQL, N8N_ENCRYPTION_KEY (crítico para cifrar credenciales almacenadas), y WEBHOOK_URL con la URL pública de tu instancia.
Docker Compose para n8n + PostgreSQL
Un archivo docker-compose.yml típico define dos servicios: el contenedor de PostgreSQL con un volumen persistente, y el contenedor de n8n que depende de PostgreSQL. El volumen de n8n almacena archivos subidos y configuraciones locales, mientras que los workflows y credenciales van a la base de datos.
Es fundamental configurar GENERIC_TIMEZONE y TZ a tu zona horaria (por ejemplo, Europe/Madrid) para que los triggers basados en cron se ejecuten correctamente. También recomendamos establecer EXECUTIONS_DATA_PRUNE=true con EXECUTIONS_DATA_MAX_AGE=168 (7 días) para evitar que la base de datos crezca indefinidamente.
Dos ajustes más que en 2026 consideramos parte del despliegue estándar: activa los task runners (N8N_RUNNERS_ENABLED=true, el modo recomendado y ya por defecto en versiones recientes) para que el código de los nodos Code no se ejecute en el proceso principal, y fija la versión concreta de la imagen (por ejemplo n8nio/n8n:2.5.1) en lugar de latest: en producción quieres decidir tú cuándo actualizas, no que lo decida un redespliegue del contenedor.
Configuración de seguridad
En producción, n8n debe estar protegido. Ojo con las guías antiguas: la autenticación básica por variables de entorno (N8N_BASIC_AUTH_ACTIVE) se eliminó en n8n 1.0 y hoy esas variables se ignoran. El mecanismo actual es el gestor de usuarios integrado, con cuentas individuales, roles y 2FA, que conviene activar para todas las cuentas y en especial las de administración. Coloca n8n detrás de un reverse proxy con certificado SSL de Let’s Encrypt. Nunca expongas el puerto 5678 directamente a internet.
Para equipos que gestionan múltiples proyectos de plataformas a medida, recomendamos aislar cada instancia de n8n por proyecto o cliente, usando redes Docker separadas y bases de datos dedicadas. Esto previene que un workflow mal configurado afecte a otros.
El otro frente es lo que n8n guarda: las credenciales de todas las APIs y bases de datos que tocan tus workflows. Aplica mínimo privilegio en cada una (una API key de solo lectura si el workflow solo lee), restringe qué usuarios pueden ver cada credencial y custodia la N8N_ENCRYPTION_KEY como lo que es: la llave de esa caja fuerte. Lo desarrollamos en la guía de seguridad en n8n: credenciales, permisos y buenas prácticas y, para la cara expuesta de tus automatizaciones (los webhooks son endpoints públicos), en seguridad en APIs REST: autenticación, rate limiting y buenas prácticas.
Escalar con queue mode
Una sola instancia de n8n aguanta más de lo que parece, pero tiene un límite: todo se ejecuta en el mismo proceso. El queue mode separa responsabilidades: el contenedor principal atiende el editor y los triggers, encola cada ejecución en Redis, y uno o varios workers las procesan en paralelo. Añadir capacidad pasa a ser levantar más workers, sin tocar el resto del stack.
¿Cuándo dar el salto? Las señales típicas: ejecuciones que se acumulan en cola en horas punta, webhooks que responden lento porque el proceso principal está ocupado, o workflows pesados (informes, sincronizaciones masivas) que bloquean al resto. Para cargas serias — cientos de miles de ejecuciones al mes, alta disponibilidad, autoescalado — el siguiente escalón es orquestarlo todo en Kubernetes; lo contamos en n8n en Kubernetes: escalar automatizaciones a nivel enterprise. Nuestra recomendación pragmática: empieza simple con Docker Compose, y escala cuando los datos (no la intuición) lo pidan.
Monitorización y backups
Configura health checks en Docker para reiniciar n8n automáticamente si deja de responder. Programa backups diarios de PostgreSQL con pg_dump. Si usas Kubernetes, puedes configurar liveness/readiness probes y CronJobs para backups automatizados.
Para monitorización avanzada, n8n expone métricas compatibles con Prometheus en el endpoint /metrics. Puedes visualizarlas con dashboards de Grafana para tener visibilidad en tiempo real del rendimiento de tus automatizaciones.
Tres matices que marcan la diferencia el día que algo falla. Primero: el backup de PostgreSQL no sirve de nada sin la N8N_ENCRYPTION_KEY — las credenciales están cifradas con ella, así que guárdala en tu gestor de secretos junto a la política de backups. Segundo: exporta también los workflows en JSON de forma periódica (la CLI de n8n lo automatiza); es tu red de seguridad si un borrado accidental convive con una ventana de backup desafortunada. Tercero: define un error workflow global que te avise (Slack, email) cuando cualquier workflow de producción falle — la monitorización de infraestructura no detecta un workflow que termina «bien» pero sin hacer su trabajo.
Actualización y mantenimiento
Actualizar n8n es tan simple como cambiar la etiqueta de imagen en docker-compose.yml y hacer docker-compose pull && docker-compose up -d. Sin embargo, siempre haz backup antes de actualizar — las migraciones de base de datos son automáticas pero irreversibles. Revisa el changelog de cada versión para detectar breaking changes en nodos que uses.
Con la rama 2.x esto es aún más importante: los saltos de versión mayor retiran funcionalidad deprecada, y un workflow que dependía de un comportamiento antiguo puede romperse en silencio. El procedimiento que aplicamos en mantenimiento de plataformas: replicar la instancia en un entorno de pruebas con una copia de la base de datos, actualizar ahí, ejecutar los workflows críticos de punta a punta, y solo entonces actualizar producción. El «rollback» real es restaurar el backup — otra razón para haberlo probado antes.
¿Self-hosted o n8n Cloud?
La alternativa a todo lo anterior es n8n Cloud, desde unos 20-24 € al mes: cero operación, actualizaciones automáticas y soporte. Para equipos pequeños sin nadie de infraestructura, es un punto de partida razonable.
El self-hosted gana cuando entran en juego el control del dato y el coste a escala: tus workflows procesan datos de clientes que no quieres sacar de tu infraestructura (RGPD manda, especialmente con datos sensibles), necesitas acceso a sistemas internos que no vas a exponer a un SaaS, o el volumen de ejecuciones haría el plan Cloud más caro que un VPS. También es la opción natural si tu organización formaliza su seguridad — en un marco tipo ISO 27001, tener la plataforma de automatización dentro del perímetro simplifica el control de accesos, el registro de actividad y el análisis de riesgos. El precio es la operación: todo lo descrito en esta guía es trabajo recurrente, tuyo o de tu partner técnico.
Webhooks en producción: la parte que más se olvida
Buena parte del valor de n8n está en los webhooks — endpoints que reciben eventos de tu ecommerce, tu CRM o cualquier sistema externo — y son también la pieza que más problemas da al pasar a producción. El primero es de configuración: WEBHOOK_URL debe apuntar al dominio público con HTTPS, porque de lo contrario n8n registra en los servicios externos URLs internas del contenedor que jamás recibirán nada. El segundo es de proxy: las peticiones con payloads grandes o respuestas lentas necesitan que Nginx o Traefik tengan límites de tamaño de cuerpo y timeouts coherentes con lo que tus workflows procesan, o verás errores 502 intermitentes difíciles de diagnosticar.
El tercero es de diseño: los sistemas que emiten webhooks reintentan cuando no reciben un 200 rápido. Si tu workflow tarda medio minuto en procesar, responde primero y procesa después (o encola en queue mode), y hazlo idempotente: el mismo evento entregado dos veces no puede crear dos pedidos ni enviar dos facturas. Distinguir la URL de test de la de producción durante el desarrollo — n8n genera ambas — evita además el clásico «funcionaba en el editor y en producción no».
PostgreSQL bien dimensionado
La base de datos es el componente que más agradece atención a medio plazo. Algunas pautas que aplicamos de serie: usa una versión moderna y soportada de PostgreSQL (16 o 17 en 2026) desde el principio, porque migrar de mayor con la instancia en marcha es un trabajo extra que nadie disfruta; dale su propio volumen con espacio de sobra y una alerta de disco al 80 %; y vigila las conexiones — n8n con varios workers puede agotar el max_connections por defecto, señal de que toca ajustar el pool o poner un pgbouncer delante.
El historial de ejecuciones merece mención aparte: con la purga activada, PostgreSQL marca el espacio como reutilizable, pero el autovacuum necesita margen para hacer su trabajo; si la base de datos creció descontrolada antes de activar la purga, recuperar el espacio en disco exige mantenimiento manual. Y si tus workflows mueven ficheros (PDFs, imágenes, exports), configura el almacenamiento de datos binarios en el sistema de archivos o en un bucket S3 en lugar de la base de datos — meter binarios en PostgreSQL es la vía rápida hacia backups lentos y restauraciones eternas.
Errores comunes en despliegues de n8n
1. Quedarse en SQLite. La instalación por defecto funciona… hasta que la base de datos se corrompe con volumen real. PostgreSQL desde el día uno.
2. Perder la N8N_ENCRYPTION_KEY. Se regenera el contenedor sin fijar la clave y, de repente, todas las credenciales guardadas son ilegibles. Fíjala explícitamente y guárdala fuera del servidor.
3. Exponer el puerto 5678. Sin proxy, sin SSL y con el editor accesible desde internet. Los escáneres automatizados encuentran instancias así todos los días.
4. No purgar ejecuciones. Meses de historial de ejecuciones con payloads completos inflan PostgreSQL hasta que el disco se agota — normalmente de madrugada.
5. Webhooks sin autenticación. Un webhook es un endpoint público; sin token o firma, cualquiera que descubra la URL puede disparar tu workflow o inyectarle datos.
Preguntas frecuentes
¿Cuántos recursos necesita n8n en producción?
Para cargas moderadas (decenas de workflows, miles de ejecuciones al día), 2 vCPU y 4 GB de RAM con PostgreSQL en el mismo host van sobrados. Los workflows con IA (agentes, procesamiento de documentos) y las ejecuciones con payloads grandes son lo que dispara el consumo; ahí conviene medir antes de dimensionar.
¿Puedo migrar de SQLite a PostgreSQL sin perder nada?
Sí: exporta workflows y credenciales con la CLI de n8n, levanta la instancia nueva apuntando a PostgreSQL con la misma N8N_ENCRYPTION_KEY, e importa. Sin esa clave, las credenciales no se podrán descifrar.
¿Sigue sirviendo N8N_BASIC_AUTH_ACTIVE?
No. Desapareció con n8n 1.0. El control de acceso actual es el gestor de usuarios integrado (cuentas, roles, 2FA) y, en planes de pago, SSO. Si una guía la menciona, es anterior a 2023.
¿Cada cuánto conviene actualizar?
Una cadencia mensual sobre versiones estables es un buen equilibrio: recibes correcciones de seguridad sin vivir en el filo. Lo importante no es la frecuencia sino el método: backup, staging, pruebas de los workflows críticos y entonces producción.
¿n8n es seguro para datos personales bajo RGPD?
Self-hosted, sí — con la ventaja de que los datos no salen de tu infraestructura. Pero la herramienta no te exime del trabajo: minimiza los datos que persisten en el historial de ejecuciones, purga con EXECUTIONS_DATA_PRUNE, restringe el acceso por roles y documenta los flujos que tocan datos personales.
¿Necesito queue mode desde el principio?
No. Para la mayoría de empresas, una instancia única bien configurada cubre los primeros meses (o años) sin despeinarse. Queue mode añade Redis y workers que también hay que operar; actívalo cuando veas ejecuciones encoladas de forma sostenida o webhooks degradados en horas punta, no antes. La buena noticia es que el salto no exige rehacer nada: son variables de entorno y contenedores adicionales sobre el mismo stack.
¿Qué pasa si se cae el contenedor a mitad de una ejecución?
Con los health checks, Docker levanta el servicio de nuevo en segundos, pero la ejecución interrumpida no se retoma sola. Para flujos críticos (facturación, pedidos), diséñalos reanudables: pasos idempotentes, estado intermedio persistido y un trigger de reintento. Es la diferencia entre «se reinició el servidor» y «se perdieron pedidos».
Conclusión
Desplegar n8n en producción no es difícil, pero es fácil hacerlo mal: la distancia entre el docker run de la demo y una plataforma fiable está en PostgreSQL, la encryption key custodiada, el proxy con SSL, los usuarios con 2FA, la purga de ejecuciones y una rutina de backups probados. Con eso resuelto — y la 2.x trayendo agentes de IA y MCP al mismo motor — n8n se ha ganado el puesto de pieza central de automatización en empresas que quieren controlar su stack. Si prefieres que esa operación la lleve un equipo que la hace a diario, hablemos.
¿Quieres automatizar con n8n sin cargar con la infraestructura?
En Keliam desplegamos, aseguramos y mantenemos instancias de n8n en producción: desde el Docker Compose inicial hasta el escalado con workers, backups verificados y monitorización con alertas.
