Hoje, 26 de março de 2026, o GitHub publicou uma atualização silenciosa na sua política de uso de dados: a partir de 24 de abril, as interações com o Copilot — incluindo código, nomes de arquivo, estrutura de repositório e histórico de chat — serão usadas para treinar modelos de IA por padrão. Opt-out. Você precisa desativar manualmente.
É a gota d’água pra muita gente.
O Hacker News explodiu com a notícia. No mesmo dia, o artigo “Moving from GitHub to Codeberg, for lazy people” chegou ao topo do ranking com 485 pontos — um sinal claro de que essa discussão passou do nível teórico para o prático. Devs estão mesmo saindo.
Se você ainda não pensou nisso, é um bom momento para pensar.
O que o GitHub anunciou exatamente
Pra ser justo, o GitHub foi razoavelmente transparente sobre o que coleta. Segundo a atualização de política, os dados coletados para treino incluem:
- Entradas e saídas do Copilot (os prompts e as respostas)
- Trechos de código submetidos ao contexto do modelo
- Nomes de arquivos e estrutura de repositório
- Padrões de navegação dentro do IDE
- Histórico de chat e feedback dado às sugestões
O ponto que gerou mais raiva: repositórios privados. O GitHub diz que não usa o código em repouso de repos privados — mas as interações do Copilot dentro de repos privados estão incluídas na coleta. Se você tem um projeto confidencial e usa o Copilot Pro ou Free, suas interações podem ir para o treinamento.
Copilot Business e Enterprise ficam de fora. Mas esses planos custam entre $19 e $39 por usuário por mês. Ou seja: quem paga mais fica protegido. Quem usa o plano gratuito ou básico financia o modelo com seus dados.
Na thread da comunidade do GitHub, a proporção foi 59 reações negativas para 3 positivas. Não é exatamente uma recepção calorosa.
Por que o Codeberg ganhou relevância agora
O Codeberg não é novidade. A plataforma existe desde 2019, gerenciada pela Codeberg e.V., uma organização sem fins lucrativos sediada em Berlim. Mas por muito tempo ficou como a “opção ética que ninguém usa de verdade”.
Isso está mudando.
Com quase 300 mil usuários e 465 mil projetos, o Codeberg cresceu bastante nos últimos dois anos. E o motivo não é técnico — é político. Tem muito dev que simplesmente não quer que o Microsoft Azure leia seu código pra treinar um modelo que vai ser vendido de volta pra ele.
O Codeberg roda em cima do Forgejo, um fork do Gitea criado em 2022. O Forgejo nasceu depois que a Gitea Inc. mudou de governança e começou a aceitar investimento corporativo. Um grupo de contribuidores resolveu forkar e criar uma alternativa com governança democrática e 100% free software. Hoje o Forgejo tem 232 contribuidores ativos, contra 153 do Gitea — e mantém um ritmo de desenvolvimento mais acelerado.
A interface do Forgejo é familiar pra quem já usou GitHub ou GitLab. Não tem aquele choque de “onde está tudo?”. E migrar não é mais a aventura complicada que foi no passado.
Migrando do GitHub pro Codeberg: na prática
A boa notícia: o Codeberg tem importação nativa do GitHub. Você entra na sua conta, clica em “Migrate Repository” e cola a URL do repo. Ele importa:
- Todo o histórico de commits
- Issues (com os números originais preservados)
- Labels
- Informações de autoria
O que não vem automaticamente:
- Pull requests (issues viram issues, mas PRs precisam de tratamento especial)
- GitHub Actions (precisa ser adaptado)
- Integrações de terceiros (webhooks, apps do marketplace)
Pra maioria dos projetos pessoais ou de código aberto, a migração leva menos de 10 minutos.
Passo 1: Criar a conta e importar
Crie sua conta em codeberg.org. Depois, clique em + → “New Migration” → “GitHub”. Você vai precisar de um token do GitHub com permissão de leitura pra que o Codeberg acesse repos privados durante a importação.
Settings → Developer settings → Personal access tokens → Generate new token
Scopes necessários: repo, read:org (se tiver orgs)
Passo 2: Atualizar o remote local
Depois de importar, atualize o remote nos seus repositórios locais:
# Ver remote atual
git remote -v
# Substituir pelo novo remote no Codeberg
git remote set-url origin https://codeberg.org/seu-usuario/seu-repo.git
# Confirmar
git remote -v
Passo 3: Migrar CI/CD
Esse é o ponto mais trabalhoso. O Codeberg usa Forgejo Actions, que tem sintaxe praticamente idêntica ao GitHub Actions. A diferença principal: referências a actions externas precisam de URL completa.
Onde você tinha:
uses: dtolnay/rust-toolchain@stable
Vira:
uses: https://github.com/dtolnay/rust-toolchain@stable
Pequena mudança, grande impacto. A maioria das actions populares funciona dessa forma. O que não funciona são os runners da Microsoft — especialmente os macOS runners, que o GitHub oferece gratuitamente. Se seu projeto tem testes em macOS, você vai precisar ou cross-compilar, ou hospedar seu próprio runner.
Para projetos puramente Linux, a migração é quase transparente.
Passo 4: Hosting de site estático
Se você usa GitHub Pages, o equivalente no Codeberg é o Codeberg Pages. O modelo é o mesmo: um branch ou pasta específica serve o conteúdo estático. A configuração é basicamente igual.
Diferença importante: o Codeberg Pages não tem SLA formal de uptime. Na prática, funciona bem — mas não espere o mesmo suporte corporativo de uma plataforma da Microsoft.
Passo 5: Arquivar o repo antigo
Não delete o repo do GitHub. Archive. Vá em Settings → Danger Zone → Archive this repository. Isso mantém o repo visível e clonável, mas desativa issues e PRs. Atualize o README com um link pro novo endereço.
> ⚠️ Este repositório foi movido para o Codeberg:
> https://codeberg.org/seu-usuario/seu-repo
O que você perde (sendo honesto)
Não vou vender ilusão. Sair do GitHub tem custo real.
GitHub tem 180 milhões de desenvolvedores. Codeberg tem 300 mil. Se o seu projeto depende de visibilidade, estrelas, forks e colaboradores externos, essa diferença importa. Muito.
O marketplace de integrações do GitHub é incomparável. Dependabot, GitHub Actions runners gerenciados, Codespaces, Advanced Security, integração com NPM, Pages com CDN global — é uma plataforma madura com anos de investimento. O Codeberg é funcional, mas não tem nem 10% disso.
CI/CD gratuito no GitHub é generoso. 2.000 minutos por mês em projetos privados, ilimitado em públicos. O Codeberg não oferece runners gerenciados ainda — você precisa hospedar os seus ou usar alternativas como o Woodpecker CI.
Pull Requests não migram. Histórico de PRs fica no GitHub. Se você tem anos de code review documentado lá, ele não vem junto.
A migração faz sentido dependendo do seu perfil:
| Perfil | Vale migrar? |
|---|---|
| Projetos pessoais / hobby | ✅ Fácil e faz sentido |
| Open source pequeno/médio | ✅ Com algum esforço |
| Time pequeno, projetos privados | ⚠️ Avalie o custo de CI/CD |
| Open source grande com comunidade ativa | ❌ Perda de visibilidade é real |
| Empresa dependente do GitHub Enterprise | ❌ Custo de migração proibitivo |
Forgejo como alternativa self-hosted
Se você não quer depender de nenhum serviço externo, o Forgejo resolve o problema de uma vez. Você hospeda tudo no seu servidor, seus dados ficam onde você colocar.
A instalação é simples:
# Com Docker
docker run -d \
--name forgejo \
-e USER_UID=1000 \
-e USER_GID=1000 \
-p 3000:3000 \
-p 22:22 \
-v /opt/forgejo:/data \
codeberg.org/forgejo/forgejo:latest
Em minutos você tem uma instância rodando. Com um VPS de $6/mês você hospeda facilmente dezenas de repositórios pessoais.
O Forgejo tem:
- Interface web completa (idêntica ao Gitea)
- Actions compatível com GitHub Actions
- Webhook support
- OAuth (pode usar seu GitHub como provider de login)
- API compatível com Gitea (e parcialmente com GitHub)
- Suporte a mirrors — você pode espelhar seus repos do GitHub automaticamente
A grande vantagem: seus dados, seu servidor, suas regras. Nenhum modelo da Microsoft vai ver seu código a não ser que você deixe.
O contexto maior: onde o GitHub errou
O problema não é só a coleta de dados de hoje. É o padrão que o GitHub estabeleceu ao longo dos últimos 4 anos.
Quando o Copilot foi lançado em 2021, a maior polêmica foi que ele teria sido treinado em código open source sem a permissão explícita dos autores. A questão legal ainda não foi totalmente resolvida. Vários projetos, incluindo o Linux kernel e partes do GCC, levantaram objeções.
Depois veio a política de uso de dados de 2023, que também gerou reação. Depois os termos de serviço de 2024. Agora isso.
Cada vez que o GitHub mexe nos termos, a comunidade reage e depois esquece. Mas a memória institucional acumula. Em setembro de 2025, o pedido mais votado no fórum da comunidade do GitHub era “desabilite o Copilot completamente na nossa organização”. Não era um bug report. Era um pedido de remoção de feature.
Quando o produto mais comentado da sua plataforma é o que os usuários mais querem desligar, alguma coisa está errada.
Como desativar a coleta de dados no GitHub (se você ainda vai ficar)
Se decidir continuar no GitHub, pelo menos desative a coleta. O processo é manual e precisa ser feito conta a conta — não existe configuração global por organização nos planos básicos.
Para conta pessoal:
- Acesse
github.com/settings/copilot - Role até “Policies”
- Desative “Allow GitHub to use my data to improve GitHub Copilot”
Para organizações (plano Business/Enterprise):
- Vá em
github.com/organizations/SEU-ORG/settings/copilot/policies - Em “Suggestions matching public code”, configure conforme necessário
- Em “Data collected”, desative o treinamento de modelos
O detalhe irônico: pra desativar você precisa estar logado no GitHub, navegar pela interface dele, e confiar que o opt-out é respeitado. Não tem auditoria pública. Não tem confirmação técnica. Você clica e torce.
Pra quem prefere garantias por design em vez de promessas de interface — o Codeberg não coleta dados de treinamento de IA porque não tem um produto de IA pra treinar.
Outras alternativas além do Codeberg
O Codeberg é a opção mais ética e simples, mas não é a única. Dependendo do seu contexto, outras plataformas podem fazer mais sentido.
GitLab
O GitLab é a alternativa mais completa ao GitHub em termos de features. Tem CI/CD nativo robusto, container registry, security scanning, gerenciamento de issues avançado e uma versão self-hosted bastante usada por empresas.
O CERN, a NASA e o projeto GNOME hospedam código no GitLab. A versão Community Edition é open source e pode ser instalada em qualquer servidor.
A desvantagem: o GitLab é pesado. Pra um VPS pequeno, a instalação self-hosted pode ser overkill. E a empresa por trás também é comercial — não tem a mesma filosofia sem fins lucrativos do Codeberg.
Gitea
Antes do Forgejo, o Gitea era a opção mais popular pra self-hosting leve. Ainda é muito usado. Se você já tem uma instância rodando, faz sentido manter — mas novos projetos provavelmente se beneficiam mais do Forgejo, que tem governança mais saudável.
SourceHut (sr.ht)
O SourceHut é a mais radical das alternativas. Interface minimalista ao extremo, funcionamento baseado em email (sem botão de pull request — você manda um patch por email), filosofia purista de free software.
Não é pra todo mundo. Mas se você valoriza simplicidade e controle acima de tudo, é fascinante. Drew DeVault, o criador, é uma das vozes mais consistentes sobre soberania de software na comunidade open source.
Não precisa ser uma migração total
Pra maioria das pessoas, a resposta prática não é “delete o GitHub amanhã”. É diversificação.
Coloca seus projetos pessoais no Codeberg. Mantenha os repos de trabalho onde estão. Espelhe os projetos open source importantes. Aprenda a usar o Forgejo Actions antes de precisar. Reduza sua dependência gradualmente.
O Codeberg suporta mirrors automáticos — você pode manter seus repos sincronizados com o GitHub por um tempo enquanto a migração acontece. Qualquer push no Codeberg pode ser espelhado de volta pro GitHub (ou vice-versa), o que elimina o medo de “e se eu precisar voltar”.
# No Codeberg: Settings → Mirror Settings
# Adicionar um push mirror apontando pro GitHub
# O Codeberg vai manter os dois em sincronia automaticamente
Dessa forma você não perde nada durante a transição. Testa o Codeberg por 30 dias sem abandonar o GitHub. Se funcionar, arquiva o repo antigo. Se não funcionar, você ainda tem tudo lá.
O importante é parar de assumir que o GitHub é a única opção — ou pior, que é neutro. Toda plataforma tem dono, tem interesses e tem incentivos. Entender isso já é metade do caminho.
A outra metade é configurar o git remote set-url.
Fonte de inspiração: Moving from GitHub to Codeberg, for lazy people — #1 Hacker News em 26/03/2026















