Saltar al contenido principal

Guía de despliegue y seguridad para instalación en VPS

Esta guía completa cubre el despliegue de InsForge en un VPS (servidor privado virtual) genérico para producción, el endurecimiento de tu instancia con buenas prácticas de seguridad, y su mantenimiento a lo largo del tiempo con procedimientos seguros de actualización y reversión.
Alcance: Esta guía es independiente del proveedor. Funciona en cualquier VPS con Linux —se recomienda Ubuntu/Debian— ya sea de proveedores como DigitalOcean, Hetzner, Linode, Vultr, OVH, o un servidor bare-metal. Para guías específicas de nube (AWS EC2, GCP, Azure, Render), consulta las demás guías de esta sección.

📋 Tabla de contenidos


Requisitos previos

Antes de empezar, asegúrate de tener:
  • Un VPS con Ubuntu 22.04 LTS o Ubuntu 24.04 LTS (Debian 12 también funciona)
  • Acceso root o sudo al servidor
  • Un nombre de dominio registrado (recomendado para producción)
  • Familiaridad básica con la línea de comandos de Linux y SSH

Parte 1 — Despliegue

1. Requisitos del servidor

ResourceMinimumRecommended
CPU2 vCPU4 vCPU
RAM2 GB4 GB+
Storage20 GB SSD40 GB+ SSD
OSUbuntu 22.04+Ubuntu 24.04 LTS
NetworkPublic IPv4Public IPv4 + IPv6
💡 Consejo: Para cargas de producción con múltiples usuarios, empieza con 4 GB de RAM. Monitoriza el uso con docker stats y escala verticalmente según sea necesario.
InsForge consta de 4 servicios que se ejecutan juntos:
ServiceDescriptionInternal Port
PostgreSQLPrimary database5432
PostgRESTAuto-generated REST API layer3000 (mapped to 5430)
InsForgeNode.js backend + dashboard7130
DenoServerless functions runtime7133

2. Configuración inicial del servidor

2.1 Conéctate a tu VPS

2.2 Actualiza los paquetes del sistema

2.3 Crea un usuario de despliegue (no root)

Nunca ejecutes servicios de producción como root. Crea un usuario dedicado:

2.4 Configura la zona horaria

2.5 Habilita las actualizaciones de seguridad automáticas


3. Instalar Docker y Docker Compose

3.1 Instala el motor de Docker

3.2 Añade el usuario de despliegue al grupo de Docker

3.3 Verifica la instalación de Docker

⚠️ Nota de seguridad: Añadir un usuario al grupo docker le otorga privilegios equivalentes a root en el host. Esto es aceptable para un usuario de despliegue dedicado, pero no debe hacerse con cuentas de propósito general en servidores compartidos.

4. Desplegar InsForge con Docker Compose

4.1 Descarga el archivo de Docker Compose para producción

4.2 Inicia InsForge

4.3 Verifica que todos los servicios estén en ejecución

Deberías ver 4 contenedores en estado running o healthy:

4.4 Prueba el endpoint de estado (health)

Respuesta esperada:

5. Configuración de variables de entorno

Edita tu archivo .env para configurar InsForge para producción:

5.1 Variables obligatorias

Estas deben cambiarse respecto a los valores predeterminados antes de pasar a producción:
Genera secretos seguros directamente desde la terminal:
⚠️ Importante: JWT_SECRET y ENCRYPTION_KEY deben ser valores diferentes. Si ENCRYPTION_KEY no está definida, InsForge recurre a JWT_SECRET como respaldo — pero rotar JWT_SECRET más adelante corromperá de forma permanente todos los secretos almacenados (claves de API, tokens OAuth, etc.).

5.2 Variables de base de datos

5.3 Variables de puertos

Puertos predeterminados que usa InsForge:
💡 Puedes cambiarlos si entran en conflicto con otros servicios de tu VPS.

5.4 Requeridas para despliegues

Estas variables solo son necesarias si planeas usar las funciones de despliegue de InsForge (desplegar proyectos a través del panel). Si no necesitas despliegues, omite esta sección.
⚠️ Nota: Estas variables (AWS_S3_BUCKET, AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, PROJECT_ID, MAX_FILE_SIZE) provienen de la configuración del .env.example raíz. No están presentes en deploy/docker-compose/.env.example, y deploy/docker-compose/docker-compose.yml no las pasa al contenedor insforge, por lo que definirlas en tu .env no tiene efecto en ese compose de producción. Para usarlas, añade cada una al bloque environment del servicio insforge en tu docker-compose.yml.

5.5 Variables opcionales

Después de editar, reinicia los servicios para aplicar los cambios:

6. Configuración del proxy inverso

Un proxy inverso se sitúa delante de InsForge, encargándose de la terminación TLS, HTTP/2 y una URL limpia sin números de puerto.

Opción A: Nginx (recomendado)

6.1 Instala Nginx
6.2 Crea la configuración del sitio
Pega la siguiente configuración — sustituye insforge.yourdomain.com por tu dominio real:
6.3 Habilita el sitio

