Desplegando en Google Cloud Run: migración desde Railway

Por qué migré el backend de Amaris desde Railway a Google Cloud Run, qué es Docker y Artifact Registry, cómo desplegar backend y frontend, y las consideraciones de costos

Edgardo Silva
google-cloudcloud-rundockerartifact-registrydevopsrailway

Cuando empecé a desarrollar Amaris, usé Railway para el backend. Conectas el repo, Railway detecta el código y despliega. Funciona bien para empezar. El problema llegó cuando revisé la factura: $10 al mes por un servidor corriendo las 24 horas aunque Amaris recibiera pocas visitas. Con Cloud Run, el backend se apaga cuando no hay tráfico y arranca en segundos cuando llega una request. El resultado: $0 al mes dentro de la capa gratuita.


En este post cuento por qué migré, cómo funciona el stack de GCP (Docker, Artifact Registry, Cloud Run), los pasos para desplegar el backend, y qué considerar al elegir dónde desplegar el frontend.


Conceptos importantes

  • ¿Qué es Google Cloud Run?
    Un servicio serverless que ejecuta contenedores. Solo entrego una imagen Docker y Google se encarga del resto: escalado, sistema operativo, actualizaciones. Cuando no hay requests, escala a cero — el costo es cero.

  • ¿Qué es Docker?
    Una herramienta para empaquetar una aplicación junto con todo lo que necesita — Node.js, dependencias, configuración — en una unidad portable llamada contenedor. El contenedor se comporta igual en cualquier ambiente. Para Cloud Run, Docker es obligatorio.

  • ¿Qué es Artifact Registry?
    El almacén de imágenes Docker de Google Cloud. Cloud Run no sabe compilar código fuente, solo ejecutar imágenes. Artifact Registry es el intermediario donde viven esas imágenes antes de ser desplegadas.

  • ¿Qué es Secret Manager?
    Un servicio de GCP para guardar credenciales sensibles — contraseñas de base de datos, tokens, claves de API — de forma segura y centralizada. En lugar de poner esos valores en el código o en variables de entorno del deploy, Secret Manager los almacena cifrados y Cloud Run los inyecta al contenedor en tiempo de ejecución.

Paso a paso

↓
↓
↓
↓
↓
↓

*Imágenes de referencia, generadas por IA


Variables de entorno y secrets

Las credenciales sensibles van en Secret Manager, no en el comando de deploy:

# Crear el secret
echo -n "postgresql://usuario:password@host:5432/db" | \
  gcloud secrets create DATABASE_URL --data-file=- --project=mi-proyecto

# Referenciar el secret en el deploy
gcloud run deploy mi-app --update-secrets DATABASE_URL=DATABASE_URL:latest

Cloud Run inyecta el valor como variable de entorno al momento de arrancar el contenedor.

Costos reales

Cloud Run cobra por uso real. Los tres factores son:

FactorCapa gratuitaPrecio después
Requests2 millones/mes$0.40 por millón
CPU180,000 vCPU-segundos/mes$0.000024 por vCPU-segundo
Memoria360,000 GB-segundos/mes$0.0000025 por GB-segundo

Para un proyecto con tráfico bajo, la capa gratuita alcanza. Yo no he pagado nada desde que migré.

Las flags clave para controlar el costo en el deploy:

  • --min-instances 0 — activa el scale-to-zero
  • --max-instances 1 — evita escalado inesperado
  • --cpu 0.5 y --memory 512Mi — suficiente para una API Node.js liviana

Conclusión

La migración valió la pena. Pasé de pagar ~$10 al mes en Railway a $0 en Cloud Run para el backend, y el frontend en Vercel también es gratuito dentro de su capa free.

La curva es entender Docker y el stack de GCP (Artifact Registry, Secret Manager). Una vez hecho el primer deploy, el proceso es claro y repetible.