GitHub vuelve a caerse: Mirrors, alternativas y cómo mantenerte online

Si últimamente intentaste hacer push de una rama, ejecutar un pipeline de CI o instalar un paquete y te encontraste con una página de error, no estabas solo. GitHub ha tenido más caídas y degradaciones de lo habitual, y para una plataforma en el centro del desarrollo de software moderno, cada minuto de Downtime lo siente toda la industria.

Este artículo no es un ataque. Antes que nada, es una nota de agradecimiento. Y después, como todos seguimos con trabajo que entregar, una guía práctica de alternativas a GitHub, Git Mirrors y cómo asegurarte de que la próxima caída no detenga tu proyecto — ni pase desapercibida para tus usuarios.

Gracias, GitHub

Es fácil olvidar cuánto cambió una sola plataforma. GitHub convirtió el hosting de código en una comunidad y, durante casi dos décadas, ha sido el hogar por defecto del open source. Algunas cosas que hoy damos por sentadas:

• Pull requests y code review social — el flujo de trabajo que toda una generación de developers aprendió en GitHub.
• Un hogar para millones de proyectos — desde experimentos de fin de semana hasta la infraestructura de internet.
• GitHub Actions, Pages y Packages — un toolchain completo que hacía sentir a los equipos pequeños enormes.
• Efectos de red — las estrellas, los issues, las discusiones y la cultura del README que hacían un placer descubrir software.

Nada de eso desaparece por unos malos días. Las caídas le pasan a todos; cuanto más exitosa es una plataforma, más gente siente su mal día. La reacción sana no es el enojo. Es la gratitud — más un plan B. Y de hecho, GitHub hace fácil seguir sus malos días a través de su propia página de status. Pero no deberías tener que revisarla tú mismo.

Qué se rompe realmente cuando GitHub se cae

github.com tiene un mal día, el radio de impacto es más grande de lo que crees:

• Clone, push y pull requests — lo básico diario se detiene.
• Pipelines de CI/CD (Actions) — los builds se encolan o fallan, los releases se retrasan.
• GitHub Pages — los sitios de documentación y marketing se apagan.
• Instalación de paquetes — las dependencias que obtienen de endpoints de GitHub empiezan a fallar.
• Webhooks e integraciones — los eventos se retrasan o se pierden, rompiendo silenciosamente la automatización.

Si tu proceso de release, tu documentación o tu producto toca alguno de estos puntos, tu Uptime ahora está acoplado al de GitHub. Es un riesgo que sí puedes reducir.

Git Mirrors: tu primera línea de defensa

Un Git Mirror es una copia completa y actualizada continuamente de tu repositorio en otro host. Un mirror no es una migración ni una protesta — es redundancia. Cuando GitHub tiene un mal día, tu historial, tus ramas y tus tags siguen vivos en otro lugar.

1. Elige un segundo hogar. GitLab, Codeberg o un Gitea o Forgejo auto-hospedado funcionan muy bien.
2. Empuja todo una vez: clona con git clone --mirror, luego ejecuta git push --mirror hacia el nuevo remote.
3. Manténlo sincronizado: o agregas un segundo remote (git remote add mirror <url>) y haces push a ambos, o ejecutas git push --mirror desde un job programado — una entrada cron por hora es suficiente para la mayoría de los equipos.
4. O deja que la copia se mantenga sola: GitLab, Gitea y Forgejo pueden crear pull-mirrors desde GitHub por programación, sin cron.
5. Verifica el mirror de vez en cuando. Un mirror que nunca pruebas es una falsa sensación de seguridad.

Un mirror no te da un segundo CI ni un seguimiento de issues, pero protege lo más valioso que tienes: tu código y su historial.

Alternativas a GitHub que vale la pena conocer

No tienes que dejar GitHub para prepararte para un día lluvioso. Conocer las alternativas — y mantener un mirror en alguna de ellas — es simplemente buena ingeniería. Cada una de estas plataformas se ha ganado una confianza real de la comunidad:

• GitLab — una plataforma DevOps completa con CI/CD integrado, container registry y mirroring de repositorios de primera clase en ambas direcciones. El plan B más natural para los equipos.
• Codeberg — una plataforma sin fines de lucro gestionada por la comunidad, impulsada por Forgejo. Un hogar genuinamente independiente para el software libre y open source.
• Sourcehut — minimalista, rápido y basado en email. Un enfoque refrescante y sin pretensiones del tooling de forges.
• Gitea y Forgejo — forges open source ligeros que puedes auto-hospedar. Control total, huella mínima, soporte de mirrors integrado.
• Bitbucket — la opción histórica de Atlassian con integración profunda de Jira.

El objetivo no es abandonar GitHub. Es poder decir, con la frente en alto, que nunca fuiste totalmente dependiente de él.

Desacopla lo que puedas

Los mirrors protegen tu código. Pero el Downtime más doloroso llega cuando todo lo demás depende del mismo host. Reparte la carga:

• Documentación y landing pages — no las sirvas solo desde GitHub Pages. Hospédalas como los sitios de producción que son.
• Paquetes — publica en más de un registry, por ejemplo npm más un registry privado o de una segunda plataforma.
• Releases — guarda los artefactos en tu propio storage o CDN además de los GitHub Releases.
• CI — un segundo pipeline en GitLab o en tus propios runners puede tomar el relevo cuando Actions está down.
• Badges y deep links — si tu README o tu sitio referencian raw.githubusercontent.com, trata esa URL como una dependencia y monitorea como tal.

Entérate antes que tus usuarios

Enterarte de una caída por redes sociales significa que llegaste tarde. La solución es aburrida pero eficaz: monitorea las cosas de las que dependes — GitHub mismo, tu sitio Pages, tus endpoints de clone y por supuesto tu propio producto.

Exactamente para eso construimos isthisthing.online. Agrega Monitors de HTTP, TCP o ping para cada salto entre tú y tus usuarios: github.com, api.github.com, tu URL de GitHub Pages y tus endpoints de producción. Los Checks corren desde hasta 10 ubicaciones globales en intervalos de hasta 30 segundos, y las alertas llegan a Slack, Microsoft Teams, Discord o cualquier lugar vía Webhooks en el momento en que algo se degrada.

Cuando GitHub se cae, tu Monitoring te dice en segundos si es GitHub o tu propio stack — así cambias a tu mirror, mueves un registro DNS o simplemente dejas de depurar la caída de otro.

Y cuando el mal día es tuyo, una Status Page que se actualiza automáticamente mantiene informados a tus usuarios en lugar de dejarlos refrescar tu bandeja de soporte.

Un checklist práctico de resiliencia

1. Crea un mirror de cada repositorio crítico y mantenlo sincronizado.
2. Agrega un segundo pipeline de CI a tus proyectos más importantes.
3. Publica paquetes y artefactos de release en más de un lugar.
4. No hospedes documentación ni páginas de marketing en una sola plataforma.
5. Monitorea github.com, api.github.com, tus URLs de Pages y tus propios endpoints con Checks rápidos.
6. Dirige las alertas a Slack, Teams o Discord para que las personas correctas se enteren primero.
7. Publica una Status Page pública para que tus usuarios nunca tengan que adivinar.
8. Ensaya el failover una vez, antes de necesitarlo de verdad.

GitHub construyó décadas de buena voluntad, y unas caídas no cambian eso. Mantente agradecido, mantente en mirror y mantente monitoreado.

¿Listo para la próxima caída? Crea tu cuenta gratis de isthisthing.online y convierte el próximo tropiezo de GitHub en una pausa de cinco minutos en lugar de una tarde perdida.