GitHub Developer Exodus 2026: você realmente deveria sair?
Eu estava na metade da revisão de uma solicitação pull quando a notificação X chegou. Mitchell Hashimoto - o cara que construiu o Vagrant, Terraform e Ghostty - estava retirando seu projeto de terminal de 50.000 estrelas do GitHub. Ele era o usuário 1299 do GitHub desde fevereiro de 2008. Ele abriu o site, segundo suas próprias contas, basicamente todos os dias por mais de dezoito anos.
Li o post dele duas vezes. Então fechei o PR que estava revisando, abri uma nova guia e comecei a digitar "GitHub alternatives 2026" em uma barra de pesquisa na qual nunca pensei que digitaria essa frase.
A questão é que não sou Mitchell Hashimoto. Não tenho um projeto de 50 mil estrelas. Não tenho influência com vários "provedores comerciais e de software livre" dispostos a me hospedar. Sou um engenheiro ativo com talvez quarenta repos ativos em mejba.me, Ramlit Limited e alguns projetos de clientes. A matemática sobre se eu deveria deixar GitHub não é a mesma matemática que a dele.
Mas a questão ficou tão alta esta semana que não pude ignorá-la. Então, passei quatro dias analisando os números - na verdade, testando GitLab, Codeberg e SourceHut em relação ao workflows que executo diariamente - e o que descobri me surpreendeu. Não porque um deles seja obviamente melhor. Eles não são. A surpresa é o que a comparação revela sobre o que GitHub realmente se tornou em 2026, e o tipo específico de desenvolvedor que deveria estar agindo agora em comparação com o tipo específico que deveria absolutamente permanecer parado e apenas se adaptar.
Este é o post que eu gostaria que alguém tivesse escrito antes de eu perder um domingo para ele.
A semana que quebrou a suposição "GitHub é para sempre"
Você já conhece as manchetes. Deixe-me definir um cronograma apertado, porque a ordem é mais importante do que os incidentes individuais.
23 de abril de 2026. Entre 16h05 UTC e 20h43 UTC, uma regressão na fila de mesclagem de GitHub produzia silenciosamente confirmações de mesclagem incorretas sempre que um grupo de filas continha mais de um PR usando o método de mesclagem squash. De acordo com o próprio incidente GitHub, report, 2.092 solicitações pull em 230 repositories foram afetadas. O bug não foi uma falha de disponibilidade — as operações do Git continuaram funcionando, o API continuou retornando dados, a página de status permaneceu quase toda verde. O bug foi que a correção do commit quebrou. O código que as equipes pensavam ter mesclado foi revertido por fusões subsequentes na mesma fila. GitHub levou três horas e trinta e três minutos para perceber, porque nenhum monitor automatizado estava observando "a mesclagem realmente fez o que disse que fez".
Leia esse parágrafo novamente se precisar. Uma plataforma de controle de versão parou brevemente de rastrear versões de maneira confiável.
27 de abril de 2026. O cluster Elasticsearch do GitHub — o subsistema que alimenta as visualizações de lista do PR, a pesquisa de problemas, os filtros do quadro de projeto e a maior parte da UI em que você realmente clica — ficou sobrecarregado. O CTO do GitHub descreveu-o publicamente como um ataque de botnet empilhado sobre o tráfego orgânico com o qual o cluster já estava lutando. Durante horas, os dados subjacentes funcionaram bem, mas a interface que encontra os dados mentiu para os desenvolvedores. As pessoas acusaram colegas de equipe de excluir trabalhos que não haviam sido excluídos. As equipes realizaram reuniões presumindo que os PRs que eles não conseguiam ver não existiam mais.
28 de abril de 2026. Três coisas aconteceram no mesmo ciclo de notícias. GitHub publicou um pedido público de desculpas pela confiabilidade, levando a empresa a uma postura de “Disponibilidade em primeiro lugar”. A Wiz Research divulgou CVE-2026-3854 — um RCE crítico do CVSS 8.7 que permite que qualquer usuário autenticado obtenha execução remota de código no back-end do GitHub com um único git push, injetando dados não higienizados no cabeçalho X-Stat interno. E Mitchell Hashimoto publicou "Ghostty está saindo de GitHub."
Três falhas, três camadas diferentes da pilha, uma semana. Esses são os dados.
Mas aqui está a parte que não cabia na primeira página do Hacker News: O tempo de atividade monitorado por terceiros do GitHub caiu para menos de 90% em 2025 e caiu ainda mais em abril de 2026, atingindo cerca de 86% no mês. O AWS S3, para fins de contexto, é executado em uma meta de design de "onze noves" - 99,999999999%. A página de status público de GitHub continuou reivindicando acima de 99% o tempo todo. Essa lacuna, entre o que a página de status reports e o que os desenvolvedores realmente experimentaram, é o que está desgastando a confiança mais rápido do que qualquer interrupção única poderia.
Quando o desenvolvedor solo mais respeitado no mundo do código aberto diz que uma plataforma “não é mais um lugar para trabalho sério”, o resto de nós tem que pelo menos fazer as contas.
O que eu realmente testei (e o veredicto honesto)
Antes de entrar na comparação, aqui está a regra que estabeleci: não avaliaria nenhuma plataforma a partir de sua página de marketing. Eu migraria um projeto real para cada um, executaria meu workflow real nele por um dia e anotaria o que quebrou.
O projeto que escolhi foi um projeto paralelo privado do Laravel com cerca de 240 commits, ações GitHub para CI, dois PRs abertos, três marcos, doze problemas e um arquivo CODEOWNERS. Não é um brinquedo. Também não é um monstro de 50 mil estrelas. Aproximadamente o tipo de trabalho que a maioria dos leitores deste site realmente faz.
Aqui está o que aconteceu.
GitLab: A migração segura que não é totalmente segura
GitLab é a primeira parada óbvia. É a plataforma com a qual cada lista "GitHub alternatives 2026" lidera, e a razão é simples - é o único concorrente com área de superfície de recursos comparável. CI/CD, rastreamento de problemas, registro de contêiner, registro de pacotes, verificação de segurança, tudo agrupado em um único produto, em vez de agrupado em ações, pacotes, Dependabot e segurança avançada GitHub.
Migrei o projeto Laravel para GitLab.com (o SaaS, não auto-hospedado) usando seu importador GitHub integrado. Tempo total desde clicar em "importar" até ver meu repo com todos os PRs, problemas e marcos intactos: cerca de onze minutos. O importador trouxe:
- Histórico completo do Git (obviamente)
- Problemas com rótulos e marcos
- Solicitações pull como solicitações de mesclagem
- Configuração CI/CD (com reescritas —
.github/workflows/*.ymlnão roda em GitLab; você precisa de um.gitlab-ci.yml) - Regras de proteção de filiais (reaplicadas manualmente)
- Webhooks (tive que recriar)
A reescrita do CI foi o custo real. Minhas ações GitHub workflow executou PHPUnit, executou Pint para formatação, executou uma passagem de análise estática via Larastan e implantou um ambiente de visualização em um Hetzner VPS. Traduzir isso para GitLab CI levou cerca de noventa minutos, principalmente porque o bloco services: do GitLab para ativar um contêiner MySQL é genuinamente melhor que o do GitHub, mas a sintaxe rules: para trabalhos condicionais é mais detalhada. Você não pode copiar e colar; você tem que pensar.
O que o GitLab faz melhor do que o GitHub no momento, ponto final, é a integração DevOps primária. Se você é uma startup que deseja uma plataforma para código, CI, registro de contêiner, registro de pacotes e verificação de segurança e, de outra forma, estaria montando isso com GitHub e mais três outros fornecedores, GitLab é a aposta mais limpa. A história completa é real.
O problema - e este é o problema que ninguém sinaliza alto o suficiente - é que GitLab.com teve sua própria interrupção significativa em 2025 e funciona com a mesma pressão de escala fundamental que o GitHub faz. Migrar de um grande host SaaS Git para outro grande host SaaS Git porque você está preocupado com a confiabilidade é, caridosamente, uma estratégia incompleta. Você mudou seu único ponto de falha, não o removeu.
A versão do GitLab que realmente corrige o problema de confiabilidade é GitLab auto-hospedado – seja a Community Edition gratuita ou o nível Premium pago. Essa é uma conversa diferente. Esse é um trabalho de administrador de sistema. Esse é um servidor que precisa de patches, backups, um certificado SSL, uma retransmissão SMTP e um runbook para o dia em que ele cair às 2h. Se você estiver sozinho ou em uma equipe pequena, o imposto operacional geralmente supera o ganho de confiabilidade.
Veredicto do GitLab: Um concorrente genuíno do GitHub em recursos. Um concorrente GitHub questionável em confiabilidade se você permanecer em GitLab.com. Uma verdadeira confiabilidade só é garantida se você se auto-hospedar - e a auto-hospedagem é um trabalho, não uma caixa de seleção.
Codeberg: Aquele que me surpreendeu
Codeberg é a plataforma que eu esperava descartar em vinte minutos. Saí do teste levando-o mais a sério do que qualquer outra coisa que avaliei.
Contexto rápido: Codeberg é uma organização alemã sem fins lucrativos que executa uma instância do Forgejo, um soft fork do Gitea governado pela comunidade. Não há investidores, nem anúncios, nem roteiro corporativo, nem recursos do AI fixados no topo, nem aumento "agente workflow" inflando artificialmente a carga. É financiado por doações. Sua filosofia é explícita: ser um lar seguro para software livre e de código aberto. Ele está hospedado na UE sob uma fundação, o que tem uma importância discreta, mas enorme, se você tiver exposição ao GDPR.
Importei o projeto Laravel - bem, um fork dele de fácil acesso ao público. Os próprios termos do Codeberg solicitam que você hospede principalmente trabalhos de origem gratuitos do /open, que é o limite certo para uma organização sem fins lucrativos financiada por doações. A importação demorou cerca de sete minutos. A interface é inconfundivelmente “GitHub por volta de 2018” – e quero dizer isso como um elogio. Visualização PR, visualização de problemas, visualização de marcos, pesquisa de código, tudo imediatamente legível. Nenhuma sugestão AI. Nenhum upsell do Copilot. Nenhum feed de "exploração" projetado para mantê-lo no site.
O sistema CI da Forgejo, Forgejo Actions, é compatível com API com GitHub Actions. Meu .github/workflows/ci.yml foi executado com dois pequenos ajustes: um rótulo de executor renomeado e uma ação que eu estava extraindo do mercado GitHub teve que ser substituída por um equivalente publicado no próprio registro de ações do Codeberg. Cerca de quarenta e cinco minutos de trabalho para ficar verde.
Aqui está a parte que me fez sentar. Na semana de 23 a 28 de abril, enquanto o GitHub estava visivelmente com dificuldades, a página de status do Codeberg mostrava operações normais em todos os componentes. Isso não é uma afirmação exagerada - é uma vantagem estrutural. Codeberg não é um alvo para os mesmos botnets na mesma escala, não está sendo atingido pela mesma carga de agente AI workflow, não está tentando escalar sua infraestrutura 30x para acompanhar o tráfego sintético. A plataforma é pequena o suficiente para permanecer confiável de uma forma que os gigantes atualmente não são.
Os limites honestos: Codeberg não é intencionalmente para trabalho proprietário de código fechado. Os minutos de CI disponíveis são conservadores porque alguém está doando para mantê-los. Não há nenhum gráfico social no estilo do LinkedIn que impulsione a descoberta. Se a estratégia de crescimento do seu projeto depende da página "Tendências" do GitHub, você não pode replicar isso aqui.
Veredicto do Codeberg: Se você envia software de código aberto, especialmente na UE, especialmente como um indivíduo ou uma equipe pequena, este é o alvo de migração mais subestimado em 2026. Não é um substituto do GitHub. É algo melhor nas dimensões específicas em que o GitHub deixou de ser bom – silencioso, confiável, de propriedade da comunidade que atende.
SourceHut: Aquele construído para o engenheiro que você provavelmente não é
SourceHut é a plataforma mais opinativa que testei. Drew DeVault construiu isso em uma tese clara: muito do que torna a hospedagem Git moderna "poderosa" é na verdade ruído, e um workflow baseado em e-mail e livre de JavaScript é mais rápido para desenvolvimento de software sério do que qualquer alternativa com muita interface de usuário. O preço começa gratuitamente; os níveis pagos custam cerca de US$ 20 a US$ 50/year, dependendo do uso.
Vou ser honesto com você. Importei o projeto Laravel, executei o workflow por um dia e desisti por volta das seis horas.
Não porque SourceHut seja ruim. Como o SourceHut foi criado para um workflow, na verdade não executo. A revisão do código em SourceHut acontece por meio de listas de discussão e git send-email. O rastreamento de bugs acontece por meio de um rastreador deliberadamente espartano. CI é executado em builds.sr.ht e é genuinamente rápido e limpo. Mas o delta cultural — mudar da revisão baseada em PR para a revisão patch por e-mail — é enorme. Os mantenedores do kernel Linux adoram. A maioria de nós, inclusive eu, construímos uma década de memória muscular clicando em “Aprovar” em uma interface da web.
A plataforma em si é impecavelmente projetada. Cada página é renderizada em menos de um segundo. Não há JavaScript em lugar nenhum. A transparência do mantenedor sobre os custos e decisões de infraestrutura é algo que ninguém mais neste espaço iguala. Se você é o tipo de desenvolvedor que executa o mutt para e-mail e considera um botão de interface do usuário um insulto pessoal, o SourceHut é a plataforma que finalmente recompensa sua estética.
Veredicto SourceHut: Não é uma alternativa GitHub para a maioria das equipes. Um paradigma diferente para o subconjunto específico de desenvolvedores que realmente desejam patch via e-mail workflows. Respeite a filosofia, mas seja honesto sobre se você é realmente esse engenheiro.
A matemática da migração que ninguém mostra para você
É aqui que quero interromper todas as listas das "principais alternativas GitHub" que você leu esta semana.
A maioria deles para na comparação de recursos. A comparação de recursos é a parte fácil. A comparação de recursos não captura o custo real de sair do GitHub e, se você não avaliar esse custo honestamente, migrará quando não deveria ou permanecerá quando não deveria.
Aqui está a verdadeira matemática.
O que o GitHub realmente oferece além da hospedagem
Ao hospedar em GitHub, você não está pagando para que git push funcione. git push funciona em um VPS de US$ 5 com um repo simples e uma chave SSH. Você está pagando - explicitamente com dólares de assinatura, implicitamente com seus dados - por uma pilha interconectada de serviços, a maioria dos quais não tem substituto em Codeberg, SourceHut ou mesmo GitLab.
Contribuidores de descoberta e entrada. A página "Tendências", o gráfico de exploração, a prova social de estrelas e garfos, a pesquisa nativa do GitHub que permite que um estranho tropece no seu projeto - esses são ativos de negócios enormes para qualquer mantenedor de código aberto e não migram. Mitchell Hashimoto pode mover Ghostty de GitHub porque Ghostty já é famoso. Um novo projeto tentando construir um público não consegue.
Ubiquidade CI/CD. O GitHub Actions se tornou o alvo de integração de implantação de fato para cada provedor de nuvem, cada registro de pacote, cada ferramenta de lançamento. AWS publica ações. Cloudflare publica ações. Vercel publica Ações. Replicar essa superfície de integração em outro lugar não é impossível, mas raramente é algo pronto para uso.
O ecossistema do mercado. Ações de terceiros, aplicativos GitHub, a camada de integração – nada disso existe na mesma densidade em qualquer outro lugar. Se o seu workflow depende de cinco ações do marketplace, migrar significa reconstruir ou substituir cinco integrações.
Recrutamento e identidade. Seu perfil GitHub é, para muitas empresas, seu currículo. Seu gráfico de contribuição é uma credencial. Seu nome de usuário é uma marca. Nada disso é transferido de forma limpa para uma nova plataforma – e o efeito de rede flui apenas em uma direção.
A planilha de custos de migração
Aqui está a planilha que eu gostaria de ter tido no domingo de manhã. Execute seu projeto antes de tomar qualquer decisão.
1. Tempo de migração do repositório. Para um projeto com menos de 500 commits e problemas padrão/PRs: ~30 minutos por repo apenas para a importação. Multiplique pela sua contagem repo.
2. Tempo de reescrita do CI. GitHub Ações para GitLab CI: orçamento de 1 a 3 horas por workflow não trivial. Ações GitHub para ações Forgejo em Codeberg: orçamento de 30 a 90 minutos por workflow. Ações GitHub para compilações SourceHut: orçamento de meio dia por workflow se você nunca escreveu um antes.
3. Webhook e religação de integração. Cada serviço externo postado em seu repo (Slack, Discord, ganchos de implantação, verificações de status) precisa ser reconfigurado. Orçamento de 15 minutos por integração, ou mais se o formato do webhook da nova plataforma for diferente.
4. Proteção de filiais e permissões de equipe. Nada disso migra automaticamente. Auditar e recriar. Orçamento de aproximadamente 2 horas para uma configuração típica de equipe.
5. Atualizações de documentação. Cada emblema README, cada link wiki, cada documento externo que diz "encontre-nos em GitHub". Este é o trabalho nada glamoroso que leva mais tempo do que você pensa.
6. O custo do contribuidor. Se você tiver colaboradores externos, eles também terão que migrar. Alguns não. Você perderá alguma velocidade de contribuição pelo menos no primeiro trimestre após a migração. Coloque isso em sua decisão.
7. O custo de recrutamento e visibilidade. Se o seu projeto ganha colaboradores por meio da descoberta, o efeito de rede do GitHub faz parte da sua estratégia de crescimento. Sair significa reconstruir esse pipeline em algum lugar com efeitos de rede mais fracos.
Para minha configuração pessoal /work de quarenta repo, minha estimativa honesta para deixar completamente o GitHub foi de cerca de 60 horas de trabalho de engenharia focado, além de vários meses de pequenos reparos. Esse é um número real. Uma fração significativa da produtividade de um trimestre, trocada por uma quantidade desconhecida de confiabilidade futura.
Para uma startup com vinte engenheiros, multiplique isso pelo número de repos e integrações e você terá um projeto de meses de duração com custo de oportunidade real. Para um projeto público de 50 mil estrelas como o Ghostty, é ainda maior - exceto que o Hashimoto tem a vantagem de negociar com os fornecedores e a marca para manter os colaboradores prestando atenção durante a transição.
Para a maioria dos leitores desta postagem: o custo de migração é maior do que o custo de confiabilidade de permanecer durante a recuperação do GitHub, a menos que uma das três condições específicas seja verdadeira.
Quando você realmente deveria migrar (e quando não deveria)
Depois de executar as contas no workflows real, aqui está a estrutura que estou usando pessoalmente e recomendando aos clientes.
Migre agora se:
Seu trabalho depende da correção da fila de mesclagem para monorepos de alta velocidade. O incidente de 23 de abril interrompeu especificamente a correção de confirmação nas filas. Se sua equipe mescla dezenas de PRs por dia por meio de filas automatizadas e você não consegue tolerar nem mesmo uma pequena probabilidade de reversões silenciosas, a lacuna de confiança é grande demais para esperar. Os trens de mesclagem do GitLab ou uma alternativa auto-hospedada são coberturas razoáveis.
Você tem exposição ao GDPR ou requisitos de soberania de dados da UE e está tratando "GitHub é adequado para isso" como uma suposição de trabalho que você realmente não examinou. Codeberg ou Forgejo auto-hospedado na infraestrutura da UE esclarece sua história de conformidade de uma forma que o GitHub agora complica ativamente.
Você executa o GitHub Enterprise Server. Este é aquele em que eu realmente acho que você deveria agir hoje, não no próximo trimestre. CVE-2026-3854 afetou cerca de 88% dos casos de GHES na divulgação. Se você ainda não atualizou para o GHES 3.19.3 ou posterior, esse é o seu primeiro passo, independentemente de qualquer questão de migração. A cadeia RCE – injetar um rails_env falso, redirecionar o diretório de gancho, plantar um gancho de pré-recebimento, obter a execução do código como o usuário git – é direta o suficiente para que a exploração em estado selvagem seja uma questão de quando, não se.
Fique (com ajustes) se:
Você é um desenvolvedor solo ou uma pequena equipe executando o workflows padrão baseado em PR em um repos público para obter visibilidade. O custo de migração é real, o custo de descoberta é grande e a maioria das falhas recentes do GitHub não quebrou o próprio Git. Eles quebraram a camada da UI que encontra seu trabalho. A medida certa é se proteger contra falhas na camada de UI (use gh CLI, crie scripts na UI da web, espelhe repos crítico em outro lugar como backup frio) em vez da migração completa.
Seu negócio depende de integrações nativas do GitHub como Copilot, Advanced Security ou ações específicas do mercado que você não pode substituir facilmente. Precificar honestamente a perda de integração muitas vezes leva a “migração” para “ainda não”.
Você está executando um projeto cujo crescimento depende da descoberta de contribuidores recebidos. Você está usando o efeito de rede do GitHub, mesmo que não pense dessa forma. Não subestime o preço.
A peça híbrida que estou fazendo
Para meu próprio trabalho, não estou migrando. Estou espelhando. Cada repo meu que importa agora tem um espelho noturno automatizado para uma conta Codeberg privada. Se GitHub tiver outra semana ruim, tenho uma segunda cópia funcional. Se GitHub nunca mais tiver outra semana ruim, gastei cerca de três horas na automação de espelho e ganhei um backup fora da plataforma que é uma boa prática de qualquer maneira.
A configuração consiste em aproximadamente trinta linhas de bash mais um cron job. Codeberg aceita pushes de qualquer cliente Git padrão, portanto a configuração do espelho é idêntica a qualquer outro remoto. Estou usando o git push --mirror de acordo com uma programação, com credenciais em um cofre separado das minhas credenciais do GitHub. A coisa toda é o tipo de redundância de baixo risco que você gostaria de ter construído antes de precisar dela. (Se você já investiu em um Claude Code workflow para desenvolvimento orientado por terminal, conectá-lo como uma tarefa agendada em segundo plano é uma tarefa de 20 minutos.)
O que isso diz sobre o rumo da infraestrutura do desenvolvedor
Quero encerrar a parte que é maior do que qualquer plataforma individual.
O CTO do GitHub descreveu a curva de carga que atinge a plataforma como "desenvolvimento agentico workflows" chegando "como um buffet grátis". Essa frase ficou comigo a semana toda. Ele não está errado. Cada agente Claude Code, cada execução de Codex, cada trabalho em segundo plano do Cursor, cada pipeline autônomo que você e eu estamos executando em 2026 atinge o API de GitHub mais do que um humano jamais faria. Somos, coletiva e acidentalmente, a carga que o quebrou.
A arquitetura GitHub em execução em 2024 foi dimensionada para desenvolvedores humanos. A arquitetura necessária em 2026 é dimensionada para agentes e humanos, e a diferença entre esses dois números é de aproximadamente 30x. Essa é a meta de expansão com a qual a empresa se comprometeu publicamente. É um enorme projeto de engenharia. Se o atingiram em doze meses ou em trinta e seis é a verdadeira questão que determina se os incidentes de Abril de 2026 foram um ponto problemático de transição ou o início de um declínio mais longo.
O que também é verdade é que o mesmo surto de agente workflow que altera a curva de carga do GitHub está mudando o que os desenvolvedores valorizam em um host Git. Nós nos preocupamos mais com a confiabilidade do API do que com o aprimoramento da interface do usuário, mais com o acesso programático do que com recursos sociais, mais com custos previsíveis do que com listas de recursos corporativos. Codeberg e SourceHut, por acidente ou por projeto, foram construídos para esse público anos antes de o público existir em grande escala. O momento deles é agora. Se você estiver criando agentes AI que atingem APIs de controle de versão continuamente, o host escolhido será uma decisão de suporte de carga de uma forma que não era há dois anos.
O que tenho mais certeza, depois desta semana: a era em que "GitHub" era sinônimo de "onde reside o código" está chegando ao fim. Não porque o GitHub esteja em colapso – a Microsoft tem o capital, os engenheiros e as razões estratégicas para consertar isso. Mas porque a suposição de inevitabilidade desapareceu. Vimos o desenvolvedor solo mais visível do código aberto fazer as malas e ir embora. Vimos a própria empresa admitir publicamente que seu tempo de atividade está abaixo de 86%. O padrão foi quebrado, e um padrão quebrado é um tipo diferente de padrão.
Você não precisa sair. Eu não vou embora. Mas voltar sonâmbulo à suposição de que GitHub é a única opção séria para hospedar código em 2026 é algo que nenhum de nós pode mais fazer. A questão está finalmente de volta à mesa – e isso, mais do que qualquer um dos incidentes individuais, foi o que mudou este mês.
Então aqui está a lição de casa. Em algum momento nos próximos sete dias, defina um cronômetro de uma hora. Escolha a planilha do início desta postagem. Compare-o com um projeto seu que realmente importa. Apenas um. Descubra qual seria o custo real da migração para você, em seu código, com suas integrações.
Você provavelmente não se moverá. Mas você nunca mais estará na posição de ter que tomar essa decisão em condições de pânico, como acabou fazendo metade dos gerentes de engenharia com quem conversei esta semana. Essa é a verdadeira vitória. Não a migração. A clareza.
Perguntas frequentes
GitHub está fora do ar agora?
GitHub está geralmente disponível, mas tem operado abaixo de suas metas históricas de confiabilidade – o monitoramento de terceiros colocou o tempo de atividade de abril de 2026 em torno de 86%, bem abaixo da narrativa da página de status da plataforma. Incidentes específicos em 23 de abril (corrupção na fila de mesclagem) e 27 de abril (interrupção da pesquisa do Elasticsearch) causaram interrupções de várias horas. Para status em tempo real, verifique monitores de terceiros em vez da página oficial de status.
O GitLab é realmente mais confiável que o GitHub?
Não categoricamente. GitLab.com funciona com a mesma pressão de escalonamento SaaS que GitHub e teve suas próprias interrupções significativas em 2025. GitLab é mais confiável que GitHub somente se você hospedar por conta própria, o que troca ganhos de confiabilidade pelo custo operacional de execução de seu próprio servidor. Para a maioria das equipes, mudar de provedor de SaaS não resolve a questão subjacente de confiabilidade.
O que é Codeberg e é uma alternativa real ao GitHub?
Codeberg é uma organização alemã sem fins lucrativos que administra Forgejo, uma plataforma Git governada pela comunidade. É uma alternativa real para projetos gratuitos e de código aberto, especialmente com as necessidades de soberania de dados da UE. Intencionalmente, não é adequado para trabalho proprietário de código fechado. CI é compatível com API com ações GitHub, e a plataforma permaneceu totalmente operacional durante os incidentes de abril de 2026 do GitHub.
Devo migrar meu repos privado do GitHub agora mesmo?
Provavelmente não, a menos que você caia em um dos três grupos: monorepos de alta velocidade, dependendo da correção da fila de mesclagem, requisitos de soberania GDPR/EU ou instâncias do GitHub Enterprise Server que ainda não corrigiram o CVE-2026-3854. Para a maioria dos desenvolvedores individuais e equipes pequenas, o custo da migração supera o custo atual de confiabilidade. Um movimento intermediário mais inteligente é espelhar o repos crítico para um segundo host como backup frio.
O que é CVE-2026-3854 e isso me afeta?
CVE-2026-3854 é uma vulnerabilidade de execução remota de código CVSS 8.7 divulgada pela Wiz Research em 28 de abril de 2026, explorável por qualquer usuário autenticado por meio de um único git push com opções de push criadas. GitHub.com foi corrigido em março de 2026 – nenhuma ação necessária para usuários da nuvem. Os usuários do GitHub Enterprise Server devem atualizar para GHES 3.19.3 ou posterior; estima-se que 88% dos casos de GHES ainda estavam vulneráveis no momento da divulgação.
Vamos trabalhar juntos
Procurando construir sistemas AI, automatizar workflows ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.
- Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e marca): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
