Não espere a próxima indisponibilidade: a estratégia do CTO para sair do GitHub

Você não rodaria produção em uma única zona de disponibilidade. Não rode sua organização de engenharia em uma única forja de código.

Nas últimas semanas, vimos uma sequência de lembretes de que o GitHub é uma dependência, não uma garantia: uma divulgação de CVE de execução remota de código (RCE), uma atualização pública de incidente de disponibilidade, o projeto Ghostty anunciando publicamente que está deixando o GitHub, e o HardenedBSD subindo no Radicle. Nada disso significa “entre em pânico e migre amanhã”. Significa agir como um gestor de plataforma responsável: faça um hedge do seu risco agora para poder migrar depois — sem drama.

Este post apresenta um framework de decisão e uma arquitetura concreta para uma estratégia de Git com dupla hospedagem: mantenha o GitHub como primário, levante uma segunda casa para a qual você consiga fazer cutover em horas, não semanas. Você também terá um plano 30–60–90 dias e os riscos que vimos de perto ao entregar isso para equipes nos EUA com nossos engenheiros de plataforma Brazil-based.

Por que fazer um hedge do GitHub é racional (não reacionário)

• Dependência de uma única forja. Se seus repositórios, CI, pacotes e busca de código estão todos atrás de um único fornecedor, uma indisponibilidade de autenticação do lado do provedor pode paralisar a engenharia em minutos. Você mede isso em custo médio da engenharia por hora, não em casas decimais de SLA.
• Eventos de segurança acontecem. RCEs e falhas de vazamento de token continuarão ocorrendo em todas as forjas. A mitigação não é “trocar de fornecedor”. É “assumir violação, conter o raio de impacto, fazer failover rapidamente”.
• Política e preço mudam. Alterações em ToS ou preço (pense em add-ons de IA cobrados por uso ou inflação de assentos) podem atingir o orçamento no meio do ano. Você precisa de alavancagem antes da renovação, não depois.
• Compliance e soberania. Certos clientes (especialmente enterprise ou regulados) cada vez mais exigem proveniência de código demonstrável e um plano de saída do fornecedor. Um espelho com builds assinadas satisfaz auditores que perguntam: “E se o GitHub ficar indisponível por 48 horas?”

Permanecer no GitHub é ótimo. Permanecer apenas no GitHub, sem uma rota de escape testada, não é.

O framework de decisão: três níveis de prontidão

Nível 0: Status quo (não fique aqui)

• Todos os repositórios, issues, CI/CD, pacotes no GitHub.
• Personal access tokens para automação.
• Sem backups offsite, sem assinatura de commits, sem proveniência.

Tempo para sair: dias a semanas, com lacunas dolorosas e perda de dados.

Nível 1: Hedge (comece aqui, 0–30 dias)

• Backups noturnos de repositórios bare offsite (criptografados), incluindo Git LFS.
• Assinatura sem chave para builds via Sigstore (Fulcio/Rekor) e metadados de proveniência (SLSA L2+).
• GitHub Actions usando OIDC para cloud para credenciais; sem segredos de longa duração.
• Artefatos de pacotes espelhados para um registro neutro (ex.: ECR/Artifact Registry/Quay), não apenas GitHub Packages.

Tempo para sair: 48–72 horas com hora extra e algum retrabalho manual.

Nível 2: Dupla hospedagem (o que você realmente quer, 30–90 dias)

• GitHub permanece como primário. Forgejo/Gitea/GitLab CE sobe como um espelho quente (somente leitura por política).
• Todos os repositórios espelhados via push a cada commit; issues/discussões espelhadas em uma cadência.
• Definições de CI/CD neutras quanto ao runner, com um pipeline sombra em WoodpeckerCI/Drone, Buildkite ou Tekton.
• Sourcegraph/Zoekt indexam ambas as forjas.
• Game day de failover trimestral e passos de cutover documentados.

Tempo para sair: 4–8 horas, majoritariamente coordenação de DNS/URLs e virada de pipelines.

