Instalar N8N en VPS: guía paso a paso (Hostinger, Docker, PostgreSQL y dominio HTTPS) para un despliegue profesional

Si buscas instalar N8N en VPS y olvidarte de límites, esta guía es para ti. Desplegar N8N en un VPS propio te da control total, ahorro frente a N8N Cloud, escalabilidad real y más seguridad. Aquí lo haremos con Docker y docker-compose, base de datos PostgreSQL (no SQLite en producción), dominio propio y HTTPS con Let’s Encrypt. Usaremos un VPS de Hostinger y un panel de aplicaciones (Doploy; alternativa: EasyPanel) para simplificar el despliegue.

En pocas palabras: montaje profesional, reproducible y listo para crecer. Sigue leyendo.

Tiempo de lectura estimado

12–15 minutos

Puntos clave

• Producción real: N8N en Docker + PostgreSQL, dominio propio y HTTPS automático con Let’s Encrypt.
• Rendimiento: concurrencia controlada, pruning de ejecuciones y límites de memoria para evitar caídas.
• Escalabilidad: modo cola (Redis + workers), separación de componentes y redes internas seguras.
• Seguridad: firewall mínimo, versiones ancladas, backups lógicos y snapshots antes de cambios.
• IA lista: añade PGVector o Qdrant para memorias y búsquedas semánticas en tus agentes.
• Ahorro y control: despliegue reproducible, fácil de mantener y con crecimiento sin fricción.

Tabla de contenidos

• Requisitos previos y arquitectura deseada
• Elegir y preparar el VPS en Hostinger
• Instalar el panel y preparar el servidor
• Despliegue de N8N con PostgreSQL usando plantillas
• Configurar dominio y HTTPS (Let’s Encrypt)
• Activar el plan Community de N8N (opcional pero recomendado)
• Buenas prácticas de producción y seguridad
• Añadir servicios complementarios (ecosistema de automatizaciones)
• Ejemplo express: un agente de IA con memoria en PostgreSQL
• Escalado y alternativas de despliegue
• Solución de problemas comunes
• Checklist final de instalación
• Cierre y próximos pasos
• Conclusión
• Preguntas frecuentes (FAQ)

Requisitos previos y arquitectura deseada

Antes de tocar el servidor, deja clara la arquitectura. Definir bien tu objetivo y límites reduce errores y retrabajo. En términos prácticos, “definir” significa fijar lo que es y lo que no es una cosa, para que todos entendamos lo mismo; puedes contrastar la definición en Cambridge o revisar otra definición en Dictionary.com, y su explicación en Wikipedia.

Requisitos:

• Cuenta en un proveedor de VPS (usaremos Hostinger como ejemplo).
• Dominio propio y acceso al panel DNS de tu dominio.
• Nociones básicas de DNS (crear un CNAME).
• Correo válido para activar N8N y recibir avisos.
• API keys (por ejemplo, OpenAI API) si vas a montar agentes de IA más adelante.

Arquitectura de referencia:

• N8N en contenedor Docker.
• PostgreSQL como base de datos de N8N (evitamos SQLite en producción para estabilidad y concurrencia).
• Dominio propio con HTTPS (certificados SSL de Let’s Encrypt).
• Servicios complementarios opcionales en el mismo VPS o en otro:
  • PostgreSQL adicional con extensión PGVector para memorias/IA.
  • Qdrant (base de datos vectorial), Evolution API (WhatsApp), Redis, etc.

“Lo que no se define, no se puede medir ni mejorar.” Establece límites y metas desde el inicio para minimizar retrabajo.

Sigue bajando: elegiremos el plan de VPS ideal y lo dejaremos listo en minutos.

Elegir y preparar el VPS en Hostinger

Para automatizaciones con N8N, el plan KVM2 de Hostinger suele dar el mejor equilibrio de recursos y precio. Con 2 vCPU y memoria suficiente para flujos medianos, es un punto de partida sólido con margen de escalado.

Qué mirar al elegir:

