O caso
Na quinta-feira, 11 de junho de 2026, desenvolvedores brasileiros começaram a perceber algo estranho: a API do GitHub simplesmente parou de responder.
O site github.com continuava funcionando normalmente para navegação, clone via SSH, tudo certo. Mas api.github.com — o coração que alimenta a linha de comando com gh, as integrações de CI/CD, os bots, as automações — virou um buraco negro. Requisições timeout, conexões recusadas, rotas silenciosamente jogadas no limbo.
Não foi um bug. Não foi um erro de configuração. Foi um bloqueio de rede.
O que realmente aconteceu
A causa suspeita é uma ordem de bloqueio da Anatel relacionada a direitos de transmissão de futebol. Ordens anti-pirataria que, na prática, usam listas de IPs para bloquear serviços considerados infratores. Só que o tiro é tão largo que acerta serviços legítimos — neste caso, o IP de api.github.com (4.228.31.149) foi parar no meio dessa lista.
Testes feitos por desenvolvedores em diferentes provedores (VIVO, Claro) confirmaram: o mesmo IP resolvia corretamente via DNS, mas o tráfego simplesmente não chegava ao destino. Um blackhole em nível de operadora. Cerca de 250 milhões de IPs no Brasil foram afetados, segundo estimativas.
O impacto no dia a dia
Na prática, o bloqueio quebrou:
- gh CLI — nada de
gh pr list,gh issue view,gh api rate_limit - CI/CD — pipelines que dependem da API do GitHub para notificar status, buscar artefatos, acionar deploys
- Bots e automações — tudo que conversa com o GitHub via API parou de funcionar
- Integrações de terceiros — ferramentas que usam o GitHub como backend de autenticação ou dados
O mais curioso é que o bloqueio foi silencioso. Não houve comunicado oficial. Não houve transparência. O Github Status (githubstatus.com) nunca registrou incidente — porque do ponto de vista do GitHub, o serviço estava funcionando perfeitamente. O problema estava no meio do caminho entre o desenvolvedor brasileiro e o servidor.
Por que isso importa
Esse episódio escancara uma verdade que muitos preferem ignorar: serviços de terceiros não estão sob seu controle. E quando algo dá errado, você não tem para quem ligar.
O desenvolvedor brasileiro médio:
- Descobriu o bloqueio por acaso, no meio do expediente
- Perdeu horas tentando debugar um problema que não era dele
- Teve que improvisar soluções: VPN, proxy Tor, Tailscale com exit node fora do país
- Ficou refém de um bloqueio que não pediu, não autorizou, e sobre o qual não foi informado
E o mais grave: não há garantia de que isso não vai acontecer de novo. Se um IP do GitHub pode ser bloqueado por tabela, amanhã pode ser um IP da OpenAI, do GitLab, do seu provedor de nuvem favorito. O mecanismo que permite esse tipo de bloqueio opera na surdina e o escopo é definido por ordens judiciais ou administrativas sem auditaria pública.
O mesmo argumento, agora com ainda mais força
Eu já escrevi aqui sobre por que escolhi Gitea ao invés de GitHub. Naquele artigo, eu falava sobre controle, privacidade, custo previsível. Mas confesso que o argumento mais forte veio depois que o artigo foi publicado: a capacidade de um terceiro derrubar um serviço que você considera essencial.
Não estou dizendo que o GitHub é ruim. O GitHub é uma plataforma excelente, e continuo usando para visibilidade e colaboração via mirror. Mas o repositório principal dos meus projetos — o verdadeiro, o fonte da verdade — está no meu Gitea, no meu servidor.
No dia 11 de junho, enquanto desenvolvedores pelo Brasil inteiro corriam atrás de proxies e VPNs para conseguir trabalhar, meu fluxo continuou normal: git push, git pull, gh na minha instância interna, CI/CD rodando nos meus próprios runners. O bloqueio simplesmente não me afetou.
Não por sorte. Por decisão.
O que você pode fazer
Se você é desenvolvedor e depende do GitHub (ou de qualquer serviço externo) para o core do seu fluxo de trabalho, vale considerar algumas ações:
-
Tenha um mirror. Mantenha seus repositórios principais em um servidor que você controla e espelhe para o GitHub. Se o GitHub cair, você continua trabalhando. Se seu servidor cair, o GitHub ainda tem uma cópia.
-
Diversifique suas dependências. Não coloque todos os ovos na mesma cesta. Se seu CI/CD, seu repositório, seu deploy e sua documentação estão todos no mesmo provedor, uma única falha externa paralisa tudo.
-
Considere self-hosting. Gitea é leve (100MB de RAM), fácil de instalar (um container Docker), e roda em qualquer VPS de entrada. O custo é previsível: o preço do seu VPS. O benefício é imensurável: seu código não para quando o serviço de alguém para.
-
Documente e teste. Simule cenários de falha. O que você faz se o GitHub ficar indisponível por 24 horas? E se for uma semana? Ter um plano de contingência testado é melhor do que improvisar na hora do desespero.
O recado final
O bloqueio da API do GitHub no Brasil não foi um ataque direto aos desenvolvedores. Foi um dano colateral de uma política de bloqueio mal calibrada. Mas o efeito foi o mesmo: milhares de desenvolvedores ficaram sem conseguir trabalhar por algo que não estava no controle deles.
Isso pode acontecer de novo. Pode ser com outro serviço. Pode ser com o seu.
A pergunta que eu deixo é a mesma que me fiz quando decidi migrar para o Gitea: você prefere confiar em terceiros ou prefere estar no controle?
Eu já fiz minha escolha. E no dia 11 de junho, ela se pagou.