Nível 3: Migração completa (apenas se necessário)

• Primário migra para Forgejo/GitLab CE self-hosted ou uma alternativa hospedada (SourceHut, Codeberg, GitLab Cloud).
• GitHub permanece como espelho somente leitura para continuidade do histórico e alcance do ecossistema.

Tempo para concluir: 2–6 semanas com tratamento cuidadoso de histórico de issues/PRs.

A arquitetura de referência: Git que faz failover como produção

Forjas e espelhos

• Primário: GitHub (Enterprise recomendado para SSO, auditoria e allow lists de IP).
• Secundário: Forgejo (fork do Gitea liderado pela comunidade), Gitea ou GitLab CE. Para os muito aventureiros ou casos OSS, adicione um remoto Radicle para replicação peer-to-peer.

Padrão de espelhamento:

1. Proteja sua branch primária no GitHub; apenas o CI ou as merge queues podem escrever.
2. Ao fazer push para branches protegidas, rode um job de push-mirror a partir de um runner endurecido que mantenha uma chave de deploy somente gravação para a forja secundária. Use git push --mirror para novos repositórios e git push --prune para sincronização contínua.
3. Exclua segredos e notas privadas do Git. Sincronize explicitamente Git LFS via git lfs fetch --all e git lfs push --all.

Custos: Uma VM de 4 vCPU/16 GB para Forgejo mais Postgres normalmente custa US$ 60–120/mês em uma grande nuvem, mais armazenamento compatível com S3 para repositórios/LFS (aprox. US$ 0,023/GB-mês). Tempo de administração é o custo real: espere 3–5 horas/semana, uma vez estável, para organizações com 50 engenheiros e 200–400 repositórios.

Identidade e permissões

• Centralize em SSO (Okta/Entra/Google) para ambas as forjas.
• Use tokens de curta duração via OIDC para toda automação; proíba personal access tokens no CI.
• Replique permissões equipe→repo para a forja secundária via um exportador (GitHub GraphQL) e importador (API do Forgejo/GitLab). Gere um diff noturno e alerte sobre drift.

Neutralidade de CI/CD

• Mantenha o GitHub Actions pela ergonomia do desenvolvedor, mas defina pipelines de maneira portátil:
• Para build/teste: Espelhe o grafo de jobs em WoodpeckerCI ou Drone (o YAML é próximo do Actions), ou use Buildkite se quiser um control plane gerenciado com seus próprios runners.
• Para organizações nativas de K8s: Tekton oferece controle total, mas exija mais encanamento.
• Credenciais: Use OIDC para cloud (AWS/GCP/Azure) a partir de ambos os sistemas de CI, para que os segredos sejam idênticos. Nada de segredos de ambiente; cada etapa recebe credenciais novas e com escopo.
• Proveniência de artefatos: Assine contêineres e binários com Sigstore, anexe proveniência SLSA aos releases e verifique no deploy. Isso torna “qual forja construiu isso?” uma não-pergunta.

Issues, PRs e code review

Esta é a parte mais difícil de tornar portátil. Escolha um único sistema de registro para colaboração enquanto espelha metadados para continuidade.

• Sistema de registro: Mantenha issues/PRs no GitHub enquanto estiver em dupla hospedagem. Em failover, congele o GitHub (permissões de escrita no nível da organização desativadas) e promova a secundária para leitura e escrita.
• Espelhamento: Use exportadores para sincronizar issues/labels/milestones para a secundária, nightly. Para Forgejo/GitLab, as ferramentas de migração importam a maior parte dos metadados; revisões e discussões de PR frequentemente perdem fidelidade. Capture snapshots dos PRs em HTML estático no S3 para fins legais/arquivamento.
• Notificações: Direcione webhooks por um relay de fan-out (por exemplo, um serviço pequeno atrás de API Gateway/Cloud Run) que encaminhe para ambos os sistemas de CI e para o chat, de modo que alternar sistemas não quebre as automações.

Busca e experiência do desenvolvedor

