05 — Operación e infraestructura

Despliegue por colegio

Un VPS por colegio, gestionado con Dokploy: dominio propio, Let's Encrypt, deploys desde el fork de GitHub del colegio.
Compose por instancia: nginx (SPA + proxy + archivos), bff, core (incluye workers pg-boss), postgres. Solo nginx expone puertos.
Migraciones Prisma corren en el entrypoint del core al boot.
Dimensionamiento inicial (500+ alumnos): VPS 4 vCPU / 8 GB es holgado; el pico real es entrega de notas y matrículas — cubierto por colas y paginación.

Entorno	Dónde	Datos
dev	compose local	seeds ficticios
staging	VPS (puede compartir con prod del mismo colegio, compose aparte)	solo datos ficticios — nunca datos reales de menores (LOPDP)
prod	VPS del colegio	reales

El colegio valida en staging antes de cada release relevante.

PR: lint + tests unit/integración (Testcontainers) + tests front + build.
Merge a main: build de imágenes versionadas (tags) → push a registry.
Deploy a staging automático; a prod con aprobación manual (webhook de Dokploy).
Smoke E2E post-deploy (login, listado paginado, generación de una boleta de prueba en staging).
Builds de la app Flutter por flavor (white-label) firmados para cada colegio.

pg_dump diario automatizado + copia fuera del VPS (storage externo barato). Retención: diarios 30 días; snapshots de cierre de período/año permanentes.
Volumen de archivos incluido en el backup.
Restore drill periódico (mensual o antes de cada cierre de período): un backup que nunca se restauró no es un backup. Documentar el procedimiento de restore paso a paso.

Uptime check externo (endpoint /health del BFF y core).
Errores a Sentry (self-hosted o plan free).
Alerta de espacio en disco (los PDFs y archivos crecen).
Logs de contenedores con rotación; el logger propio ya provee correlationId y masking.

Core y Postgres jamás expuestos; acceso al VPS solo por SSH con llave.
Rate limiting en BFF (login y endpoints públicos), lockout progresivo en credenciales.
Secretos por variables de entorno de Dokploy — nunca en el repo ni en seeds.
Auditoría de accesos a datos sensibles (LOPDP): quién consultó ficha de alumno/observaciones DECE.

Repo base (este) + fork por colegio. Los forks pueden divergir (decisión asumida), con convención: personalizaciones en módulos/overrides separados y un FORK_NOTES.md que documente cada divergencia, para poder traer fixes del base con merge cuando convenga.