# Arquitectura

## Papel de OVH

OVH es la frontera pública endurecida de MESAVAULT.

Su papel correcto es:

- publicar servicios web
- centralizar identidad y MFA
- alojar tenants de cliente
- enrutar subrutas públicas
- actuar como ingress LoRaWAN
- hablar con el stack por Tailscale

## Separación correcta con platform-40

La arquitectura consolidada es:

### OVH
- Traefik
- Authentik
- logout handler
- Gateway Bridge
- tenant Grafana del cliente
- routing `/control/*`

### platform-40
- Mosquitto
- ChirpStack core
- Grafana interno
- MinIO
- Portainer
- PostgreSQL
- servicios de vertical
- persistencia real

## Principio clave

OVH no guarda datos del backend. OVH enruta y autentica. `platform-40` sí guarda datos.

## Caso drenaje

Arquitectura final documentada:

Cliente final  
→ `https://elpicon.panel.mesavault.es`  
→ Grafana tenant del cliente en OVH  
→ iframe a `/control/ui`  
→ OVH VPS  
→ Traefik + Authentik + routing `/control/*` + logout handler + Tailscale  
→ `platform-40`  
→ `drain_control_api`, `drain_control_scheduler`, `drain01_norm`, `drain01_pg`, `mv_postgres_hot`, `mv_mosquitto`, `cs_chirpstack`  
→ ChirpStack  
→ nodo físico `LSN50 + XKC`

## Decisión clave de publicación

Se valoraron dos estrategias:

- subdominio separado para control
- subruta dentro del mismo tenant

La decisión final fue:

- publicar la UI en `/control/` bajo el mismo host del tenant del cliente

Motivos:
- un solo host por cliente
- más limpio para escalar
- mejor integración visual
- más fácil de embeber en Grafana
- arquitectura más coherente con el tenant público del cliente

## Tailscale

Tailscale es el enlace correcto entre OVH y `platform-40` para que OVH hable con el stack sin abrir servicios internos a Internet.

## Advertencia importante

Con Tailscale activo, cualquier contenedor publicado en `0.0.0.0` en `platform-40` pasa a ser accesible también por la interfaz Tailscale. Por eso el criterio correcto de exposición mínima se reforzó tanto en el frontal como en el backend.