Despliegue

BloomX está pensado para Vercel (frontend y backend son proyectos Next.js independientes), pero funciona en cualquier host de Node que ejecute next start.

Base de datos#

• PostgreSQL para el frontend (DATABASE_URL) y otra para el backend. Neon, Supabase, RDS… cualquiera.
• Ejecuta npm run db:ensure antes de desplegar contra la base de destino (en Vercel corre solo en prebuild, que necesita DATABASE_URL en el entorno de build). Sin las tablas UserMfa, RevokedSession, AuditEvent, Rule, RuleRun, etc. algunas funciones se degradan y el login de un administrador responde 503.
• db:ensure usa advisory locks por transacción pensados para el pooler de Neon (pgbouncer en modo transacción), pero no se probó contra un Neon real. Si tienes problemas, ejecútalo con la conexión directa (no la del pooler).
• El backend no tiene ensure: aplica su esquema con npm run prisma:push (usa prisma/schema_push.prisma). Revisa siempre lo que prisma db push propone antes de aceptar cambios destructivos.

Frontend en Vercel#

1. Importa el repositorio bloomx como proyecto (Framework: Next.js). Build por defecto: npm run build (ejecuta prebuild → db:ensure y luego next build).
2. Define las variables de entorno del mínimo de producción. En especial NEXTAUTH_SECRET (propio), NEXT_PUBLIC_APP_URL (https) y NEXT_PUBLIC_BACKEND_URL (https).
3. Asigna tu dominio y confirma que TOP_DOMAIN coincide con el tenant que registraste en el backend.
4. Despliega y comprueba GET /api/config.

Backend compartido en Vercel#

1. Proyecto aparte con la carpeta bloomx-backend como raíz. No tiene vercel.json: usa los valores por defecto de Next.js.
2. Variables: mínimo del backend. No definas NEXTAUTH_SECRET, INTERNAL_SECRET, EXTENSION_HOOKS_SECRET ni FRONTEND_INTERNAL_URL.
3. Aplica el esquema con npm run prisma:push y publica las extensiones (Crear una extensión).
4. El backend NO necesita ninguna clave: services.mail y el resto de servicios del host funcionan con la executionGrant que firma cada instancia con su BLOOMX_DOMAIN_PRIVATE_KEY. No definas BACKEND_SIGNING_PRIVATE_KEY (legado deprecado). Cada instancia que quiera GoogleLib, IA por puente o rutas de extensión necesita su clave de dominio: ver Requisito: la clave de dominio.
5. Registro abierto: si tu backend es privado, define ALLOW_OPEN_REGISTRATION=false.

Cron#

Define CRON_SECRET en el proyecto del frontend: Vercel Cron envía automáticamente Authorization: Bearer <CRON_SECRET> a los crons declarados. El código solo comprueba el Bearer (no que la llamada venga de Vercel).

{
  "framework": "nextjs",
  "crons": [
    { "path": "/api/cron/run", "schedule": "0 6 * * *" }
  ]
}

# Recordatorios y reglas (modo global, hasta 50 usuarios). Vercel Cron lo llama con GET y Bearer automáticamente.
curl -sS "https://mail.tu-dominio.com/api/cron/run" -H "Authorization: Bearer $CRON_SECRET"

# Campañas de Elixir en segundo plano (GET o POST). Procesa hasta 5 campañas 'running' (~50 s)
curl -sS "https://mail.tu-dominio.com/api/cron/elixir" -H "Authorization: Bearer $CRON_SECRET"

# Retención (añade ?dryRun=1 para solo contar)
curl -sS "https://mail.tu-dominio.com/api/admin/retention?dryRun=1" -H "Authorization: Bearer $CRON_SECRET"

Los tokens de baja y el resto de endpoints públicos (/api/cron, /api/webhooks, /api/assets) no exigen sesión: se protegen con su propio secreto o firma.

Upstash Redis (opcional)#

Sin Upstash el rate limit es por instancia (memoria). En Vercel cada invocación puede caer en otra instancia, así que para un límite real crea una base en Upstash, copia la URL REST y el token a UPSTASH_REDIS_REST_URL y UPSTASH_REDIS_REST_TOKEN. Si Redis falla, RATE_LIMIT_ON_ERROR=memory (por defecto) cuenta en memoria; nunca bloquea a todos. El rate limit del backend siempre es en memoria.

HTTPS y cabeceras#

• Usa siempre https: la cookie de sesión __Host-… exige Secure y el frontend emite HSTS con preload.
• Si quitas el prefijo __Host- o cambias de dominio, las sesiones existentes se invalidan (ver SESSION_COOKIE_* en Variables).
• Detrás de un proxy propio, haz que sobrescriba x-forwarded-for (el rate limit lo usa) y x-forwarded-host.

Después del despliegue#

1. Configura los webhooks de Resend y el DNS (Correo: Resend y DNS).
2. Rota cualquier credencial que haya estado en texto plano en algún archivo o historial.
3. Repasa Operación (backups y pruebas).