GitHub Developer Exodus 2026: ¿de verdad deberías irte?

Estaba a medio camino de revisar una solicitud de extracción cuando llegó la notificación X. Mitchell Hashimoto, el tipo que construyó Vagrant, Terraform y Ghostty, estaba retirando su proyecto de terminal de 50.000 estrellas de GitHub. Había sido el usuario 1299 de GitHub desde febrero de 2008. Había abierto el sitio, según sus propias cuentas, básicamente todos los días durante más de dieciocho años.

Leí su publicación dos veces. Luego cerré el PR que estaba revisando, abrí una nueva pestaña y comencé a escribir "GitHub alternatives 2026" en una barra de búsqueda en la que nunca pensé que escribiría esa frase.

La cuestión es que no soy Mitchell Hashimoto. No tengo un proyecto de 50k estrellas. No tengo influencia con múltiples "proveedores comerciales y de FOSS" dispuestos a hospedarme. Soy un ingeniero en activo con unos cuarenta repos activos en mejba.me, Ramlit Limited y un puñado de proyectos de clientes. Las matemáticas sobre si yo debería dejar GitHub no son las mismas matemáticas que las suyas.

Pero la pregunta se hizo tan ruidosa esta semana que no pude ignorarla. Así que pasé cuatro días analizando los números (en realidad probé GitLab, Codeberg y SourceHut con el workflows que ejecuto a diario) y lo que encontré me sorprendió. No porque uno de ellos sea obviamente mejor. No lo son. La sorpresa es lo que revela la comparación sobre en qué se ha convertido realmente GitHub en 2026, y el tipo específico de desarrollador que debería tomar medidas en este momento frente al tipo específico que debería quedarse quieto y simplemente adaptarse.

Esta es la publicación que desearía que alguien hubiera escrito antes de perder un domingo.

La semana que rompió la suposición de "GitHub es para siempre"

Ya conoces los titulares. Permítanme establecer un cronograma estricto, porque el orden importa más que los incidentes individuales.

23 de abril de 2026. Entre las 16:05 UTC y las 20:43 UTC, una regresión en la cola de combinación de GitHub produjo silenciosamente confirmaciones de combinación incorrectas cada vez que un grupo de cola contenía más de un PR usando el método de combinación squash. Según el propio incidente de GitHub, report, 2092 solicitudes de extracción en 230 repositories se vieron afectadas. El error no fue una falla de disponibilidad: las operaciones de Git siguieron funcionando, el API siguió devolviendo datos y la página de estado permaneció mayormente verde. El error fue que la corrección del compromiso se rompió. El código que los equipos pensaban que habían fusionado se revirtió mediante fusiones posteriores en la misma cola. A GitHub le tomó tres horas y treinta y tres minutos incluso darse cuenta, porque ningún monitor automatizado estaba observando si "la fusión realmente hizo lo que la fusión dijo que hizo".

Lea ese párrafo nuevamente si es necesario. Una plataforma de control de versiones dejó brevemente de rastrear versiones de manera confiable.

27 de abril de 2026. El clúster Elasticsearch de GitHub, el subsistema que impulsa las vistas de lista de PR, la búsqueda de problemas, los filtros del tablero de proyecto y la mayor parte de la interfaz de usuario en la que realmente haces clic, se vio abrumado. El CTO de GitHub lo describió públicamente como un ataque de botnet acumulado sobre el tráfico orgánico con el que el clúster ya estaba luchando. Durante horas, los datos subyacentes estaban bien, pero la interfaz que encuentra los datos mintió a los desarrolladores. La gente acusó a sus compañeros de equipo de eliminar trabajos que no habían sido eliminados. Los equipos realizaron reuniones asumiendo que los PR que no podían ver ya no existían.

28 de abril de 2026. Tres cosas sucedieron en un mismo ciclo de noticias. GitHub publicó una disculpa pública por la confiabilidad que llevó a la empresa a una postura de "Disponibilidad primero". Wiz Research reveló CVE-2026-3854: un RCE crítico CVSS 8.7 que permite a cualquier usuario autenticado lograr la ejecución remota de código en el backend de GitHub con un único git push, mediante la inyección de datos no desinfectados en el encabezado interno X-Stat. Y Mitchell Hashimoto publicó "Ghostty abandona GitHub".