• Busca de código: Aponte o Sourcegraph (self-hosted ou cloud) ou Zoekt para ambas as forjas. Devs continuam com uma única barra de busca, independentemente de qual remoto é o primário.
• Devcontainers e templates: Mantenha-os no repositório e agnósticos ao provedor. Evite passos compostos apenas de Actions para operações fundamentais; empacote-os em makefiles ou pequenos CLIs em Go/Node que seu CI alternativo possa chamar.

Cutover: como são, de fato, “quatro horas”

Se você fez o Nível 2 corretamente, aqui está seu runbook para um cutover planejado ou de emergência.

1. Congele escritas no GitHub. Altere permissões de org/repo para somente leitura. Anuncie um brownout de 30 minutos.
2. Promova a secundária para leitura e escrita. Remova políticas de proteção de escrita temporariamente onde necessário; preserve proteções de branch.
3. Vire o CI/CD. Pause Actions em nível de organização, habilite pipelines na secundária (Woodpecker/Buildkite/Tekton). Verifique se os runners estão disponíveis e com autoscaling.
4. Atualize remotos em massa. Para monorepos e equipes trunk-based, atualize URLs do origin via scripts centralizados para repositórios internos; repositórios OSS mantêm o GitHub como espelho para a comunidade.
5. Redirecione webhooks e publicação de pacotes. Seu relay deve tornar isso um toggle, não um refactor. Valide assinaturas de artefatos em staging e, depois, em produção.
6. Monitore e comunique. Acompanhe tempos da fila de merge, duração do CI, canais de incidentes. Decida em até 24 horas se fica ou se faz rollback.

O atrito mais comum: desenvolvedores com branches de feature de longa duração que não foram espelhadas e pipelines fora do padrão que usavam Actions obsoletas. Um dry-run com uma equipe piloto revela isso.

Números que importam ao apresentar isso ao CFO

• Custos de assento não desaparecem. A dupla hospedagem não é principalmente sobre economizar licenças. O preço por usuário do GitHub Enterprise ainda faz sentido para a maioria das equipes. O hedge é um prêmio de seguro, não um substituto.
• Itens de infra são modestos. Espere US$ 150–400/mês para a infra da forja secundária com 50–100 engenheiros, mais US$ 50–150 para uma pequena instância de Sourcegraph/Zoekt se você self-host.
• Tempo para valor é curto. Equipes que ajudamos atingem o Nível 2 em 6–10 semanas com um engenheiro de plataforma alocado em ~50% e um DevOps/SRE em ~30%. Game days consomem 2–3 horas trimestralmente.
• A matemática da indisponibilidade é brutal. Se o custo médio por engenheiro for US$ 150/hora e 60 engenheiros ficarem bloqueados por 3 horas, isso dá US$ 27.000. Um único incidente paga anos de infra de hedge.

Armadilhas e como evitá-las

• Surpresas com Git LFS. Espelhe LFS explicitamente e verifique se a contagem de objetos bate nos dois lados. Muitas equipes presumem que --mirror inclui LFS; não inclui.
• Perda do histórico de review. Você não vai portar 1:1 as threads de review de PR. Arquive-as (HTML estático + S3 com lifecycle) e siga em frente. Mantenha o GitHub somente leitura por um trimestre para que os links continuem funcionando.
• Proliferação de segredos. A dupla hospedagem dobra os lugares onde segredos podem vazar, a menos que você padronize em OIDC e credenciais efêmeras. Não replique pecados antigos.
• Drift das ferramentas sombra. Mantenha um diff semanal de repositórios, equipes e proteções de branch entre as forjas. Falhe rápido no drift em vez de descobri-lo no cutover.
• Abstrair demais o CI. Mire em 80% de portabilidade, não em uma DSL de menor denominador comum que desacelera a equipe. Tudo bem se 20% dos jobs forem específicos do provedor.

E o Radicle e código totalmente descentralizado?

Radicle (que o HardenedBSD agora usa) é atraente para resistência à censura e replicação ponto a ponto. Hoje, é um complemento, não um substituto, para a maioria das equipes comerciais:

