Despliegue de Rebase en Google Cloud Platform

Google Cloud Platform (GCP) ofrece una experiencia de desarrollo fluida para aplicaciones contenerizadas. Para una configuración de producción robusta, utiliza Cloud SQL para la base de datos y Cloud Run para el entorno de ejecución.

Para mantener un cumplimiento estricto de los datos europeos, opera completamente dentro de una región de la UE como europe-west3 (Fráncfort), europe-west9 (París) o europe-west1 (Bélgica).

Nada en esta página es específico de GCP con respecto a tu proyecto. Un despliegue de Rebase consta de dos partes separables: la imagen de runtime publicada y el bundle que genera rebase build; y el mismo bundle se ejecuta bajo Docker Compose en un ordenador portátil, en Rebase Cloud, bajo el Helm chart y aquí.

1. Aprovisionar Cloud SQL (PostgreSQL)

Navega a la consola de Cloud SQL en tu región preferida de la UE.
Haz clic en Create Instance y selecciona PostgreSQL.
Define tu Instance ID y genera una contraseña segura para el usuario postgres.
Despliega Configuration Options para elegir un tipo de máquina (dos vCPU es un buen punto de partida).
Configura una IP privada o una red pública autorizada, dependiendo de cómo accederá Cloud Run a ella.
Ensambla tu URI de conexión: postgresql://postgres:YOUR_PASSWORD@YOUR_IP:5432/postgres

Si tus colecciones declaran una propiedad vector, habilita la extensión una vez: CREATE EXTENSION vector; en la base de datos.

2. Compilar el bundle e integrarlo en una imagen

No hay ninguna imagen de aplicación que compilar a partir de tu código fuente. rebase build genera un directorio dist-bundle con tus colecciones compiladas, funciones, tareas cron y —si tu proyecto declara una aplicación estática— tu frontend compilado. La imagen de runtime publicada lo ejecuta:

rebase build

Cloud Run descarga desde un registro, así que integra el bundle en una imagen derivada. Tres líneas, y fija exactamente lo que se ejecuta:

FROM rebasepro/server:0.24.0
COPY dist-bundle /bundle

# Set your active GCP project
gcloud config set project YOUR_PROJECT_ID

# Create an Artifact Registry repository (one-time)
gcloud artifacts repositories create rebase --repository-format=docker --location=europe-west3

# Authenticate Docker to Artifact Registry (one-time)
gcloud auth configure-docker europe-west3-docker.pkg.dev

# Build from the project root and push
docker build -t europe-west3-docker.pkg.dev/YOUR_PROJECT_ID/rebase/backend:latest .
docker push europe-west3-docker.pkg.dev/YOUR_PROJECT_ID/rebase/backend:latest

Actualizar Rebase más adelante consiste simplemente en cambiar esa línea FROM. Tu bundle no se modifica.

3. Desplegar en Cloud Run

gcloud run deploy rebase-backend \
  --image europe-west3-docker.pkg.dev/YOUR_PROJECT_ID/rebase/backend:latest \
  --region europe-west3 \
  --set-env-vars NODE_ENV="production",CORS_ORIGINS="https://yourdomain.com",FRONTEND_URL="https://yourdomain.com",DISABLE_SELF_REGISTRATION="true",REBASE_ADMIN_EMAIL="you@yourdomain.com" \
  --set-secrets DATABASE_URL=rebase-database-url:latest,JWT_SECRET=rebase-jwt-secret:latest,REBASE_SERVICE_KEY=rebase-service-key:latest,REBASE_ADMIN_PASSWORD=rebase-admin-password:latest \
  --allow-unauthenticated

Cloud Run inyecta PORT y el runtime se vincula a él, por lo que no hay ningún puerto que configurar. Apunta la sonda de inicio (startup probe) a /livez en lugar de /health: la segunda realiza un viaje de ida y vuelta a la base de datos, por lo que una sonda de liveness sobre ella reiniciaría una revisión en buen estado durante un breve fallo temporal de la base de datos.

REBASE_ADMIN_EMAIL y REBASE_ADMIN_PASSWORD son la forma en que este servicio obtiene un administrador: en producción, la primera cuenta que se registra no se promociona, por lo que nada más genera el primer usuario autenticado. Configúralos antes de que la primera revisión empiece a servir tráfico; consulta Tu primer admin.

--set-env-vars reemplaza el bloque de entorno completo en cada despliegue, por lo que un despliegue posterior que omita una variable la desconfigurará de forma silenciosa. Mantén la lista completa en tu script de despliegue.

Para acceder a una instancia privada de Cloud SQL se necesita --add-cloudsql-instances YOUR_PROJECT:REGION:INSTANCE y una DATABASE_URL con formato de socket; una instancia pública con una red autorizada no necesita ninguna de las dos.

4. El esquema

El runtime crea las tablas faltantes al iniciar, incluidas las de tus colecciones. REBASE_MIGRATE_ON_BOOT tiene por defecto el valor ensure, el cual es aditivo en todo el esquema: crea las tablas, columnas y tipos enum faltantes y aplica su seguridad a nivel de fila (RLS), de modo que el primer arranque con una instancia vacía empieza sirviendo tus colecciones.

Lo que ensure nunca hace es modificar algo que ya existe: no altera el tipo de una columna, no elimina nada ni edita las etiquetas de un enum existente, ya que el inicio de una revisión no debe remodelar un esquema como efecto secundario de un despliegue.

Por lo tanto, todavía queda una cosa que requiere la CLI, ejecutada desde un repositorio clonado o un trabajo de CI:

rebase db push

Cualquier cambio que no sea puramente aditivo: una columna renombrada, un tipo más restrictivo, un campo eliminado.

Desde tu equipo, conéctate mediante el Cloud SQL Auth Proxy y apunta DATABASE_URL a localhost. La imagen del runtime se distribuye sin la CLI, por lo que esto nunca se ejecuta dentro del contenedor de Cloud Run. Para migraciones versionadas, haz commit de los archivos de migración con rebase db generate y ejecuta rebase db migrate como un paso de release en su lugar.

Almacenamiento de archivos

Las instancias de Cloud Run son sin estado (stateless) y efímeras, por lo que el almacenamiento de archivos local supone una pérdida de datos silenciosa y el runtime lo rechaza en producción.

Crea un bucket privado de Google Cloud Storage en tu región de la UE elegida.
Configura STORAGE_TYPE=gcs y su bucket; consulta Almacenamiento. En Cloud Run, la cuenta de servicio del entorno suministra las credenciales, por lo que no hay nada más que configurar.

Próximos pasos

Despliegue — la lista de verificación de producción y las reglas del primer administrador que comparten todas las plataformas.
Configuración — cada variable de entorno que lee el runtime.