Em 24 de abril de 2026, a política de treinamento de modelos do GitHub mudou para os planos individuais do Copilot. O GitHub agora pode usar interações do Copilot Free, Pro, Pro+ e Max, incluindo entradas, saídas, trechos de código e o contexto associado, para treinar e melhorar modelos de IA, a menos que o usuário opte por sair. Os dados do Copilot Business e Enterprise continuam protegidos pelo Acordo de Proteção de Dados do GitHub. O ponto crucial: isso diz respeito aos dados de interação com o Copilot, não aos repositórios privados que apenas ficam parados no GitHub.
Ao mesmo tempo, os argumentos de migração voltaram por outro motivo: instâncias Git auto-hospedadas públicas estavam absorvendo tráfego automatizado pesado. Uma discussão no Hacker News reuniu um conjunto útil de relatos de operadores sobre esse problema: Fim de uma era para mim: chega de git auto-hospedado.
Isso deixa uma pergunta mais útil do que "GitHub ou auto-hospedagem?": qual preocupação você está realmente tentando resolver?
A versão curta
Três respostas. Escolha a que se encaixa na sua situação.
- A: Optar por sair e ficar. Use isto quando a mudança de treinamento do Copilot for sua única preocupação e o GitHub ainda atender às necessidades operacionais da equipe. Desative a configuração no nível da conta e siga em frente.
- B: Rodar um híbrido. Mantenha o OSS público no GitHub pelo efeito de rede. Mova o código privado para uma instância auto-hospedada de Forgejo, Gitea ou GitLab CE atrás de uma VPN ou lista de IPs permitidos. Use isto quando alcance público e controle privado importam ao mesmo tempo.
- C: Migrar por completo. Tire tudo do GitHub. Use isto quando regulação, residência de dados, governança ou política exclusivamente de software livre descartam o GitHub e a equipe consegue arcar com o custo operacional.
A maioria dos leitores está na posição A ou B. A posição C se justifica por exigências mais rígidas de governança, soberania ou valores, não pela configuração do Copilot sozinha.
O que realmente mudou em abril de 2026
A mudança mecânica é pequena. Nas configurações do Copilot, assinantes individuais podem definir "Allow GitHub to use my data for AI model training" como Disabled. O GitHub descreve o material coberto como interações com seus recursos e serviços, incluindo entradas, saídas, trechos de código e contexto associado, e não o conteúdo de repositórios privados que nunca passou pelo Copilot.
Copilot Business e Enterprise não mostram esse botão porque seus dados estão protegidos pelo Acordo de Proteção de Dados do GitHub. Nos planos individuais, desativar a configuração resolve a preocupação com a política de treinamento; não resolve uma objeção mais ampla a depender de uma política controlada pelo fornecedor.
A mudança do Copilot pode ser o estopim sem ser o caso inteiro. Uma equipe também pode se importar com dependência de plataforma, identidade atrelada ao GitHub, fluxos de trabalho construídos em torno do Actions, residência de dados ou o quanto seria fácil se mudar de novo mais adiante. Essas são questões de migração; o botão de treinamento é apenas uma configuração.
Essa distinção importa: optar por sair muda uma configuração de uso de dados, enquanto migrar muda quem controla hospedagem, identidade, integrações e política. A segunda decisão carrega um custo operacional muito maior.
As três posições explicadas
A decisão comprimida em três linhas. Os detalhes vêm abaixo.
| Sua preocupação | Resposta | O Que Fazer |
|---|---|---|
| Meus dados de interação com o Copilot usados para treinamento | Optar por sair e ficar (posição A) | Mude a configuração e volte ao trabalho |
| Código privado que não quero em um fornecedor dos EUA + OSS ativo que não quero esconder | Híbrido (posição B) | Auto-hospede os repositórios privados atrás de uma VPN; mantenha o OSS público no GitHub |
| Soberania, setor regulado, princípio de apenas software livre, independência total do fornecedor | Migração completa (posição C) | Mova tudo; orce o custo operacional |
Posição A: optar por sair e ficar
Se você é um desenvolvedor solo ou uma equipe pequena com repositórios privados e sua única reclamação é o padrão de treinamento, esta é a sua resposta. Mudar uma configuração: um minuto, uma vez. Auto-hospedar: uma pequena conta de VPS, uma estratégia de backup que você realmente testa, integrações para refazer porque presumiam a autenticação do GitHub, e a eventual atualização ou recuperação que cai no pior momento possível.
Auto-hospedar ainda pode valer a pena, mas só se esse trabalho recorrente comprar algo de que você realmente precisa.
A objeção mais forte: o botão também é uma decisão do fornecedor. Em 2026 o GitHub passou de não usar esses dados de interação para treinamento por padrão a usá-los por padrão, e pode mudar a política de novo.
Se sua preocupação de fundo é "nunca quero um fornecedor dos EUA tomando decisões unilaterais sobre meu código", nenhuma caixa de seleção resolve isso, e a posição A é a resposta errada para você. Pule para a posição C.
Mas se sua preocupação é especificamente "não quero meus dados atuais de interação com o Copilot no treinamento" e você vai confiar na configuração do GitHub até a próxima mudança, a posição A é a resposta correta mais barata. Não há vergonha em algo barato e correto.
Posição B: rodar um modelo híbrido
A hospedagem híbrida separa o alcance público do controle privado.
A divisão é simples. O OSS público fica no GitHub: efeito de rede, fluxo de contribuidores, Dependabot e o ecossistema do Actions são valor real. O código privado vai para uma instância auto-hospedada atrás de uma VPN ou lista de IPs permitidos, nunca alcançável pela internet pública.
O motivo de isso funcionar é uma propriedade do modelo de ameaças. A preocupação com o treinamento do Copilot só se aplica aos dados de interação que você envia pelo GitHub. O problema de tráfego de raspadores de IA (próxima seção) só se aplica a instâncias acessíveis publicamente. Um arranjo híbrido privado desvia dos dois.
Para uma equipe privada de 2 a 10 pessoas, 2 vCPU e 4 GB de RAM são um ponto de partida mais seguro para Forgejo ou Gitea, com mais folga se indexação de busca, pacotes ou CI dividirem o mesmo host. Trate isso como dimensionamento de Forgejo/Gitea, não de GitLab CE: o tutorial de instalação em nó único do GitLab começa em 8 vCPU e 7,2 GB de memória, antes da carga de CI.
Não exponha a interface web abertamente na 80 ou 443. Restrinja-a na camada de firewall, proxy, VPN ou rede mesh. Os runners de CI podem atender aos dois lados.
A escolha da plataforma muda o conjunto de recursos mais do que o próprio modelo híbrido. Forgejo e Gitea combinam com uma forge privada mais leve; GitLab CE faz mais sentido quando você também precisa de uma pilha integrada de CI/CD e registro.
Backups são gerenciáveis, mas não os reduza a um git bundle. O guia oficial de atualização do Forgejo considera um snapshot sincronizado, em um ponto no tempo, de todo o armazenamento que o Forgejo usa como o backup confiável e, quando isso não é prático, um dump do Forgejo acompanhado de um dump separado de PostgreSQL ou MySQL. Tanto para Forgejo quanto para Gitea, mantenha repositórios, banco de dados, configuração, anexos e dados LFS juntos, guarde uma cópia fora do servidor e teste uma restauração.
O clone local de um desenvolvedor consegue recuperar o código, mas não as issues, os usuários, os metadados de pull requests, os anexos ou todos os objetos LFS. Se um fork privado se tornar público mais tarde, envie-o para um espelho no GitHub nesse momento.
Posição C: migração completa quando o controle é um requisito
A migração completa se encaixa com mais clareza quando a independência do fornecedor é um requisito, não uma preferência.
Três grupos se destacam: equipes reguladas com regras de auditoria, residência ou controle de fornecedor que descartam o GitHub; equipes do setor público ou da UE cujos requisitos de soberania são política, não preferência; e organizações exclusivamente de software livre que querem sair de uma infraestrutura da Microsoft e já têm pessoal capaz de operar serviços Linux.
O custo é um VPS pequeno, manutenção contínua e perda de integrações. A perda de integrações é a parte que as pessoas esquecem. Tudo que autentica com "Sign in with GitHub" fica no GitHub ou precisa de um provedor de identidade separado.
Planeje a migração em torno das dependências, não apenas dos repositórios. Prévias de PR, Actions de terceiros, bots, webhooks, registros de pacotes e integrações com "Sign in with GitHub" podem exigir novas credenciais, novos fluxos ou serviços substitutos. Estrelas e watchers não viram registros nativos na nova forge, então projetos públicos também abrem mão de parte do seu sinal de descoberta atual.
Faça um ensaio antes de trocar o remoto canônico: migre um repositório representativo, reconstrua suas integrações, teste o histórico de issues e pull requests e documente o caminho de rollback. A comparação de plataformas vem depois dessa auditoria de dependências.
Para equipes que querem governança sem fins lucrativos sem operar um servidor, o Codeberg merece consideração.
Dica sobre soberania. Se você está escolhendo auto-hospedagem por causa de residência de dados na UE, a localização do datacenter importa. Locais como Frankfurt ou Amsterdã são a escolha chata, porém correta. O VPS mais barato na Virgínia não ajuda o seu DPA.
O custo operacional da hospedagem Git pública
A auto-hospedagem pública expõe uma forge ao mesmo tráfego automatizado que atinge qualquer aplicação voltada para a internet, só que as páginas de repositório incluem caminhos caros como visões de blame, arquivos compactados e histórico de commits. Os relatos a seguir são experiências individuais de operadores, não medições de referência.
Na discussão sobre Git auto-hospedado mencionada antes, um operador relatou 37.212.377 requisições contra uma instância cgit em 60 dias, com mais de 99% classificadas como bots.
Na mesma discussão, kstrauser relatou ter derrubado uma instância Forgejo de cerca de 600.000 requisições por dia para aproximadamente 1.000, mas só depois de acrescentar um desafio de JavaScript e cookie por cima das mitigações padrão.
Outros operadores mencionaram fail2ban, bloqueios por GeoIP, blackholes em nível de sistema autônomo e devolver repositórios a plataformas hospedadas. Esses relatos mostram modos de falha possíveis; não são referências universais de tráfego.
O motivo mecânico de isso ser difícil: uma simples limitação de taxa por IP pode falhar diante de tráfego que rotaciona por proxies residenciais. Uma frota de raspadores consegue espalhar requisições por IPs suficientes para que nenhum endereço pareça abusivo, enquanto o servidor ainda assim é sobrecarregado no agregado.
Desafios de JavaScript ou cookie podem reduzir a raspagem pouco sofisticada, mas também podem bloquear usuários sem JavaScript e atrapalhar o Git sobre HTTPS se aplicados a todos os caminhos. O cache de CDN ajuda em leituras repetidas; ajuda bem menos em endpoints únicos ou caros como arquivos compactados, visões de blame e páginas por commit.
O que um desafio muda é a economia do problema. Anubis fica na frente de uma forge e faz o cliente concluir um desafio, por exemplo um pequeno cálculo de prova de trabalho, antes de o servidor devolver a página protegida, o que encarece a varredura em grande volume. É mitigação, não garantia.
Aplique desafios de navegador de forma seletiva. Mantenha o SSH disponível para operações Git e teste o Git sobre HTTPS antes de proteger esse caminho; uma página de desafio devolvida a um cliente Git vira um clone que falha, não uma verificação útil.
O GitHub absorve essa classe de tráfego como parte do seu serviço hospedado. Uma instância pública de Forgejo ou cgit deixa com você o planejamento de capacidade, os controles antiabuso, o cache e a mitigação. Essa transferência operacional, e não o custo bruto do software, é a parte importante da decisão de migrar.
É por isso que o modelo híbrido é uma opção de primeira classe, não um plano B. Código privado atrás de uma VPN: os raspadores não alcançam. OSS público no GitHub: a infraestrutura antiabuso do GitHub cuida do tráfego de bots.
Se ainda assim você quer uma forge pública auto-hospedada, orce logs, controles de taxa, cache, mitigação de bots, monitoramento e um caminho testado para o tráfego Git que não dependa de desafios de navegador. Trate a defesa contra raspadores como parte da operação normal, não como caso extremo.
A questão do efeito de rede para mantenedores de OSS
Aqui eu falo com um leitor bem específico: você mantém um projeto de código aberto. Vinte contribuidores, duzentas estrelas e um rastreador de issues ativo. E está pensando em tirá-lo do GitHub.
Seja honesto sobre o que está trocando: a chance de ser descoberto por contribuidores, o selo implícito de confiança do github.com, Dependabot, CodeQL e o ecossistema de terceiros que se apoia na autenticação do GitHub. Nada disso é impossível em outro lugar; tudo vira atrito.
A regra prática que eu ofereceria: se o valor do seu projeto está sobretudo no código, auto-hospedar é mais fácil de justificar.
O código viaja. Mas se o valor dele depende bastante de contribuidores, issues, visibilidade em buscas e da confiança em torno do github.com, sair troca parte do que faz o projeto funcionar pelo que faz o mantenedor se sentir melhor. Troca legítima se seus motivos forem grandes o bastante. Troca ruim se você está fazendo isso para provar um ponto.
A visão geral da plataforma Codeberg descreve um serviço baseado em Forgejo operado pela associação sem fins lucrativos Codeberg e.V. Para mantenedores de OSS, isso significa governança comunitária sem o peso de manutenção de operar a forge por conta própria.
Para equipes alinhadas ao OSS que querem governança comunitária sem o dever de atualizar, isso representa um salto operacional menor do que operar uma forge pública. O SourceHut é uma mudança de fluxo de trabalho bem mais deliberada e pede uma avaliação separada.
Faça a menor mudança que resolve o problema
Antes de trocar os remotos, escreva o requisito em uma frase: parar o treinamento sobre os dados de interação do Copilot, separar hospedagem pública e privada, ou remover o GitHub da arquitetura. Se você não consegue nomear o requisito, ainda não migre.
Para uma migração, comece com um repositório representativo como piloto. Faça o inventário de autenticação, Actions, webhooks, publicação de pacotes, ambientes de prévia, histórico de issues, dados LFS e passos de rollback antes de trocar o remoto canônico.
Cloudzy's implantação do Forgejo em um clique é um jeito rápido de montar o lado privado de um modelo híbrido; uma instalação manual em qualquer Linux VPS também funciona. Qualquer que seja o caminho escolhido, mantenha a interface web privada, faça backup do estado completo da aplicação e teste a restauração antes de mover um repositório crítico.
Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.
Ver planos LinuxO controle só é útil quando resolve o requisito a um custo operacional que sua equipe consegue sustentar.
Perguntas frequentes
Devo migrar do GitHub por causa da mudança de treinamento do Copilot?
Não automaticamente. Se sua única preocupação é o uso dos dados de interação com o Copilot para treinar modelos, desativar a configuração no nível da conta é a menor correção correta. Migrar faz sentido quando você também precisa de controles mais rígidos de residência de dados, governança, independência de fornecedor ou política exclusivamente de software livre.
O GitHub treina em todos os meus repositórios privados?
Não. A mudança de política discutida aqui cobre os dados elegíveis de interação com o Copilot, incluindo entradas, saídas, trechos de código e o contexto associado enviados pelo Copilot. Isso não significa que todo repositório privado guardado no GitHub seja automaticamente usado para treinar modelos.
Auto-hospedar Git é sempre mais privado?
Só se você a operar assim. Uma forge privada atrás de uma VPN ou lista de IPs permitidos pode reduzir a exposição, mas uma instância acessível publicamente acrescenta responsabilidades de aplicação de patches, monitoramento, mitigação de bots, controle de acesso e backup que o GitHub normalmente absorve.
Qual plataforma Git auto-hospedada devo escolher?
Escolha Forgejo ou Gitea se quiser uma forge privada mais leve. Escolha GitLab CE quando CI/CD integrado e um registro de pacotes ou contêineres importarem o suficiente para justificar suas exigências maiores de recursos e manutenção.
Que tamanho de VPS o Forgejo ou o Gitea precisam para uma equipe pequena?
Para uma equipe privada de duas a dez pessoas, 2 vCPU e 4 GB de RAM são um ponto de partida mais seguro. Acrescente capacidade quando indexação de busca, pacotes, repositórios grandes ou runners de CI dividirem o host. Dimensione o GitLab CE à parte, porque ele precisa de mais recursos.
O que devo testar antes de trocar o remoto canônico?
Faça um piloto com um repositório representativo. Verifique o histórico de issues e pull requests, autenticação, Actions ou fluxos de CI substitutos, webhooks, publicação de pacotes, dados LFS, ambientes de prévia, backups, restauração e o caminho de rollback antes de mover tudo.