• Casos de uso: espelhos OSS, replicação emergencial para máquinas de desenvolvedores e garantia extra para repositórios centrais.
• Lacunas: maturidade de SSO/permissões corporativas e UX de PR/review em comparação ao GitHub/GitLab.

Se você é pesado em OSS ou tem restrições únicas de soberania, adicionar um remoto Radicle é um seguro barato. Trate-o como uma terceira cópia dos seus repositórios mais críticos.

Um plano de 30–60–90 dias que você realmente consegue executar

Dias 0–30: Defesas rápidas

• Faça um inventário de todos os repositórios, uso de LFS, Actions, runners, segredos, webhooks e pacotes.
• Ative a assinatura Sigstore nas builds e anexe proveniência SLSA aos artefatos.
• Substitua segredos de CI por OIDC. Proíba personal access tokens na automação.
• Levante backups noturnos de repositórios bare + LFS para S3 com regras de ciclo de vida.
• Migre a publicação de artefatos para um registro neutro e espelhe de lá para o GitHub Packages (não o inverso).

Dias 31–60: Construa a segunda hospedagem

• Levante Forgejo/GitLab CE com SSO e permissões por equipe.
• Implemente push-mirror por commit para todas as branches protegidas; faça backfill de grandes repositórios offline.
• Suba o CI sombra (Woodpecker/Buildkite/Tekton). Espelhe 70–80% dos jobs do Actions.
• Indexe ambas as forjas no Sourcegraph/Zoekt.
• Espelhe issues/labels/milestones nightly; arquive históricos de PR semanalmente no S3.
• Pilote um game day com um squad de produto e um serviço não crítico.

Dias 61–90: Prove o failover

• Rode um game day de failover de 2 horas para toda a empresa. Meça tempo até merge e estabilidade do CI.
• Publique um runbook de cutover com nomes de responsáveis claros e SLAs.
• Automatize detecção de drift (equipes, repositórios, proteções de branch) e alertas.
• Integre o plano a documentos de risco de fornecedor e BCP para auditorias e clientes corporativos.

Onde um parceiro nearshore ajuda (e onde você não precisa de um)

Você não precisa de ajuda para ativar Sigstore e backups. Você pode querer ajuda quando:

• Você tem 200+ repositórios, múltiplas linguagens e runners de CI heterogêneos.
• Precisa preservar trilhas de evidência SOC 2 enquanto muda CI/CD e fluxos de artefatos.
• Precisa de 6–8 horas/dia de sobreposição para conduzir janelas de migração sem queimar noites e fins de semana.

Uma equipe de plataforma experiente vai antecipar as partes cabeludas: sincronização de LFS, mapeamento de identidade/SSO, verificação de proveniência no deploy e failovers em dry-run. Depois disso, a operação em estado estável é leve.

Em resumo

Ghostty saindo do GitHub, o avanço do Radicle com projetos de SO endurecidos e os próprios relatórios de incidentes do GitHub devem aguçar seu pensamento — não provocar uma migração por impulso. A decisão certa é resiliência ponderada: continue usando o GitHub onde ele brilha, mas dê a si mesmo um Plano B de verdade. Você já investe em multi-AZ, multi-região e runbooks para produção. Sua plataforma de código merece a mesma seriedade.

Principais pontos

• Não saia do GitHub no impulso — faça hedge. Dê dupla hospedagem ao seu código, CI e artefatos para que um cutover leve horas, não semanas.
• Proveniência vence plataforma. Assine builds, anexe SLSA e use OIDC para que posse e integridade não dependam de uma única forja.
• Espere US$ 150–400/mês em infra para uma forja secundária com 50–100 engenheiros; a primeira indisponibilidade paga o hedge.
• A parte mais difícil são issues/PRs. Espelhe o que der, arquive o restante e mantenha o GitHub somente leitura para continuidade.
• Rode um game day de failover trimestralmente. Se você nunca testou sua saída, você não tem uma.