• Procesador e I/O: AMD EPYC y discos SSD NVMe; latencia baja y tiempos de respuesta estables incluso con múltiples flujos.
• Ubicación: elige el centro de datos más cercano a tus usuarios/sistemas para bajar la latencia.
• Copias de seguridad: activa backups semanales (incluidos), considera snapshots antes de cambios grandes y evalúa backups diarios según criticidad.
• Contratación: 12 o 24 meses suelen abaratar el costo. Si tienes cupón, mejor.
• Escalado sin fricción: cuando la carga suba, pasa al siguiente plan sin reinstalar todo.

Consejo: anota tus límites objetivo (memoria, concurrencia, tamaño de base de datos). Así sabrás cuándo escalar sin esperar a que algo se caiga.

Próximo paso: instalar el panel y preparar el servidor.

Instalar el panel y preparar el servidor

En la creación del VPS en Hostinger:

• Selecciona “Sistema operativo con panel” y elige Doploy. Alternativa: EasyPanel si ya lo conoces.
• Establece la contraseña de root y lanza el aprovisionamiento. El panel desplegará Docker, docker-compose y una interfaz web para tus servicios.

Primer acceso y mantenimiento:

• Entra al panel (URL y credenciales que te da Hostinger).
• Haz una actualización inicial del panel y de las plantillas. Repite esto al menos 1 vez al mes para parches de seguridad.
• Reglas básicas de firewall: deja abiertos únicamente los puertos necesarios (HTTP/HTTPS y los que use el panel). El resto, cerrados por defecto.

Listo el panel, toquemos N8N.

Despliegue de N8N con PostgreSQL usando plantillas

Crear el proyecto y usar una plantilla

• En el panel (Doploy): crea un proyecto nuevo.
• Create Service > Template > elige la plantilla de N8N con PostgreSQL.
• Evita la versión “N8N con SQLite” para producción; SQLite se degrada cuando crecen los flujos y la concurrencia.

Revisión del docker-compose generado

Verás servicios como:

• n8n: la app principal.
• postgres: base de datos PostgreSQL dedicada a N8N.
• volúmenes: para persistir datos (base de datos y archivos de N8N).
• puertos: generalmente 5678 interno para N8N; el panel suele manejar el proxy reverso y TLS.

Comprueba:

• Volúmenes montados (para no perder nada tras un reinicio).
• Dependencias: n8n depende de postgres.
• Healthchecks: opcional pero útil para reinicios automáticos si algo falla.

Variables de entorno clave para producción

Estas variables marcan la diferencia entre un demo y un despliegue profesional. Ajusta según tu carga:

Ejecuciones (pruning y guardado):

• EXECUTIONS_DATA_SAVE_ON_ERROR: true para depurar fallos clave.
• EXECUTIONS_DATA_SAVE_ON_SUCCESS: false o “none” para no inflar la base.
• EXECUTIONS_DATA_MAX_AGE: por ejemplo 14d (borra ejecuciones viejas).
• EXECUTIONS_DATA_PRUNE: true para activar la poda automática.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: un tope de seguridad (por ejemplo 10.000).

Rendimiento y estabilidad:

• N8N_CONCURRENCY (o N8N_CONCURRENCY_PRODUCTION_LIMIT): empieza con 5–10 en KVM2; sube con pruebas.
• NODE_ENV=production: habilita optimizaciones de producción.

Memoria:

• N8N_MEMORY_LIMIT o MAX_OLD_SPACE_SIZE: reserva memoria para Node.js. En un VPS con 4 GB, asigna 1024–2048 MB a N8N para evitar OOM. Recuerda dejar espacio a PostgreSQL y al sistema.

Zona horaria:

• TZ: define tu zona (ej. Europe/Madrid o America/Mexico_City) para triggers y logs coherentes.

Base URL y webhooks:

• N8N_HOST: tu subdominio (ej. automatiza.midominio.com).
• N8N_PROTOCOL: https.
• WEBHOOK_URL: la URL pública completa para webhooks; debe coincidir con tu dominio y protocolo.