Opción B: Caddy (HTTPS automático)

Caddy es una alternativa más simple que gestiona los certificados TLS automáticamente.
Instala Caddy
Configura Caddy
Caddy obtendrá y renovará automáticamente los certificados de Let’s Encrypt — sin pasos adicionales.

7. Configuración de HTTPS / TLS

Si elegiste Caddy en el paso 6, TLS ya está gestionado automáticamente. Pasa directamente a la Parte 2.

7.1 Instala Certbot (para Nginx)

7.2 Obtén certificados SSL

Sigue las indicaciones interactivas. Certbot hará lo siguiente:
  1. Verificar la propiedad del dominio mediante un desafío HTTP
  2. Obtener un certificado firmado de Let’s Encrypt
  3. Actualizar automáticamente tu configuración de Nginx para servir HTTPS
  4. Configurar la redirección HTTP → HTTPS

7.3 Verifica la renovación automática

Los certificados de Let’s Encrypt caducan cada 90 días. Certbot instala un temporizador de systemd para la renovación automática:

7.4 Actualiza el entorno de InsForge para HTTPS

Después de obtener tu certificado, actualiza tu .env para usar URLs HTTPS:
Reinicia InsForge para aplicar los cambios:

Parte 2 — Seguridad

8. Gestión de puertos

Puertos que deben estar abiertos (a través del proxy inverso)

PortProtocolPurpose
22TCPSSH (restrict source IP)
80TCPHTTP → HTTPS redirect
443TCPHTTPS (reverse proxy)

Puertos que deben estar cerrados al público

Estos puertos se usan únicamente para la comunicación interna entre servicios de Docker. Nunca deben exponerse a internet:
PortServiceWhy Close It
5432PostgreSQLDirect DB access — use docker exec instead
5430PostgRESTInternal REST layer — proxied through InsForge
7130InsForgeAPI + dashboard, accessed via reverse proxy on 443, not directly
7131(unused)Published by compose (AUTH_PORT), but no process listens on it
7133DenoInternal serverless runtime
⚠️ Crítico: El docker-compose.yml predeterminado vincula los puertos a 0.0.0.0 (todas las interfaces), no a 127.0.0.1. Esto significa que Docker expondrá los servicios directamente a internet, saltándose UFW por completo (Docker manipula iptables directamente). Debes añadir el prefijo 127.0.0.1: a cada puerto publicado en tu docker-compose.yml:
Sin este prefijo, cualquier persona en internet puede acceder directamente a estos servicios — incluido PostgreSQL con credenciales predeterminadas. Consulta la Sección 9.2 para más detalles.

9. Configuración del firewall (UFW)

UFW (Uncomplicated Firewall) es la forma más sencilla de gestionar iptables en Ubuntu.

9.1 Instala y configura UFW

Salida esperada:
⚠️ Crítico: Permite siempre SSH antes de habilitar UFW, o te quedarás bloqueado fuera del servidor.

9.2 Advertencia sobre Docker y UFW

Docker manipula iptables directamente, lo que puede saltarse las reglas de UFW. Para evitarlo: Opción 1 — Vincular los puertos a localhost (recomendado): En tu docker-compose.yml, antepón 127.0.0.1: a los puertos:
Opción 2 — Desactivar la gestión de iptables de Docker:
⚠️ Desactivar la gestión de iptables de Docker requiere configuración manual de red. Se prefiere la Opción 1 para la mayoría de configuraciones.

9.3 Restringe SSH a tu IP (opcional)

Para máxima seguridad, restringe el acceso SSH a una dirección IP conocida:

10. Ejecutar servicios como usuario no root

La imagen Docker de InsForge ya sigue las buenas prácticas de no root:
  • El Dockerfile de producción establece USER node (UID 1000), por lo que el proceso de la aplicación dentro del contenedor se ejecuta como un usuario no root.
  • Las operaciones de Docker a nivel de sistema están gestionadas por el usuario deploy (creado en el Paso 2.3), que tiene acceso al socket de Docker a través del grupo docker.
Verifica el usuario del contenedor:
Endurecimiento adicional: Añade security_opt a cada servicio de tu docker-compose.yml para evitar la escalada de privilegios:

11. Endurecimiento de SSH

11.1 Usa autenticación por clave SSH

11.2 Desactiva la autenticación por contraseña

Una vez confirmado que la autenticación basada en claves funciona:
Configura lo siguiente:
Reinicia SSH:

11.3 Instala Fail2Ban

Fail2Ban bloquea automáticamente las IPs que muestran actividad maliciosa (por ejemplo, fuerza bruta contra SSH):
Añade o asegúrate de que estén presentes estos ajustes:

12. Seguridad de Docker

12.1 Mantén Docker actualizado

12.2 Limita los recursos de los contenedores (opcional)

Evita que un único contenedor consuma todos los recursos:

12.3 Sistema de archivos raíz de solo lectura (avanzado)

Para un endurecimiento adicional, monta el sistema de archivos del contenedor como de solo lectura cuando sea posible:
⚠️ Esto requiere pruebas — algunos servicios necesitan directorios con permiso de escritura para cachés o archivos temporales.

