SYS-ADR-006 — Plataformas de despliegue: Vercel, Cloud Run y la Raspberry Pi¶
| Estado | Aceptada |
| Decisión | 2026-07-16, la migración de la API a Cloud Run |
| Registrada | 2026-09-30 |
| Relacionadas | SYS-ADR-001, SYS-ADR-003 |
Contexto¶
El sistema lo construyen dos personas, en un proyecto académico con presupuesto de infraestructura cercano a cero, y tiene que quedar operable por un tercero —la empresa que lo recibe— sin equipo de plataforma.
La API corría en Koyeb, en su plan gratuito, hasta que el servicio quedó bloqueado por cuota del plan y hubo que darlo de baja.
Decisión¶
Tres plataformas, una por naturaleza de carga:
| Pieza | Plataforma | Por qué |
|---|---|---|
| Frontend y BFF | Vercel | Es la plataforma nativa del framework; los previews por rama salen sin configurar nada |
| Cloud API | Google Cloud Run, región us-east1 |
Contenedor sin servidor, escala a cero, plan gratuito suficiente |
| historian, InfluxDB y Edge | Raspberry Pi en planta | No es una elección de plataforma: el PLC está ahí. Ver SYS-ADR-001 |
Los almacenes son servicios gestionados: Postgres y la autenticación en Supabase, más MongoDB y Redis.
Las dos plataformas de nube despliegan desde main, con GitHub Actions. La Pi se despliega
a mano.
El acceso de GitHub a Google Cloud usa federación de identidad con OIDC: no hay claves de servicio guardadas en el repositorio, y el proveedor solo acepta tokens de ese repositorio.
Alternativas consideradas¶
| Alternativa | Por qué no |
|---|---|
| Quedarse en Koyeb | El servicio quedó bloqueado por cuota del plan gratuito. Fue el hecho que forzó la decisión |
| Un solo proveedor de nube para todo | Migrar el frontend fuera de Vercel no aportaba nada y costaba trabajo |
| Kubernetes | Desproporcionado para dos personas y una API |
| Máquina virtual clásica | Más barata de razonar, más cara de operar: parches, certificados, respaldos |
| Servidor propio en la planta del cliente | Descartado: el sistema tiene que ser accesible desde fuera de la planta |
Consecuencias¶
A favor:
- El despliegue de las dos piezas de nube es automático y reproducible, y el de la API se hace por identificador de commit, así que volver atrás es una operación de la plataforma, no un revert en git.
- No hay credenciales de larga vida de Google Cloud en ningún repositorio.
- El costo de infraestructura se mantiene cerca de cero.
En contra:
- La configuración no vive en ningún repositorio. Los valores reales están repartidos en el servicio de Cloud Run, el gestor de secretos, el proyecto de Vercel, los secretos del repositorio y un archivo local en cada Pi. Ningún repositorio permite reconstruir un ambiente. Es el mayor riesgo de traspaso del sistema.
- No hay staging:
maindespliega a producción en los dos pipelines. Los previews de Vercel son lo más cercano, y apuntan a la API de producción. - Las migraciones de base se aplican a mano, y hay al menos dos donde el orden respecto del
despliegue del binario cambia el resultado, en las dos direcciones. (El binario también puede
aplicarlas al arrancar con
RUN_MIGRATIONS_ON_BOOT, apagado por defecto; no se sabe si producción lo usa. Ver despliegue.) - Tres cuentas personales, tres proveedores. El proyecto depende de accesos individuales, no de una organización. Crear la organización de GitHub y transferir los repositorios sigue pendiente.
- Escalar a cero implica latencia en la primera request después de un período de inactividad.
- Sigue existiendo una base de Postgres congelada en Koyeb, como respaldo. Una migración mal apuntada puede terminar ahí.
- No se sabe dónde corre MongoDB en producción. Ver contenedores C4.
Evidencia¶
- Despliegue de la API, con federación de identidad y despliegue por identificador de commit:
.github/workflows/deploy-cloud-run.yml - Despliegue del frontend con previews por rama:
.github/workflows/ci-cd.ymldel frontend - Despliegue manual en la Pi:
docs/pi.md - Orden de aplicación de migraciones:
migrations/README.md - Plataforma y proveedores actuales:
GOOGLE_CLOUD_GUIDE.md, guía operativa externa a los repositorios