Estas “definiciones” precisas evitan ambigüedades y errores de OAuth/webhooks.

Deploy y verificación de logs

• Haz Deploy desde el panel.
• Abre los logs de n8n y postgres:
  • n8n debe mostrar “Migrations finished” y “Editor is now accessible”.
  • postgres debe iniciar sin errores de autenticación.
• Entra a la URL temporal del servicio (la que da el panel) y crea el usuario administrador con tu correo.

¿Abre, pero sin dominio propio aún? Perfecto. En el siguiente paso lo conectamos y activamos HTTPS.

Configurar dominio y HTTPS (Let’s Encrypt)

Crear CNAME en el DNS

• En el DNS de tu dominio, crea un CNAME:
  • Nombre/host: el subdominio que quieres (por ejemplo, automatiza).
  • Valor: el dominio público del servicio N8N que te muestra el panel (suele ser algo como n8n-proyecto.tu-panel.app).
• TTL: 5–15 minutos para propagación rápida. Espera a que resuelva correctamente.

Asignar el host personalizado y emitir certificados SSL

• En el servicio N8N (dentro del panel), añade el “Custom Domain” con tu subdominio (automatiza.midominio.com).
• Activa HTTPS con Let’s Encrypt:
  • El panel solicitará y renovará automáticamente el certificado SSL.
  • Si falla: revisa que el CNAME apunte exacto, no existan A/AAAA en conflicto, y que el puerto 80/443 estén accesibles.

Ajustar variables N8N_HOST/WEBHOOK_URL y redeploy

• Actualiza N8N_HOST con tu dominio y N8N_PROTOCOL=https.
• Ajusta WEBHOOK_URL a la URL final con https.
• Redeploy. Prueba el editor en https://automatiza.midominio.com y ejecuta un webhook de prueba.

Nota clave: HTTPS es obligatorio para credenciales OAuth (Google Drive, Gmail, etc.). Muchos proveedores rechazan callbacks sin TLS válido. Sin HTTPS activo, los “callback URLs” no coinciden y OAuth no funciona.

Transición: con el dominio y SSL listos, tu N8N ya puede recibir webhooks públicos y autenticar con Google, Slack y más. Falta un toque final que te dará funciones avanzadas sin coste.

Activar el plan Community de N8N (opcional pero recomendado)

• Pide la licencia gratuita “Community” de N8N con tu email corporativo.
• En N8N: Settings > Enter Activation Key e introduce la clave.
• Beneficios: carpetas, mejoras de UI/UX y características útiles para equipos pequeños sin pasar por caja.

Ya tienes N8N pro corriendo en un VPS con Docker, PostgreSQL, dominio y HTTPS. En la segunda parte optimizaremos concurrencia, límite de memoria y pruning de ejecuciones, veremos backups/snapshots, y añadiremos servicios como PGVector o Qdrant para agentes de IA. Sigue bajando cuando estés listo para afinar y escalar.

Buenas prácticas de producción y seguridad

Concurrencia controlada y modo cola

• Empieza con un límite de concurrencia realista (5–10 en KVM2) y súbelo con métricas.
• Si recibes picos o procesos largos, activa el modo cola (queue mode) para ejecutar peticiones en cola y evitar saturación. El modo cola usa Redis y permite añadir “workers” sin bloquear el editor.

Límite de memoria y procesos “pesados”

• Define N8N_MEMORY_LIMIT o MAX_OLD_SPACE_SIZE para que un flujo no consuma toda la RAM.
• Evita cargar datasets gigantes en un solo nodo. Prefiere paginación o procesar por lotes.
• Reserva RAM para PostgreSQL y el sistema. Como regla simple: 50–60% para N8N, 20–30% para PostgreSQL y resto para OS/servicios.

Pruning de ejecuciones y tamaño de base de datos

• Elige una edad máxima (por ejemplo 14–30 días) y un tope de conteo. Activa EXECUTIONS_DATA_PRUNE.
• Guarda solo lo útil: on error sí, on success no. Así bajas el tamaño de la base, evitas I/O excesivo en SSD NVMe y mantienes baja latencia.