12.4 Restringe los orígenes de CORS

Por defecto, el backend permite todos los orígenes. Refleja el encabezado Origin de la solicitud de vuelta en la respuesta y, para las respuestas del proxy de funciones, establece Access-Control-Allow-Origin: *. Esto es conveniente para el desarrollo local, pero demasiado permisivo para producción. Para un despliegue en producción, restringe los orígenes permitidos a los dominios que realmente sirves (por ejemplo, tu panel y los dominios de tu aplicación), de modo que otros sitios no puedan hacer solicitudes entre orígenes con credenciales a tu API.

13. Gestión de secretos

Sí ✅

  • Guarda los secretos en el archivo .env con chmod 600 ~/insforge/.env
  • Usa valores separados para JWT_SECRET y ENCRYPTION_KEY
  • Genera secretos con openssl rand -base64 32
  • Haz una copia de seguridad de tu archivo .env en una ubicación segura y sin conexión

No ❌

  • Confirmar (commit) el .env en el control de versiones
  • Reutilizar el mismo secreto para varias variables
  • Usar contraseñas predeterminadas (change-this-password, postgres) en producción
  • Compartir secretos por canales sin cifrar

Parte 3 — Actualización y mantenimiento

14. Copia de seguridad previa a la actualización

Realiza siempre una copia de seguridad antes de actualizar. Esto te da una vía de recuperación si algo sale mal.

14.1 Haz una copia de seguridad de la base de datos

14.2 Haz una copia de seguridad del entorno y los volúmenes

14.3 Registra la versión actual


15. Actualizar InsForge

15.1 Descarga las imágenes más recientes

15.2 Aplica la actualización

Presiona Ctrl+C para dejar de seguir los logs.

15.3 Verifica la actualización

15.4 Actualiza el archivo de Docker Compose (si es necesario)

Ocasionalmente, las nuevas versiones pueden incluir cambios en docker-compose.yml. Para incorporar estos cambios:

16. Procedimiento de reversión

Si una actualización causa problemas, sigue estos pasos para revertirla:

16.1 Detén los servicios afectados

16.2 Restaura el archivo de Docker Compose anterior

16.3 Fija una versión específica de la imagen

Edita docker-compose.yml y sustituye las etiquetas latest por la versión anterior:
Nota: el deploy/docker-compose actual fija la versión v1.5.0, y el proyecto ya está en la línea 2.x. Fija la versión que estuvieras ejecutando antes de la actualización.

16.4 Restaura la base de datos (si es necesario)

Restaura la base de datos solo si la actualización incluyó una migración de base de datos que causó problemas:

16.5 Restaura el archivo de entorno (si cambió)


17. Copias de seguridad automatizadas

Configura una tarea cron para copias de seguridad automáticas diarias:

17.1 Crea un script de copia de seguridad

17.2 Programa con Cron

Añade esta línea para copias de seguridad diarias a las 3:00 a. m.:

17.3 Copias de seguridad fuera del sitio (recomendado)

Para la recuperación ante desastres, copia las copias de seguridad a una ubicación externa:

18. Monitorización y comprobaciones de estado

18.1 Comprueba el estado de los servicios

18.2 Consulta los logs

18.3 Endpoint de comprobación de estado

Monitoriza el endpoint de estado desde el exterior. Una comprobación sencilla basada en cron:
O usa un servicio gratuito de monitorización de disponibilidad como UptimeRobot o Betterstack para monitorizar https://insforge.yourdomain.com/api/health.

Referencia rápida

Comandos esenciales

Lista de verificación de seguridad

  • Usuario de despliegue creado (no root)
  • Autenticación por clave SSH habilitada
  • Autenticación por contraseña de SSH deshabilitada
  • Inicio de sesión root deshabilitado
  • Firewall UFW habilitado (solo puertos 22, 80, 443)
  • Puertos de Docker vinculados a 127.0.0.1
  • Fail2Ban instalado y activo
  • JWT_SECRET cambiado del valor predeterminado (32+ caracteres)
  • ENCRYPTION_KEY definida (distinta de JWT_SECRET)
  • ROOT_ADMIN_PASSWORD cambiada del valor predeterminado
  • POSTGRES_PASSWORD cambiada del valor predeterminado
  • Permisos del archivo .env establecidos en 600
  • HTTPS habilitado mediante Certbot o Caddy
  • Copias de seguridad diarias automatizadas configuradas
  • Actualizaciones de seguridad no asistidas habilitadas

Solución de problemas

No se puede conectar tras habilitar UFW

Si te quedas bloqueado fuera, usa la consola web de tu proveedor de VPS (acceso fuera de banda) para:

Docker se salta UFW

Docker manipula iptables directamente. Vincula los puertos a 127.0.0.1 en docker-compose.yml como se describe en la Sección 9.2.

Los servicios no arrancan

El certificado SSL no se renueva

Conflictos de puertos

Problemas de conexión a la base de datos


🆘 ¿Necesitas ayuda?