Saindo do GitHub para o Forgejo
(jorijn.com)- O motivo direto para sair do GitHub não é a indisponibilidade de abril de 2026, mas a questão da propriedade do código e dos fluxos de trabalho executados no GitHub
- Desde agosto de 2025, o GitHub ficou sem CEO próprio e foi incorporado à divisão CoreAI da Microsoft, fazendo com que o código passasse a ficar sob a organização de IA da Microsoft
- A partir de abril de 2026, o Copilot Free, Pro e Pro+ mudou para um modelo de opt-out em que os dados de interação passam a ser usados por padrão como dados de treinamento
- Como GitHub e Microsoft são empresas dos EUA, estão sob a jurisdição da FISA 702 e do CLOUD Act, e apenas a residência de dados na UE não resolve isso
- O Forgejo v15 LTS roda em um único NUC no code.jorijn.com, com runners isolados por KVM, gVisor, rebuild semanal e filtro de egress
O motivo para sair do GitHub não é a indisponibilidade, mas a questão da propriedade
- A indisponibilidade de abril de 2026 foi séria o suficiente para os desenvolvedores, mas o principal motivo para sair do GitHub não é a indisponibilidade em si, e sim a propriedade do código e dos fluxos de trabalho executados sobre o GitHub
- Em 27 de abril de 2026, o Ministério do Interior da Holanda fez o soft launch do code.overheid.nl, uma instância autohospedada do Forgejo para código-fonte do governo
- O gerente de projeto Boris Van Hoytema afirmou que a plataforma surgiu da exigência de que os ministérios publiquem o código-fonte em um “local de propriedade” deles do ponto de vista legal
- O Forgejo foi escolhido em vez do GitLab por ser totalmente open source e por oferecer a liberdade necessária para a autonomia digital
- O host Git padrão para código pessoal também foi movido para code.jorijn.com, onde o Forgejo v15 LTS roda em uma configuração reforçada em um único NUC
- Alguns repositórios já foram migrados, e os demais ainda estão pendentes
- Quando a migração terminar, o plano é arquivar os repositórios públicos no GitHub e apontar, em cada arquivo, para o novo local
Indisponibilidade e carga de IA
- Em 23 de abril de 2026, o caminho de código de squash-merge da merge queue reverteu silenciosamente commits já mesclados em 658 repositórios e 2.092 pull requests após uma implementação incompleta de feature flags
- Empresas como Modal e Zipline recuperaram os dados manualmente
- Quatro dias depois, Pull Requests, Issues e Packages ficaram indisponíveis por mais de 6 horas devido a um cluster do Elasticsearch sobrecarregado
- Só em fevereiro de 2026, foram registrados 37 incidentes, incluindo uma indisponibilidade de 3 horas e 40 minutos em que Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot e Pages caíram ao mesmo tempo
- Em 1º de outubro de 2025, houve uma indisponibilidade de 10 horas dos runners de macOS
- Segundo a contagem do IncidentHub, de maio de 2025 a abril de 2026 o GitHub registrou 257 incidentes e 48 grandes indisponibilidades, com cerca de 112 horas totais de downtime
- Ao pedir desculpas em 28 de abril, o CTO do GitHub, Vlad Fedorov, afirmou que seria necessário aumentar a capacidade em 30 vezes para acompanhar a carga causada pelo “agentic AI workflow growth” desde dezembro de 2025
- Os problemas de confiabilidade são interpretados como um efeito colateral da expansão dos recursos de IA
- Em vez de desacelerar os recursos de IA, o GitHub está pressionando ainda mais nessa direção
- O The Pragmatic Engineer observou que GitLab, Bitbucket, Vercel, Linear e Sentry não passaram pelo mesmo tipo de ano
- Como essas empresas também lidam com pressão da demanda de desenvolvedores, o padrão de indisponibilidades do GitHub parece ser um problema específico do próprio GitHub
Mudanças organizacionais no GitHub
- Em 11 de agosto de 2025, Thomas Dohmke deixou o cargo de CEO do GitHub, e a Microsoft não nomeou um sucessor
- O GitHub foi absorvido pela divisão CoreAI da Microsoft
- A CoreAI é a organização apresentada por Satya Nadella em janeiro de 2025, com o objetivo de construir uma stack de IA e Copilot end-to-end para clientes 1st-party e 3rd-party
- A receita, a engenharia e o suporte do GitHub passaram a se reportar à divisão de desenvolvedores da Microsoft sob Julia Liuson
- O CPO do GitHub se reporta ao VP de plataforma de IA da Microsoft
- A marca permanece, mas a liderança independente desapareceu
- De 2018 a 2024, a avaliação de que a Microsoft operava o GitHub com certo distanciamento era praticamente correta, mas depois de agosto de 2025 essa premissa ficou difícil de sustentar
- Hoje, dar push de código no github.com passou a significar dar push de código para uma unidade sob a organização de IA da Microsoft
Mudança no padrão de dados de treinamento do Copilot
- Em 25 de março de 2026, o GitHub anunciou mudanças na política de privacidade que passaram a valer em 24 de abril
- Os dados de interação de usuários do Copilot Free, Pro e Pro+, especialmente prompts, saídas, trechos de código e contexto relacionado, passam a ser usados no treinamento e na melhoria de modelos de IA, a menos que o usuário recuse
- A mudança central é que se trata de opt-out, não opt-in
- Usuários do Copilot Free, Pro e Pro+ passam a contribuir para o treinamento de modelos se não desativarem isso na página de configurações do Copilot
- Não existe bloqueio por repositório
- Administradores não podem instruir o GitHub a não treinar com interações ocorridas em um repositório específico
- O opt-out é uma configuração por conta de usuário, então cada colaborador precisa escolher individualmente
- Na prática, se um usuário do Copilot Free/Pro/Pro+ lida com um repositório, a base de código pode virar material de treinamento independentemente da licença
- A exceção para repositórios privados também se aplica de forma limitada
- O GitHub afirma não usar para treinamento o conteúdo “at rest” de repositórios privados
- Mas coleta “code snippets and interaction context” gerados durante o uso do Copilot dentro de repositórios privados
- A fronteira entre “código em repouso” e “trechos gerados durante a edição” é nebulosa
- Clientes do Copilot Business e Copilot Enterprise ficam de fora por estarem cobertos por acordos separados de proteção de dados
- A estrutura é: se você pagar o suficiente, suas interações não viram dados de treinamento; caso contrário, viram
- O interesse estratégico do GitHub nos dados de interação dos usuários deixou de ser um elemento opcional e passou a ser um elemento estrutural
O risco de jurisdição não se resolve com a localização dos dados
- GitHub Inc. e Microsoft Corp. são empresas dos EUA, e os dados mantidos por elas entram no escopo das leis americanas, incluindo a Section 702 da FISA e o CLOUD Act de 2018
- As duas leis podem se aplicar independentemente de onde os dados estejam fisicamente
- A Section 702 foi reautorizada por dois anos em 4 de abril de 2024 e segue em vigor com uma prorrogação de 45 dias assinada no fim de abril de 2026
- Ela permite a coleta, por agências de inteligência dos EUA, de dados de não americanos por meio de provedores de serviços de comunicação eletrônica sediados nos EUA
- O CLOUD Act pode obrigar empresas sediadas nos EUA a entregar dados armazenados em qualquer lugar do mundo
- O GitHub anunciou, em outubro de 2024, a disponibilidade geral da residência de dados na UE para o Enterprise Cloud
- Isso trata da questão da localização dos dados, mas não resolve a questão da jurisdição
- A exposição ao CLOUD Act segue a estrutura de controle corporativo, não a localização geográfica
- Um advogado da Microsoft respondeu sob juramento, em uma audiência no Senado francês em junho de 2025, que não podia garantir que dados franceses armazenados em datacenters europeus da Microsoft estariam protegidos contra acesso discreto do governo dos EUA
- Enquanto o código estiver no github.com, esse código estará dentro da esfera jurídica dos EUA
- A residência de dados na UE pode trazer alguma tranquilidade, mas não é uma solução
A escolha do governo neerlandês pelo code.overheid.nl
- O contexto jurídico da escolha do governo neerlandês é a política “Open, tenzij”, em vigor desde 2020
- Softwares desenvolvidos com recursos públicos tornam-se open source por padrão, a menos que haja exigências de segurança ou confidencialidade
- Para cumprir isso, os ministérios precisavam de um lugar para publicar código que realmente controlassem
- A Comissão Europeia opera, desde setembro de 2022, o code.europa.eu, baseado em GitLab e auto-hospedado
- O openCode da Alemanha também é baseado em GitLab
- O code.gouv.fr da França não é uma forge própria, mas um agregador que indexa repositórios hospedados em outros lugares
- O governo neerlandês escolheu deliberadamente o Forgejo, e não o GitLab
- Segundo a OSOR, o motivo foi que o Forgejo é totalmente open source, não tem separação open-core e oferece todas as liberdades necessárias para a autonomia digital
- Van Hoytema acrescenta que o roadmap do Forgejo estava “way more aligned” do que o das alternativas
- O governo neerlandês não queria apenas uma forge soberana, mas uma forge soberana que não ficasse presa atrás do tier premium de um fornecedor comercial
- O governo viu a mesma estrutura de problemas e tomou a mesma decisão, e a escolha pelo Forgejo já não parece mais uma opção periférica
Por que escolher o Forgejo
- O GitLab também foi considerado seriamente
- O GitLab CE auto-hospedado é uma opção bem conhecida e tem um ecossistema comercial maior, além de uma UI mais refinada
-
Licença
- O GitLab adota um modelo open core
- A Community Edition usa licença MIT, mas muitos recursos desejáveis em ambiente operacional ficam no tier Enterprise, com licença não livre
- O Forgejo segue na direção oposta
- A partir da v9.0 de agosto de 2024, ele foi relicenciado de MIT para GPLv3+
- O objetivo explícito é manter o copyleft e evitar futura captura comercial da base de código
- O motivo de o Forgejo ter sido um fork do Gitea em dezembro de 2022 também foi o fato de a Gitea Ltd controlar a marca e o domínio sem consenso da comunidade
- Essa lição se refletiu na escolha da licença
- O GitLab adota um modelo open core
-
Governança
- O Forgejo está sob a Codeberg e.V.
- A Codeberg e.V. é uma associação sem fins lucrativos registrada em Berlim desde setembro de 2018
- Ela tem diretoria eleita pelos membros, orçamento público e mais de 300.000 repositórios na instância hospedada
- Os membros votam anualmente no orçamento
- O plano de 2025 foi aprovado com 88 votos a favor, 0 contra e 1 abstenção
- O Forgejo está sob a Codeberg e.V.
-
Releases e maturidade
- O Forgejo v15.0 LTS foi lançado em 16 de abril de 2026
- É o 100º release do projeto
- O suporte de longo prazo vai até 15 de julho de 2027
- O Forgejo Actions chegou, na v15, ao nível necessário
- Inclui ephemeral runner, OpenID Connect e expansão de reusable workflows
- Desde o fork, os releases têm sido consistentes, e os relatórios mensais também seguem ativos
- O Forgejo v15.0 LTS foi lançado em 16 de abril de 2026
-
Limites do ecossistema comercial
- O ecossistema comercial do Forgejo existe, mas é enxuto
- No momento, o produto comercial mais polido é o Codey by VSHN
- É um Forgejo gerenciado com hospedagem suíça, lançado na Servala em março de 2025
- Começa em 19 CHF por mês
- Não existe uma assinatura de suporte corporativo no estilo Red Hat
- Se você precisa de suporte telefônico 24/7 e de um fornecedor responsável, vai ter de montar isso por conta própria ou esperar
Configuração do code.jorijn.com
- O code.jorijn.com roda em um único Intel NUC no home office
- A RAM é de 64GB
- Forgejo v15 LTS, Postgres 17 e Traefik rodam dentro de Docker
- Uma máquina virtual KVM gerenciada por Incus roda, ao lado, o runner do Forgejo Actions
- Mais importante do que a implantação em si de Forgejo, Postgres e reverse proxy é a decisão sobre a configuração do runner
O runner é a parte mais arriscada
- Em uma forge auto-hospedada, a própria forge é a parte fácil; a parte difícil é o ambiente que executa os jobs de CI
- O runner precisa executar
npm install,composer installepip installdiariamente, seguindo o agendamento do Renovate- O alvo são lockfiles gerados no próprio repositório
- Isso implica executar lifecycle scripts
- Todo job pode acabar executando código potencialmente não confiável
- Há riscos como o worm recente do npm e o ataque à cadeia de suprimentos do axios, que se moveram por bots de dependência com auto-merge em menos de uma hora
- O papel do runner não é executar código, mas isolar o código em execução
- Parte-se do princípio de que uma única camada de defesa pode falhar, e o sistema é projetado para que a camada seguinte absorva essa falha
Camadas de defesa do runner
-
VM KVM persistente
- o runner fica dentro de uma VM KVM separada, não em um contêiner do host
- o ambiente de trabalho não compartilha o kernel do host
- para uma CVE do kernel Linux dentro do runner atingir o NUC, primeiro seria preciso quebrar a fronteira do KVM
-
Uso de gVisor como runtime Docker padrão dentro da VM
- os contêineres de trabalho são executados sob
runsc - o
runscnão repassa chamadas de sistema diretamente ao kernel do host; ele as intercepta no espaço do usuário - para escapar do contêiner, seria preciso quebrar tanto o gVisor quanto o KVM ao redor
- os contêineres de trabalho são executados sob
-
Rebuild destrutivo semanal
- toda segunda-feira às 02:00 UTC, a VM inteira é apagada e recriada a partir de uma nova imagem base do Ubuntu
- um novo registro persistente de runner para o Forgejo também é emitido novamente
- a imagem base é rebuildada no domingo, então a nova VM reflete os patches de
apte do kernel daquela semana - nenhum estado persistente pode permanecer por mais de 7 dias
-
Filtro de saída nftables na bridge do runner
- o runner pode acessar destinos públicos em
:443,:80,:22e:53- isso inclui npm, pypi, ghcr e o próprio Forgejo, acessado por hostname público via hairpin NAT
- ele não pode acessar
192.168.0.0/16,10.0.0.0/8nem172.16.0.0/12 - um job comprometido não consegue escanear a LAN nem acessar a interface administrativa do roteador ou outros serviços do host
- o runner pode acessar destinos públicos em
-
Token de runner com escopo limitado
- os dois registros persistentes de runner são vinculados, respectivamente, a um único escopo de usuário e a um único escopo de organização
- a administração usa o escopo PAT
write:user,write:organization - um token vazado não consegue registrar runners fora do escopo nem executar ações com escopo de admin
- as camadas foram configuradas de propósito para se sobrepor
- cada camada é uma cerca e, juntas, formam uma barreira em profundidade
- isolamento por KVM, gVisor, rebuild semanal e registro de runner vinculado a escopo são todos elementos com suporte nativo do Forgejo e do Incus
O que foi deixado de lado
-
Descoberta e grafo social
- o GitHub é onde os colaboradores encontram repositórios
- quem quer enviar uma pequena correção para um repositório público espera trabalhar no github.com, não em um domínio desconhecido
- quando a mudança estiver concluída, o plano é arquivar cada repositório público no GitHub e fazer o README apontar para code.jorijn.com
- o caminho de descoberta é mantido
- as pessoas ainda encontram o repositório no GitHub, veem o aviso de arquivamento e depois vão para a casa canônica
- isso ainda não foi concluído; apenas alguns repositórios estão em code.jorijn.com, e o restante ainda está pendente
-
Compatibilidade frágil do ecossistema GitHub Actions
- o Forgejo Actions busca familiaridade, não compatibilidade
- a maior parte funciona, mas algumas coisas não funcionam
- o bloco
permissions:no nível do workflow é ignorado silenciosamente actions/checkout@v6quebrou o checkout autenticado em runners não GitHub no começo de 2026, então foi fixado na v5actions/upload-artifact@v4exige um fork hospedado no Forgejo- o OIDC funciona, mas usa uma chave de workflow diferente,
enable-openid-connect: true, em vez dopermissions: id-token: writedo GitHub - se o workflow depende muito de recursos específicos do GitHub, a migração vira um projeto, não algo que se resolve em uma noite
-
Ausência do Dependabot
- o Forgejo não tem Dependabot
- o Renovate roda no mesmo runner self-hosted a cada 3 horas
- ele cumpre a mesma função, mas exige mais configuração, e a montagem levou um dia
-
Suporte de fornecedor 24/7
- o GitHub Enterprise oferece número de telefone e SLA
- o Forgejo oferece issue tracker e sala de chat
- isso é suficiente para uma operação de uma pessoa, mas pode não ser suficiente para uma organização com 200 engenheiros
Quando não vale a pena mudar
- se a equipe não tem nenhuma disposição ou capacidade para operar infraestrutura, é melhor não migrar para um Forgejo self-hosted
- um Forgejo gerenciado como o Codey, ou o Codeberg para FOSS, reduz bastante essa diferença, mas o custo da migração continua existindo
- se você investiu profundamente em recursos exclusivos do GitHub como GitHub Apps marketplace, Codespaces, Copilot Workspace e Advanced Security, não é uma boa opção
- o Forgejo é uma forge, não uma plataforma como serviço para desenvolvimento
- se sua base de contribuidores depende do grafo social do GitHub, a descoberta pode importar mais do que a propriedade
- você pode ficar onde os contribuidores estão, ou aceitar o atrito, concluir a migração, arquivar os repositórios públicos no GitHub apontando para o novo endereço e reavaliar depois
- se não houver uma resposta operacional confiável para os runners, a mudança fica difícil
- esta é a área que precisa ser tratada com mais seriedade
- se você não está preparado para pensar em isolamento por KVM, gVisor, nftables e rebuild semanal, é melhor executar os jobs de CI em um host de runners gerenciado ou ficar no GitHub
- até o governo dos Países Baixos não migrou tudo de uma vez
- o code.overheid.nl é uma plataforma de lançamento suave para ministérios compartilharem código open source, não uma substituição total de tudo o que usam
- a configuração do code.jorijn.com segue a mesma ideia
- o Forgejo é o host canônico e o GitHub é o espelho; o espelho pode ser reavaliado mais tarde
1 comentários
Comentários do Hacker News
Parece que, ao deixarem o GitHub, todos acabam esquecendo o espírito original do git
o git foi pensado para ser descentralizado, e o problema é que o GitHub era mais organizado, escalava melhor e era melhor administrado, então todas as ferramentas em torno do git acabaram se centralizando no GitHub
Ainda assim, seria bom manter pelo menos um espelho com sincronização automática no GitHub. Ao longo dos anos, vi projetos migrarem para hospedagem própria ou hospedagens de nicho, o espelho no GitHub morrer ou ser apagado e, no fim, o projeto desaparecer com o tempo
o git é descentralizado, e o GitHub é só um dos lugares onde se pode hospedar código; dá para fazer
pushpara vários servidores remotospor isso, não vou mais fazer commit de código pessoal lá
Também não me interessam os recursos sociais, como descoberta, estrelas ou issues despejadas por bots de IA. Do jeito que está, já me basta
E também vale lembrar: “Open Source is not about You”
o aspecto mais importante da plataforma que todo mundo esquece é o componente social, e o fato de ter tornado muito fácil criar repositórios externos persistentes e colaborar entre repositórios
usa protocolos e padrões abertos para conectar forges auto-hospedadas entre si
pouquíssimas pessoas já usaram o modelo original de patches por e-mail, e a grande maioria provavelmente nem pretende aprender
As pessoas usam git basicamente porque o GitHub usa, ou, sendo mais generoso, porque ele funciona bem quando combinado com um host central como o GitHub
o que atrai é o modelo de desenvolver código localmente e discutir issues e patches em um portal web; a parte que o próprio git fornece nisso tudo é pequena
Issues, releases, CI, documentação, avisos de segurança, busca e descoberta acabam todos se prendendo ao GitHub com o tempo
Se for um projeto open source, acho melhor manter a hospedagem própria como fonte da verdade, mas conservar um espelho somente leitura no GitHub para que as pessoas realmente consigam encontrá-lo
O que realmente vai mudar o jogo é um suporte completo à federação
por isso estou doando para Forgejo e Codeberg, e recomendo que todos contribuam com mais tempo e recursos para que a equipe do Forgejo consiga implementar isso direito
Outro bom candidato é o Radicle, totalmente descentralizado sobre Git
https://codeberg.org/forgejo-contrib/federation/src/branch/m...
https://liberapay.com/forgejo
https://donate.codeberg.org/
https://radicle.dev/
https://radicle.network/nodes/seed.radicle.dev
Também migrei meus repositórios git para um NUC auto-hospedado
Ainda não coloquei uma interface HTTP para compartilhar com o mundo, porque não quero fornecer conteúdo para raspadores de IA nem quero ter o trabalho de bloqueá-los
É vergonhoso que empresas que se beneficiaram do open source tenham poluído a indústria desse jeito
Está rodando há 3 anos. Se você restringir o acesso só à LAN e não expuser à internet, a experiência é sólida e duradoura
Os repositórios espelham bem por algumas semanas e depois param. Coloquei um token PAT sem expiração, mas ele insiste em dizer que expirou; quando testo em outro lugar, o token funciona normalmente
Às vezes não aparece nada nos logs, outras vezes o banco de dados está bloqueado. Só o Forgejo usa esse banco
Até agora, não consegui distinguir se isso é um problema do Forgejo, se os travamentos do banco vêm da péssima E/S do cartão SD do Pi, ou se o Forgejo simplesmente não serve para atuar como espelho
As megacorporações monopolistas de nuvem ganham trabalho de graça e usam isso para construir o mundo que odiamos: redes de vigilância, celulares onde você não pode instalar o que quiser, atestado de dispositivo e uma monocultura de navegadores sem bloqueio de anúncios
O Google fez as pessoas amarem BSD/MIT, e o resultado está aí
Um truque típico é: “agora isso é nosso”. Quando um fornecedor cria algo como Elasticsearch ou Redis, as hiperescalas pegam aquilo, transformam em produto monopolista próprio e ficam com todo o lucro, enquanto o autor original e a empresa passam fome
Outro é “abraçar, estender, extinguir”. Pegam projetos open source como KHTML ou Linux, fazem sua própria versão, espalham pelo mercado para expulsar concorrentes e, com meios anticompetitivos, colocam o produto delas na frente de todo mundo; quando ganham participação, enfiam rastreamento e removem liberdades
O open source deveria ser substituído por “liberdade para pessoas, empresas pagam”. Precisamos de shareware com código-fonte disponível que tenha dentes para enfrentar as hiperescalas
Nem a licença do Richard Stallman é forte o bastante; acho que CC BY-NC-SA é melhor
O open source “puro” foi bem-estar corporativo e um erro. Deixamos os gigantes nos enforcarem com a nossa própria corda
Eu quero muito que a IA leia meu código ativamente
Na seção “What I gave up”, o autor menciona seu grafo social, mas com o GitSocial dá para levar o grafo social e o histórico de colaboração junto
ele permite pull requests entre forges entre quaisquer hosts git, e tudo funciona sem dependência de terceiros
é por isso que essas alternativas quase nunca decolam
Quando o texto diz que “o CTO pediu desculpas publicamente e disse que, para suportar a carga movida por IA, teriam que aumentar a capacidade em 30 vezes”, espero que o GitHub não comece a cobrar pelo uso comum da plataforma
Mas, vendo alguns vibe coders fazendo milhares de commits por dia, estou ficando cada vez mais cético
Seria realmente uma pena se deixasse de ser possível compartilhar código e colaborar de graça
uma pessoa experiente percebe em segundos quando um repositório tem esse tipo de problema, então um sistema calibrado também deve ser possível
a parte complicada é escrever termos legais que permitam aplicar uma cota de vibe
A Anthropic já faz isso no CC, e imagino que GitHub e GitLab também devam estar fazendo algo parecido. O preço seria o ódio dos desenvolvedores do Twitter e de alguns subreddits pequenos, mas parece bem suportável
Por outro lado, sempre me surpreendo ao ver no /r/vibecoding gente pagando 200 dólares por mês de assinatura para fazer projetos de hobby ou sites quase de brincadeira
Já fiz gastos bobos quando podia bancar, mas isso parece diferente
Talvez seja um serviço que fornece sentido e propósito por 2.400 dólares ao ano. Se você chega aos 40 e percebe que não vai ficar rico nem famoso, talvez isso acabe sendo um preço administrável em comparação com outras alternativas
Também ouvi falar do Tangled, um serviço descentralizado construído sobre o AT Protocol, como o Bluesky
ele tem recursos realmente úteis, como stacked pull requests, que o GitHub demorou tanto para implementar que surgiram empresas só para adicionar isso ao GitHub
Queria saber se alguém aqui já usou
https://tangled.org/
https://tangled.org/h14h.com/knot
No geral, a plataforma parece bem promissora. A forma como o AtProto separa servidor de dados pessoais, relays e AppView parece um bom meio-termo
Dá para hospedar um repositório git como um servidor headless só de dados, então, para algo auto-hospedado, quase não há sofrimento
Comparado com soluções ActivityPub como o Forgejo, isso me agrada porque o que me importa é o controle dos dados, e assim evito a chatice de hospedar e escalar um webapp inteiro
Depois da configuração inicial, a única manutenção foi atualizar a versão do knot-server e fazer o deploy de novo. O tangled.org mostra um banner de aviso quando você está em uma versão antiga
Quero usar mais o Tangled em outros projetos e testar os recursos. Tenho interesse especial no suporte nativo a jj e stacked PRs
há também experimentos interessantes, como o tack, para conectar CI personalizada
Se o ATProto passar a suportar dados privados, talvez um dia isso também permita repositórios privados, mas pode levar um tempo
https://tangled.org/mitchellh.com/tack
ainda não falaram nada sobre modelo de negócio, então estou realmente curioso para ver no que isso vai dar
prefiro usar radicle.xyz
Fossil também vale considerar
ele empacota todo o estado do repositório em um único arquivo, incluindo histórico de código, wiki, tickets e fórum, e esse estado é replicado
Quando você precisa trocar de provedor de hospedagem, no Fossil não há dados perdidos por causa disso
https://fossil-scm.org/
Mas o problema é o efeito de rede. Não consigo trazer a equipe para o Fossil
o time precisa compartilhar código com outras pessoas, outros departamentos, e todo mundo, na prática mais de 99%, usa git
Forçar o uso do Fossil parece até prejudicial, então vira um impasse
é parecido com muita coisa na área de tecnologia. Acontece quando você tenta fazer colegas adotarem idiomatismos de estilo funcional ou impor imutabilidade
Dá a sensação de que precisaria de algum projeto grande, tipo algo do Facebook ou do Google, para empurrar a comunidade à força
Mas, filosoficamente, eu não gosto do Fossil. Não há como limpar o histórico, tudo é preservado exatamente como aconteceu
Se é isso que você quer, ótimo, mas no meu fluxo com git eu gosto de experimentar coisas, depois arrumar e organizar os commits antes de fazer
pushAs pessoas vivem falando em descentralização
mas, na prática, a maioria dos sistemas acaba se centralizando
Talvez, quando as pessoas pedem descentralização, o que elas realmente procuram seja um novo centro onde possam ser os novos pioneiros
quando sentem que não têm chance de vencer pelas regras atuais, parece que tentam virar a mesa usando a descentralização como justificativa
as pessoas querem isso porque a administração central única não é suficiente por vários motivos
Não há diferença entre as pessoas gritarem por isso e realmente quererem isso
pior ainda, sistemas centralizados funcionam muito bem na maior parte do tempo, e a dor vem de forma muito intensa em períodos curtos, como fusões ou aumentos repentinos de preço
a descentralização dói um pouco o tempo todo, mas traz uma grande alegria nos raros momentos em que a alternativa centralizada entra em colapso
normalmente, o nome disso é boicote. Você não diria “os biscoitos estão centralizados demais na Nestlé, precisamos descentralizar os biscoitos”
Estou migrando para o Tangled, que foi construído sobre o AT Protocol e por isso usa a mesma conta do Bluesky e outros serviços
até agora, estou gostando bastante
https://vale.rocks/micros/20260511-0440
Há um ano migrei para um Gitea auto-hospedado no meu homelab e bloqueei o acesso público
não uso nem HTTPS, desativei o cadastro e os repositórios também não são públicos
Estou pensando se devo criar uma instância pública com HTTPS, mas minimizando ao máximo a superfície de ataque, especialmente se alguém tiver recomendações sobre Gitea/Forgejo
É importante desativar cadastro local. No meu caso uso o authentik como IdP, mas ele só é acessível pela tailnet. Ou então você cria sua conta e depois desativa o cadastro
Também bloqueei via robots.txt algumas coisas, como visualizações individuais de commits git renderizados. Senão, os raspadores entram em loop infinito
Também bloqueei com força o acesso ao repositório de pacotes do Forgejo, porque tenho pacotes privados e a granularidade de permissões ali ainda não está no nível que eu queria, então sigo ajustando
Continuo monitorando, e até agora não tive grandes problemas. Os detalhes estão em docs.eblu.me, e, se quiser, posso até te apontar direto para o código da infraestrutura
antes, eu tinha uma instância pública somente leitura espelhando a instância interna, com uma única conexão de reverse proxy do ambiente interno para o público, para que o lado público pudesse buscar os dados git
depois disso, no geral funcionava sozinho, e quando eu mudava algo no Forgejo interno, o lado público também era atualizado
Issues, CI etc. podiam permanecer totalmente privados dentro da LAN
por isso fico curioso para saber por que você continua usando Gitea. Agora estou pensando se deveria tentar Gitea de novo em vez de Forgejo