Backups y snapshots con estrategia clara

• Backup lógico diario de PostgreSQL (pg_dump) y prueba de restauración mensual.
• Snapshots del VPS antes de cambios grandes (actualizaciones, migraciones).
• Definir con precisión qué cubre un backup y qué no reduce ambigüedades y errores en crisis; apóyate también en la definición tradicional para alinear criterios.

Actualizaciones y hardening

• Actualiza imágenes Docker y el panel 1 vez al mes. Ancla versiones (tags) para despliegues reproducibles.
• HTTPS forzado, contraseñas robustas y 2FA en el panel.
• Firewall mínimo: abre solo 80/443 (proxy) y el puerto del panel. El resto, cerrado.
• Registra cambios (changelog interno) y audita accesos.

Ubicación y rendimiento

• Mantén servicios cerca de tus usuarios y fuentes de datos. Menos “saltos” = menos latencia.
• Infraestructura con AMD EPYC y SSD NVMe ayuda a flujos con I/O intenso y tareas concurrentes.

Añadir servicios complementarios (ecosistema de automatizaciones)

PostgreSQL adicional con PGVector

• Crea un servicio PostgreSQL aparte para tus apps (no mezcles con la base de N8N).
• Usa una imagen con PGVector si planeas memorias/IA y búsquedas semánticas.
• Conéctalo desde N8N con el host interno (nombre del servicio en Docker), puerto 5432 y credenciales del servicio.
• Asegúrate de que N8N y PostgreSQL-IA estén en la misma red interna (networks) del panel.

Qdrant, Redis, Evolution API y más

• Qdrant: base vectorial veloz, ideal para embeddings y recuperación semántica.
• Redis: colas, cache, rate-limiting; clave si activas queue mode.
• Evolution API (WhatsApp): para bots y notificaciones.
• Añade otros componentes (MySQL, Redis, chatbot frameworks) usando templates del panel. Todos dentro de la red interna para máxima seguridad.

Nota breve sobre licencias

• N8N es fair-code. Revisa condiciones de uso comercial antes de revender o empaquetar. Muchas piezas del stack son open source; combina de forma compatible con tus requisitos legales.

Ejemplo express: un agente de IA con memoria en PostgreSQL

Objetivo: un asistente que recuerde datos del usuario (nombre, preferencia) entre conversaciones.

Preparar la base de memoria

• En tu PostgreSQL-IA, crea una tabla simple:
  • Tabla memories: id, user_id, key, value, updated_at.
• Opcional: habilita PGVector y agrega una columna embedding para recuerdos semánticos.

Workflow en N8N (resumen)

• Trigger: Webhook o node “Chat” con entrada de usuario.
• Nodo PostgreSQL (Read): recupera recuerdos por user_id (ej., nombre, preferencias).
• Nodo de “Set”/“Function”: construye el contexto (system prompt) con los recuerdos.
• Nodo OpenAI (Chat): usa tu OpenAI API Key, con temperatura baja para respuestas estables.
• Nodo PostgreSQL (Upsert): si el usuario dice “Mi nombre es Ana”, guarda/actualiza key=name, value=Ana.
• Respuesta: devuelve el texto al usuario. En la próxima vuelta, el modelo ya recuerda.

Variante con PGVector

• Agrega un nodo de embeddings (OpenAI Embeddings).
• Guarda vector + texto en la base (PGVector o Qdrant).
• Antes de responder, consulta por similitud y agrega los resultados relevantes como memoria contextual.

Buenas prácticas

• Limita el prompt y la cantidad de recuerdos para no inflar latencias.
• Pseudonimiza user_id si manejas datos sensibles.
• Loguea tokens y latencia para saber si necesitas subir plan del VPS o activar queue mode.

Escalado y alternativas de despliegue

Modo cola (queue mode) y workers

• Variables clave: habilita queue mode y añade Redis.
• Arquitectura: un contenedor “main” (editor + orquestación) y N contenedores “worker”.
• Beneficio: ejecutas decenas o cientos de flujos en paralelo, con control fino de concurrencia por worker.