Tres fracasos, tres capas diferentes de la pila, una semana. Esos son los datos.

Pero aquí está la parte que no cabía en la portada de Hacker News: El tiempo de actividad monitoreado por terceros de GitHub cayó por debajo del 90 % en 2025 y siguió cayendo hasta abril de 2026, alcanzando aproximadamente el 86 % durante el mes. AWS S3, por contexto, se ejecuta con un objetivo de diseño de "once nueves": 99,999999999%. La página de estado público de GitHub siguió afirmando que estaba por encima del 99% todo el tiempo. Esa brecha, entre lo que la página de estado reports y lo que realmente experimentaron los desarrolladores, es lo que erosiona la confianza más rápido que cualquier interrupción individual.

Cuando el desarrollador independiente más respetado en el mundo del código abierto dice que una plataforma "ya no es un lugar para trabajar seriamente", el resto de nosotros tenemos que al menos hacer los cálculos.

Lo que realmente probé (y el veredicto honesto)

Antes de comenzar con la comparación, esta es la regla que me di: no iba a evaluar ninguna plataforma desde su página de marketing. Migraría un proyecto real a cada uno, ejecutaría mi workflow real durante un día y anotaría lo que falló.

El proyecto que elegí fue un proyecto paralelo privado de Laravel con alrededor de 240 confirmaciones, acciones GitHub para CI, dos PR abiertos, tres hitos, doce problemas y un archivo CODEOWNERS. No es un juguete. Tampoco es un monstruo de 50.000 estrellas. Más o menos la forma de trabajo que realmente hacen la mayoría de los lectores de este sitio.

Esto es lo que pasó.

GitLab: La migración segura que no lo es del todo

GitLab es la primera parada obvia. Es la plataforma con la que lidera cada lista de "GitHub alternatives 2026", y la razón es simple: es el único competidor con una superficie de funciones comparable. CI/CD, seguimiento de problemas, registro de contenedores, registro de paquetes, escaneo de seguridad, todo incluido en un solo producto en lugar de estar integrado en acciones, paquetes, Dependabot y seguridad avanzada de GitHub.

Migré el proyecto Laravel a GitLab.com (el SaaS, no autohospedado) usando su importador integrado GitHub. Tiempo total desde hacer clic en "importar" hasta ver mi repo con todos los PR, problemas e hitos intactos: aproximadamente once minutos. El importador trajo:

