SaaS multi-tenant en Cloud Run

Llevé a producción una plataforma SaaS B2B multi-tenant en Google Cloud, con escalado a cero, datos sin exposición a internet y un despliegue que cabe en un solo comando.

El punto de partida

Una aplicación SaaS real tiene tres frentes vivos a la vez: un panel web, una API de negocio y procesos en segundo plano (envíos, recordatorios, programaciones).

Quería llevar eso a producción con un coste ajustado y sin un equipo de plataforma dedicado. Eso obliga a apoyarse en servicios gestionados y a automatizar el build y el despliegue.

Qué hice

Diseñé y desplegué una arquitectura serverless, observable y reproducible. Los requisitos eran cuatro: escalado a cero en reposo, conexiones de datos privadas, secretos fuera del código y un flujo de despliegue repetible para la API, la web y la landing.

Cómo lo hice

Servicios gestionados

API y web corren en Cloud Run. Los datos van en Cloud SQL (PostgreSQL) y la caché y las colas en Memorystore (Redis, con TLS obligatorio). Los ficheros se sirven desde Cloud Storage con signed URLs temporales, y la landing va aparte en Firebase Hosting.

Datos privados

Cloud Run se conecta a Cloud SQL por socket Unix a través del Cloud SQL Auth Proxy, nunca por IP pública. Para Memorystore usé Direct VPC egress con private-ranges-only, sin enrutar todo el tráfico por la VPC ni añadir un connector serverless.

Contenedores y secretos

Las imágenes son Dockerfiles multi-stage, etiquetadas por git SHA y latest, así que cada revisión es trazable a un commit. La API aplica las migraciones de Prisma al arrancar. Los secretos viven en Secret Manager como NOMBRE=SECRETO:latest: rotar uno es publicar una versión nueva.

Tenants y colas

El tenant se resuelve por subdominio: un proxy reescribe el Host y cada modelo y endpoint lleva tenantId. Los trabajos en segundo plano corren con BullMQ dentro del proceso de la API, lo que ahorra un servicio mientras el volumen lo permita.

Resultado

La plataforma está en producción con dominios propios, TLS gestionado y un coste en reposo casi nulo gracias al escalado a cero.

• Cada servicio (API, web, landing) se despliega de forma reproducible y trazable a un commit.
• Datos y caché no tienen exposición directa a internet, y los secretos están centralizados.
• La capa de IA (Vertex AI) se autentica con la service account del servicio, sin gestionar claves.
• La imagen de la API ocupa ~164 MB y la de la web ~92 MB, con modo standalone de Next.js.

Qué me llevo

Escalar a cero tiene un precio: un cold start de ~2-3 s, que aquí era asumible. Meter el worker dentro de la API sigue la misma lógica: simplificar ahora y dejar la puerta abierta a separarlo cuando haga falta escalar.

Arquitectura

build multi-stage → Artifact Registry → Cloud Run (API + web) → Cloud SQL por socket · Memorystore por VPC · Secret Manager · Cloud Storage