Separación de componentes

• Mueve PostgreSQL a otro VPS o servicio gestionado cuando:
  • La base supera decenas de GB, hay picos de escritura/lectura, o necesitas alta disponibilidad.
• Aísla Qdrant/Redis en instancias propias si compiten por RAM/CPU con N8N.
• Si la latencia entre N8N y tu base aumenta, acerca físicamente (misma región).

¿Cuándo preferir N8N Cloud?

• No hay equipo DevOps, necesitas SLA y soporte 24/7, o compliance exigente.
• Picos impredecibles que prefieres pagar como servicio, no administrar.
• Aun así, esta guía de instalar N8N en VPS te da control y ahorro cuando el stack es estable.

Solución de problemas comunes

• Error de conexión a PostgreSQL:
  • Usa el host interno (nombre del servicio), puerto 5432, misma red Docker.
  • Verifica usuario/contraseña y que el contenedor está healthy.
• Certificado SSL no emite:
  • Revisa CNAME, elimina A/AAAA en conflicto, espera propagación DNS.
  • Asegura puertos 80/443 abiertos. Vuelve a solicitar Let’s Encrypt.
• OAuth no funciona:
  • Comprueba N8N_HOST, N8N_PROTOCOL=https y WEBHOOK_URL exactos.
  • El callback en Google/Slack debe coincidir 1:1 con tu base URL.
• Uso alto de RAM/CPU:
  • Baja N8N_CONCURRENCY, sube límite de memoria de container, aplica pruning.
  • Divide flujos grandes en subflujos y usa paginación.
• Webhooks con timeout:
  • Aumenta timeouts del proxy, usa queue mode para tareas largas y responde pronto (ack + job).
• Zona horaria incorrecta:
  • Ajusta TZ (ej. America/Mexico_City) y redeploy.
• Logs vacíos o ruido excesivo:
  • Verifica niveles de log. Guarda solo lo útil, especialmente en producción.

Checklist final de instalación

• VPS Hostinger creado (plan KVM2 recomendado), región cercana a tus usuarios.
• Panel Doploy/EasyPanel instalado y actualizado; firewall básico aplicado.
• N8N + PostgreSQL desplegados con docker-compose; volúmenes persistentes; healthchecks OK.
• Variables de entorno ajustadas: N8N_HOST, N8N_PROTOCOL, WEBHOOK_URL, TZ, límites de memoria y concurrencia.
• Dominio con CNAME al servicio; HTTPS activo con Let’s Encrypt (certificados SSL renovándose).
• Pruning de ejecuciones configurado; backups diarios y snapshots antes de cambios.
• (Opcional) N8N Community activado.
• (Opcional) Servicios extra: PostgreSQL con PGVector, Qdrant, Redis, Evolution API; conectados por red interna.
• Monitoreo básico: uso de CPU/RAM/disco, latencia y tamaño de base.

Cierre y próximos pasos

• Descarga o crea plantillas (templates) de N8N para acelerar entregas repetitivas.
• Integra Google Workspace, tu CRM, WhatsApp (Evolution API) y webhooks externos.
• Agrega PGVector o Qdrant para agentes de IA con memoria real y búsquedas semánticas.
• Considera queue mode y workers si crece la concurrencia. Escala el VPS o separa bases cuando haga falta.
• Documenta tu arquitectura y límites. Una definición clara de alcance evita malentendidos técnicos y de negocio.

Conclusión

Con este paso a paso dejaste N8N en Docker con PostgreSQL, dominio propio y HTTPS sólido, listo para producción. Ajustaste concurrencia, memoria y pruning; definiste backups y abriste la puerta a servicios como PGVector o Qdrant. Es un despliegue profesional, reproducible y seguro. Cuando necesites más, activa queue mode, separa la base y escala sin drama. Si buscas control y ahorro, instalar N8N en VPS es una decisión inteligente.

Preguntas frecuentes (FAQ)