Historial completo de Git (obviamente)
Problemas con etiquetas e hitos.
Solicitudes de extracción como solicitudes de fusión
Configuración CI/CD (con reescrituras: .github/workflows/*.yml no se ejecuta en GitLab; necesita un .gitlab-ci.yml)
Reglas de protección de sucursales (reaplicadas manualmente)
Webhooks (tuve que recrear)

La reescritura de CI fue el costo real. Mis acciones de GitHub workflow ejecutaron PHPUnit, ejecutaron Pint para formatear, ejecutaron un análisis estático a través de Larastan e implementaron un entorno de vista previa en un Hetzner VPS. Traducir eso a GitLab CI me tomó alrededor de noventa minutos, principalmente porque el bloque services: de GitLab para activar un contenedor MySQL es realmente mejor que el de GitHub, pero la sintaxis de rules: para trabajos condicionales es más detallada. No puedes copiar y pegar; tienes que pensar.

Lo que GitLab hace mejor que GitHub en este momento, punto, es la integración de DevOps propia. Si es una startup que quiere una plataforma para código, CI, registro de contenedores, registro de paquetes y escaneo de seguridad, y de lo contrario estaría ensamblando eso desde GitHub más otros tres proveedores, GitLab es la apuesta más segura. La historia todo en uno es real.

El problema, y este es el problema que nadie señala lo suficientemente alto, es que GitLab.com tuvo su propia interrupción significativa en 2025 y funciona con la misma presión de escala fundamental que GitHub. Migrar de un gran host SaaS Git a otro gran host SaaS Git porque le preocupa la confiabilidad es, caritativamente, una estrategia incompleta. Ha cambiado su único punto de falla, no lo ha eliminado.

La versión de GitLab que realmente soluciona el problema de confiabilidad es GitLab autohospedado, ya sea la Community Edition gratuita o el nivel Premium de pago. Esa es una conversación diferente. Ese es un trabajo de administrador de sistemas. Se trata de un servidor que necesita parches, copias de seguridad, un certificado SSL, una retransmisión SMTP y un runbook para el día en que se caiga a las 2 de la madrugada. Si trabaja solo o en un equipo pequeño, el costo operativo generalmente supera la ganancia en confiabilidad.

Veredicto de GitLab: Un competidor genuino de GitHub en cuanto a funciones. Un competidor cuestionable de GitHub en cuanto a confiabilidad si permanece en GitLab.com. Una verdadera apuesta por la confiabilidad sólo es posible si realiza el autohospedaje, y el autohospedaje es un trabajo, no una casilla de verificación.

Codeberg: El que me sorprendió

Codeberg es la plataforma que esperaba descartar en veinte minutos. Salí del examen tomándolo más en serio que cualquier otra cosa que evalué.

Contexto rápido: Codeberg es una organización sin fines de lucro alemana que ejecuta una instancia de Forgejo, una bifurcación suave de Gitea gobernada por la comunidad. No hay inversores, ni anuncios, ni hoja de ruta corporativa, ni características de AI atornilladas a la parte superior, ni aumento "agente de workflow" que infle artificialmente la carga. Está financiado por donaciones. Su filosofía es explícita: ser un hogar seguro para el software gratuito y de código abierto. Está alojado en la UE bajo una fundación, lo cual es de gran importancia si tienes exposición a GDPR.

Importé el proyecto Laravel, bueno, una bifurcación pública. Los propios términos de Codeberg le piden alojar principalmente trabajo fuente gratuito de /open, que es el límite correcto para una organización sin fines de lucro financiada por donaciones. La importación tardó unos siete minutos. La interfaz es inequívocamente "GitHub circa 2018", y lo digo como un cumplido. Vista PR, vista de problemas, vista de hitos, búsqueda de códigos, todo inmediatamente legible. No hay sugerencias de AI. Sin ventas adicionales de Copilot. No hay un feed de "exploración" diseñado para mantenerte en el sitio.

El sistema CI de Forgejo, Forgejo Actions, es compatible con API y GitHub Actions. Mi .github/workflows/ci.yml se ejecutó con dos ajustes menores: una etiqueta de ejecutor renombrada y una acción que había estado extrayendo del mercado GitHub tuvo que ser reemplazada por una equivalente publicada en el propio registro de acciones de Codeberg. Unos cuarenta y cinco minutos de trabajo para volverse ecológico.

Aquí está la parte que me hizo sentarme. La semana del 23 al 28 de abril, mientras GitHub estaba visiblemente luchando, la página de estado de Codeberg mostraba operaciones normales en todos los componentes. Esa no es una afirmación de alardear, es una ventaja estructural. Codeberg no es un objetivo para las mismas botnets en la misma escala, no está siendo atacado por la misma carga agente AI workflow, no está tratando de escalar su infraestructura 30 veces para mantenerse al día con el tráfico sintético. La plataforma es lo suficientemente pequeña como para seguir siendo confiable de una manera que los gigantes no lo son actualmente.

Los límites honestos: Codeberg no está diseñado intencionalmente para trabajos propietarios de código cerrado. Los minutos de CI disponibles son conservadores porque alguien está donando para mantenerlos. No existe un gráfico social al estilo de LinkedIn que impulse el descubrimiento. Si la estrategia de crecimiento de su proyecto depende de la página "Tendencias" de GitHub, no puede replicarla aquí.

Veredicto de Codeberg: Si envía software de código abierto, especialmente en la UE, especialmente como individuo o equipo pequeño, este es el objetivo de migración más subestimado en 2026. No es un reemplazo de GitHub. Es algo mejor en las dimensiones específicas en las que GitHub ha dejado de ser bueno: silencioso, confiable, propiedad de la comunidad a la que sirve.

SourceHut: El diseñado para el ingeniero que probablemente no seas

SourceHut es la plataforma más obstinada que probé. Drew DeVault lo construyó sobre una tesis clara: la mayor parte de lo que hace que el alojamiento Git moderno sea "poderoso" es en realidad ruido, y un workflow basado en correo electrónico y sin JavaScript es más rápido para el desarrollo de software serio que cualquier alternativa con mucha interfaz de usuario. El precio comienza gratis; los niveles pagos cuestan aproximadamente entre $ 20 y $ 50 /year, según el uso.

Voy a ser honesto contigo. Importé el proyecto Laravel, ejecuté workflow durante un día y lo abandoné alrededor de la hora seis.

No porque SourceHut sea malo. Debido a que SourceHut está diseñado para un workflow, en realidad no lo ejecuto. La revisión del código en SourceHut se realiza a través de listas de correo y git send-email. El seguimiento de errores se realiza a través de un rastreador que es deliberadamente espartano. CI se ejecuta a través de builds.sr.ht y es realmente rápido y limpio. Pero el delta cultural (pasar de la revisión basada en PR a la revisión parche por correo electrónico) es enorme. A los mantenedores del kernel de Linux les encanta. La mayoría de nosotros, incluido yo mismo, hemos desarrollado una década de memoria muscular al hacer clic en "Aprobar" en una interfaz web.

La plataforma en sí está impecablemente diseñada. Cada página se procesa en menos de un segundo. No hay ningún JavaScript en ninguna parte. La transparencia del mantenedor sobre los costos y las decisiones de infraestructura es algo que nadie más en este espacio iguala. Si eres el tipo de desarrollador que ejecuta mutt para correo electrónico y considera un botón de interfaz de usuario un insulto personal, SourceHut es la plataforma que finalmente recompensa tu estética.

Veredicto de SourceHut: No es una alternativa a GitHub para la mayoría de los equipos. Un paradigma diferente para el subconjunto específico de desarrolladores que realmente quieren parches por correo electrónico workflows. Respeta la filosofía, pero sé honesto acerca de si realmente eres ese ingeniero.

Las matemáticas de la migración que nadie te muestra

Aquí es donde quiero romper con cada lista de "principales alternativas a GitHub" que haya leído esta semana.

La mayoría de ellos se detienen en la comparación de funciones. La comparación de funciones es la parte fácil. La comparación de funciones no captura el costo real de abandonar GitHub, y si no valora ese costo honestamente, migrará cuando no debería o se quedará cuando no debería.

Aquí están las verdaderas matemáticas.

Lo que GitHub realmente le ofrece más allá del hosting

Cuando hospedas en GitHub, no estás pagando para que git push funcione. git push funciona en un VPS de $5 con un repo simple y una clave SSH. Estás pagando (explícitamente con dólares de suscripción, implícitamente con tus datos) por una pila interconectada de servicios, la mayoría de los cuales no tienen reemplazo en Codeberg, SourceHut o incluso GitLab.

Descubrimiento y contribuyentes entrantes. La página "Tendencias", el gráfico de exploración, la prueba social de estrellas y bifurcaciones, la búsqueda nativa GitHub que permite que un extraño encuentre su proyecto: estos son activos comerciales enormes para cualquier mantenedor de código abierto, y no migran. Mitchell Hashimoto puede mover Ghostty de GitHub porque Ghostty ya es famoso. Un nuevo proyecto que intenta construir una audiencia no puede.

CI/CD ubicuidad. GitHub Actions se ha convertido en el objetivo de integración de implementación de facto para cada proveedor de nube, cada registro de paquetes y cada herramienta de lanzamiento. AWS publica acciones. Cloudflare publica Acciones. Vercel publica Acciones. Replicar esa superficie de integración en otros lugares no es imposible, pero rara vez es llave en mano.

El ecosistema del mercado. Acciones de terceros, aplicaciones GitHub, la capa de integraciones: nada de esto existe con la misma densidad en ningún otro lugar. Si su workflow depende de cinco acciones del mercado, migrar significa reconstruir o reemplazar cinco integraciones.

Reclutamiento e identidad. Tu perfil GitHub es, para muchas empresas, tu currículum. Tu gráfico de contribución es una credencial. Su nombre de usuario es una marca. Nada de eso se transfiere claramente a una nueva plataforma, y el efecto de red solo fluye en una dirección.

La hoja de trabajo sobre costos de migración

Aquí está la hoja de trabajo que desearía haber tenido el domingo por la mañana. Ejecute su proyecto antes de tomar cualquier decisión de cualquier manera.

1. Tiempo de migración del repositorio. Para un proyecto con menos de 500 confirmaciones y problemas estándar/PRs: ~30 minutos por repo solo para la importación. Multiplique por su recuento repo.

2. Tiempo de reescritura de CI. GitHub Acciones para GitLab CI: presupuesto de 1 a 3 horas por workflow no trivial. Acciones de GitHub para acciones de Forgejo en Codeberg: presupuesto de 30 a 90 minutos por workflow. GitHub Acciones para compilaciones SourceHut: presupuesta medio día por workflow si nunca antes has escrito uno.

3. Webhook y recableado de integración. Cada servicio externo que se publica en su repo (Slack, Discord, enlaces de implementación, comprobaciones de estado) necesita reconfigurarse. Presupuesta 15 minutos por integración, más si el formato del webhook de la nueva plataforma es diferente.

4. Protección de sucursales y permisos de equipo. Nada de esto se migra automáticamente. Auditar y recrear. Presupuesta aproximadamente 2 horas para una configuración de equipo típica.

5. Actualizaciones de documentación. Cada insignia de README, cada enlace wiki, cada documento externo que diga "encuéntrenos en GitHub". Este es el trabajo poco glamoroso que lleva más tiempo de lo que piensas.

6. El costo del contribuyente. Si tiene contribuyentes externos, ellos también tienen que migrar. Algunos no lo harán. Perderá algo de velocidad de contribución durante al menos el primer trimestre posterior a la migración. Incluya eso en su decisión.

7. El costo de reclutamiento y visibilidad. Si su proyecto gana contribuyentes a través del descubrimiento, el efecto de red de GitHub es parte de su estrategia de crecimiento. Irse significa reconstruir ese oleoducto en algún lugar con efectos de red más débiles.

Para mi configuración personal/work de cuarenta repo, mi estimación honesta para dejar GitHub por completo fue de aproximadamente 60 horas de trabajo de ingeniería enfocado más una cola de varios meses de pequeñas reparaciones. Ese es un número real. Una fracción significativa de la productividad de un trimestre, cambiada por una cantidad desconocida de confiabilidad futura.

Para una startup con veinte ingenieros, multiplique eso por la cantidad de repos e integraciones y verá un proyecto de meses de duración con un costo de oportunidad real. Para un proyecto público de 50.000 estrellas como Ghostty, es aún más grande, excepto que Hashimoto tiene la influencia para negociar con los proveedores y la marca para mantener a los contribuyentes prestando atención durante la transición.

Para la mayoría de los lectores de esta publicación: el costo de la migración es mayor que el costo de confiabilidad de permanecer durante la recuperación de GitHub, a menos que se cumpla una de tres condiciones específicas.

Cuándo debería migrar realmente (y cuándo no)

Después de ejecutar los cálculos en workflows real, este es el marco que estoy usando personalmente y recomendando a los clientes.

Migra ahora si:

Su trabajo depende de la corrección de la cola de fusión para monorepos de alta velocidad. El incidente del 23 de abril rompió específicamente la corrección de la confirmación en las colas. Si su equipo fusiona docenas de PR por día a través de colas automatizadas y no puede tolerar ni siquiera una pequeña probabilidad de reversiones silenciosas, la brecha de confianza es demasiado grande para esperar. Los trenes de fusión de GitLab o una alternativa autohospedada son coberturas razonables.

Tiene exposición a GDPR o requisitos de soberanía de datos de la UE y ha estado tratando "GitHub está bien para esto" como una suposición de trabajo que en realidad no ha examinado. Codeberg o Forgejo autohospedado en infraestructura de la UE aclara su historia de cumplimiento de una manera que GitHub ahora complica activamente.

Usted ejecuta GitHub Enterprise Server. Este es el caso en el que realmente creo que debería actuar hoy, no el próximo trimestre. CVE-2026-3854 afectó aproximadamente al 88 % de las instancias de GHES en el momento de la divulgación. Si aún no ha actualizado a GHES 3.19.3 o posterior, ese es su primer paso, independientemente de cualquier pregunta sobre la migración. La cadena RCE (inyectar un rails_env falso, redirigir el directorio de enlaces, colocar un enlace de pre-recepción, obtener la ejecución del código como usuario de git) es lo suficientemente sencilla como para que la explotación en la naturaleza sea una cuestión de cuándo, no de si.

Quédate (con ajustes) si:

Es un desarrollador en solitario o un equipo pequeño que ejecuta workflows estándar basado en PR en repos público para mayor visibilidad. El costo de la migración es real, el costo de descubrimiento es grande y la mayoría de las fallas recientes de GitHub en realidad no han roto Git. Han roto la capa de interfaz de usuario que encuentra tu trabajo. La medida correcta es protegerse contra fallas en la capa de la interfaz de usuario (use gh CLI, cree scripts en la interfaz de usuario web, refleje repos crítico en otro lugar como copia de seguridad en frío) en lugar de una migración completa.

Su negocio depende de integraciones nativas de GitHub como Copilot, Seguridad avanzada o acciones de mercado específicas que no puede reemplazar fácilmente. Valorar honestamente la pérdida de integración a menudo lleva a "migrar" a "todavía no".

Estás ejecutando un proyecto cuyo crecimiento depende del descubrimiento de los contribuyentes entrantes. Estás utilizando el efecto de red de GitHub incluso si no lo piensas de esa manera. No le subestimes el precio.

La obra híbrida que en realidad estoy haciendo.

Por mi propio trabajo, no voy a migrar. Estoy reflejando. Cada repo mío que importa ahora tiene un espejo nocturno automatizado en una cuenta privada Codeberg. Si GitHub tiene otra mala semana, tengo una segunda copia funcional. Si GitHub nunca vuelve a tener otra mala semana, dediqué aproximadamente tres horas a la automatización del espejo y obtuve una copia de seguridad fuera de la plataforma, lo cual es una buena práctica de todos modos.

La configuración consta de aproximadamente treinta líneas de bash más un trabajo cron. Codeberg acepta envíos desde cualquier cliente Git estándar, por lo que la configuración del espejo es idéntica a la de cualquier otro control remoto. Estoy usando git push --mirror según una programación, con las credenciales en una bóveda separada de mis credenciales GitHub. Todo esto es el tipo de redundancia de bajo riesgo que desearías haber construido antes de necesitarla. (Si ya ha invertido en un Claude Code workflow para desarrollo basado en terminal, conectarlo como un trabajo en segundo plano programado es una tarea de 20 minutos).

Lo que esto dice sobre hacia dónde se dirige la infraestructura para desarrolladores

Quiero cerrar con la parte que es más grande que cualquier plataforma individual.

El CTO de GitHub describió la curva de carga que llega a la plataforma como "desarrollo agente workflows" que llega "como un buffet libre". Esa frase se me ha quedado grabada toda la semana. No se equivoca. Cada agente Claude Code, cada ejecución de Codex, cada trabajo en segundo plano del cursor, cada canalización autónoma que usted y yo ejecutamos en 2026 llega al API de GitHub más de lo que lo haría un humano. Somos, colectiva y accidentalmente, la carga que lo rompió.

La arquitectura GitHub que se ejecutaba en 2024 tenía el tamaño adecuado para desarrolladores humanos. La arquitectura que necesita en 2026 está dimensionada para agentes y humanos, y la brecha entre esos dos números resulta ser aproximadamente 30 veces mayor. Ese es el objetivo de ampliación con el que la empresa se ha comprometido públicamente. Es un enorme proyecto de ingeniería. Si lo alcanzaron en doce meses o en treinta y seis es la cuestión real que determina si los incidentes de abril de 2026 fueron un punto crítico de transición o el comienzo de un declive más largo.

Lo que también es cierto es que el mismo aumento agente workflow que cambia la curva de carga de GitHub está cambiando lo que los desarrolladores valoran en un host Git. Nos preocupamos más por la confiabilidad de API que por el pulido de la interfaz de usuario, más por el acceso programático que por las funciones sociales, más por los costos predecibles que por las listas de funciones empresariales. Codeberg y SourceHut, por accidente o por diseño, se crearon para esa audiencia años antes de que la audiencia existiera a escala. Su momento es ahora. Si está construyendo agentes AI que afectan el control de versiones API continuamente, el host que elija es una decisión de carga que no lo era hace dos años.

De lo que estoy más seguro, después de esta semana: la era en la que "GitHub" era sinónimo de "dónde vive el código" está llegando a su fin. No porque GitHub esté colapsando: Microsoft tiene el capital, los ingenieros y las razones estratégicas para solucionar este problema. Sino porque la suposición de la inevitabilidad ha desaparecido. Hemos visto al desarrollador en solitario más visible en código abierto hacer las maletas y marcharse. Hemos visto a la propia empresa admitir públicamente que su tiempo de actividad es inferior al 86%. El valor predeterminado se ha resquebrajado, y un valor predeterminado resquebrajado es un tipo diferente de valor predeterminado.

No tienes que irte. No me voy. Pero volver sonámbulos a la suposición de que GitHub es la única opción seria para alojar código en 2026 es algo que ninguno de nosotros puede hacer ya. La cuestión finalmente vuelve a estar sobre la mesa, y eso, más que cualquiera de los incidentes individuales, es lo que cambió este mes.

Así que aquí está la tarea. En algún momento dentro de los próximos siete días, establezca un cronómetro de una hora. Elija la hoja de trabajo de anteriormente en esta publicación. Ejecútelo en un proyecto suyo que realmente importe. Sólo uno. Descubra cuál sería el costo de migración real para usted, en su código, con sus integraciones.

Probablemente no te muevas. Pero nunca más estará en la posición de tener que tomar esta decisión en condiciones de pánico, como terminaron haciendo la mitad de los gerentes de ingeniería con los que hablé esta semana. Esa es la verdadera victoria. No la migración. La claridad.

Preguntas frecuentes

¿GitHub está inactivo en este momento?

GitHub está disponible de forma general, pero ha estado funcionando por debajo de sus objetivos de confiabilidad históricos: el monitoreo de terceros situó el tiempo de actividad en abril de 2026 en alrededor del 86 %, muy por debajo de la narrativa de la página de estado de la plataforma. Los incidentes específicos del 23 de abril (corrupción en la cola de fusión) y el 27 de abril (interrupción de la búsqueda en Elasticsearch) provocaron interrupciones de varias horas. Para conocer el estado en tiempo real, consulte monitores de terceros en lugar de la página de estado oficial.

¿GitLab es realmente más confiable que GitHub?

No categóricamente. GitLab.com se ejecuta con la misma presión de escalamiento de SaaS que GitHub y tuvo sus propias interrupciones importantes en 2025. GitLab es más confiable que GitHub solo si usted mismo se hospeda, lo que intercambia ganancias de confiabilidad por el costo operativo de ejecutar su propio servidor. Para la mayoría de los equipos, cambiar de proveedor de SaaS no resuelve la cuestión subyacente de la confiabilidad.

¿Qué es Codeberg y es una alternativa real a GitHub?

Codeberg es una organización sin fines de lucro alemana que administra Forgejo, una plataforma Git gobernada por la comunidad. Es una alternativa real para proyectos gratuitos y de código abierto, especialmente con las necesidades de soberanía de datos de la UE. Intencionalmente no es apto para trabajos propietarios de código cerrado. CI es compatible con API con acciones GitHub, y la plataforma permaneció en pleno funcionamiento durante los incidentes de abril de 2026 de GitHub.

¿Debo migrar mi repos privado de GitHub ahora mismo?

Probablemente no, a menos que se encuentre en uno de estos tres grupos: monorepos de alta velocidad dependiendo de la corrección de la cola de fusión, requisitos de soberanía GDPR/EU o instancias de GitHub Enterprise Server que aún no han parcheado CVE-2026-3854. Para la mayoría de los desarrolladores individuales y equipos pequeños, el costo de la migración supera el costo de confiabilidad actual. Un movimiento intermedio más inteligente es reflejar el repos crítico en un segundo host como respaldo en frío.

¿Qué es CVE-2026-3854 y me afecta?

CVE-2026-3854 es una vulnerabilidad de ejecución remota de código CVSS 8.7 divulgada por Wiz Research el 28 de abril de 2026, explotable por cualquier usuario autenticado a través de un único git push con opciones de inserción diseñadas. GitHub.com fue parcheado en marzo de 2026; no es necesario realizar ninguna acción para los usuarios de la nube. Los usuarios de GitHub Enterprise Server deben actualizar a GHES 3.19.3 o posterior; Se estima que el 88% de las instancias de GHES todavía eran vulnerables en el momento de su divulgación.

Trabajemos juntos

¿Quiere crear sistemas AI, automatizar workflows o ampliar su infraestructura tecnológica? Me encantaría ayudar.

Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
Cartera: mejba.me
Ramlit Limited (soluciones empresariales): ramlit.com
ColorPark (diseño y marca): colorpark.io
xCyberSecurity (servicios de seguridad): xcybersecurity.io