## Por qué decidimos tener un registry in-house
En un principio, como muchos proyectos que crecen rápido, quisimos tener todo bajo control. Montamos un `registry:2` dentro de nuestros propios servidores — una instancia interna de *Docker Registry* que alojaba todas las imágenes de nuestros microservicios. Al comienzo funcionaba bien: control total, rapidez en red local, sin depender de nadie. Pero lo que parecía ideal, empezó a mostrar su lado menos amable cuando crecimos y nos acercabamos a la apertura de la Season 7, con ello el refresh completo de la comunidad y todos sus microservicios.
### El costo oculto de cada push
Cada imagen que subíamos tenía un costo asociado. Con la subida pasiva del dólar, cada build terminaba costando entre 0.10 y 0.15 USD por imagen mensual, considerando los layers y las distintas versiones generadas por entorno. Con **más de 10 microservicios** activos y builds constantes en *develop* y *main*, los costos de almacenamiento escalaron rápidamente. Y no solo era plata — también mantenimiento, limpieza de capas obsoletas, monitoreo del espacio, uptime del servicio y varias cosas más....
## Decisión: migrar a Docker Hub
Evaluamos varias alternativas externas como Cloudflare Registry, DigitalOcean Container Registry, el de AWS, GCP, el de github, bueno... varios realmente, pero finalmente optamos por Docker Hub, el servicio oficial y mejor documentado *(bajo mi punto de vista)*. La migración fue más sencilla de lo esperado gracias a nuestra integración con GitHub Actions.
Solo tuvimos que cambiar el `registry base`, las `credenciales` y ajustar algunos pasos del flujo de build. Desde ese momento, cada push comenzó a publicarse directamente en nuestro nuevo registry externo. Y sí... perdimos las versiones iniciales, pero que realmente eran despreciables versus el ahorro que nos estaba generando.
### Fragmento de nuestro flujo de GitHub Actions
Este es el bloque clave que permitió hacer el cambio casi sin fricción, ni deuda técnica:
```
- name: Login to Docker Hub
uses: docker/login-action@v3
with:
registry: ${{ env.REGISTRY }}
username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}
- name: Build & Push
uses: docker/build-push-action@v6
with:
context: .
push: true
platforms: linux/amd64
tags: ${{ steps.meta.outputs.tags }}
cache-from: type=gha
cache-to: type=gha,mode=max
```
Este bloque automatiza el build y publicación de cada imagen. Además, usamos metadatos y control de versiones por tags, lo que nos permite mantener builds consistentes en *develop* y *main* sin duplicar trabajo.
## Resultado: menos costos, más foco
Después del cambio, los costos se redujeron de inmediato. Dejamos de preocuparnos por la infraestructura y mantenimiento del registry, y pudimos dedicar ese tiempo y recursos a lo que realmente importa: mejorar la experiencia de nuestros jugadores y optimizar nuestros microservicios.\
Pasamos de gastar cerca de 70 USD mensuales (y en aumento) a mantener un costo fijo de aproximadamente 16 USD mensuales.
Nuestro sistema de despliegue interno sigue recibiendo las imágenes desde Docker Hub, asegurando un flujo CI/CD limpio y transparente.
## Qué aprendimos
- A veces, externalizar un servicio no es una pérdida de control, sino una ganancia de eficiencia (y de costos).
- Un par de centavos por imagen parecen poco, hasta que multiplicas por versiones, entornos y microservicios.
- Automatizar bien es clave: si tu pipeline está sólido, migrar es cuestión de minutos, no días... y esto nunca estuvo planificado, como dirían por ahí fue "un cueazo".
Esto nos reafirmó que en el Desarrollo, la optimización no siempre es técnica, hay veces que también es estratégica. Muchas de estas cosas quedan reservadas en algunos desarrolladores o administradores de comunidades y esto les puede permitir tomar decisiones que les puede ayudar a iniciar más rápido.
