Despliegue

ixiclinic se despliega en dos planos: el API (con su PostgreSQL) corre en un VPS vía Docker Compose, y las apps Next.js se despliegan en Vercel. Esta página es genérica: describe cómo desplegar, no las credenciales concretas de ningún entorno. Cada equipo rellena las variables de su propia infraestructura.

API — Docker Compose en el VPS

El API se empaqueta con un Dockerfile multi-stage (apps/api/Dockerfile) y se orquesta con apps/api/deploy/docker-compose.prod.yml, que define dos servicios: postgres y api.

Dockerfile

• Base: node:22-alpine, con pnpm@9.15.9 vía corepack.
• Stage build: instala dependencias con --frozen-lockfile, compila @ixiclinic/types y luego el API.
• Stage production: copia solo lo necesario (dist, node_modules, las migraciones SQL y los assets). Crea y usa un usuario no-root (ixiclinic).
• Healthcheck: consulta http://localhost:5000/api/health cada 30 s.
• Arranque: node dist/migrate.js && exec node dist/index.js — aplica las migraciones pendientes y, solo si tienen éxito, levanta el servidor (falla rápido si la migración rompe).

Compose de producción

• postgres — imagen postgres:17-alpine, volumen persistente pgdata, healthcheck con pg_isready, límites de memoria. No publica puertos a internet.
• api — se construye desde el Dockerfile, publica el puerto solo en localhost (127.0.0.1:5000:5000) para que un proxy inverso (p. ej. Nginx) lo exponga por HTTPS, y arranca después de que postgres esté saludable (depends_on: condition: service_healthy).
• Ambos servicios viven en una red Docker interna; el API se conecta a la base por el nombre de servicio (postgres:5432), no por una IP pública.

Pasos de despliegue (genéricos)

En el VPS, dentro del repo:

git pull origin main
cd apps/api
docker compose -f deploy/docker-compose.prod.yml build api
docker compose -f deploy/docker-compose.prod.yml up -d api

Las migraciones se aplican solas al arrancar el contenedor (ver Migraciones). No hace falta un paso manual de migración en el flujo normal.

Variables de entorno (no se commitean)

El servicio api carga un archivo .env.prod (referenciado por env_file en el compose) que no está en el repositorio. Ahí van todas las variables sensibles. El compose deriva la DATABASE_URL a partir de las de PostgreSQL.

Importante: Un equipo nuevo debe crear su propio .env.prod en el VPS con las variables de su infraestructura. Nunca lo commitees ni lo compartas por canales inseguros. La configuración del API se valida con Zod en apps/api/src/config/env.ts, que rechaza el arranque si falta algo obligatorio o los secretos JWT son demasiado cortos.

Apps Next.js — Vercel

Las apps admin, console, portal, landing y docs se despliegan en Vercel con auto-deploy en cada push a main. No hay paso manual: al hacer merge a main, Vercel construye y publica cada proyecto.

Cada proyecto de Vercel necesita su propia variable de API:

• Las apps Next.js usan NEXT_PUBLIC_API_URL.
• El lab-site (Vite) usa VITE_API_URL.

Todas apuntan al endpoint público del API.

URLs públicas de producción