A desconfortável sensação de depender
Durante muito tempo, Git e GitHub foram sinônimos na minha cabeça. Quando pensava em versionamento de código, pensava em GitHub. Quando pensava em abrir issue, fazer PR, revisar código — tudo passava pelo octocat.
Não que o GitHub seja ruim. É uma plataforma excelente, madura, com comunidade gigante, Actions poderoso, Copilot integrado. Mas tem um custo que vai além do financeiro: dependência.
E dependência, no meu livro, é um risco que precisa ser questionado.
O ponto de virada veio quando percebi quantos serviços essenciais do meu dia-a-dia estavam concentrados em provedores externos. Não só código — documentação (Notion), comunicação (WhatsApp), CI/CD, deploy. Cada um desses serviços, se cair, se mudar os termos, se aumentar o preço, ou simplesmente decidir que não quer mais meu perfil de uso, me deixa numa posição desconfortável.
Foi aí que comecei a migrar tudo que podia para a minha própria infraestrutura.
O que o GitHub entrega
Vamos ser justos. O GitHub entrega muito:
- Repositórios ilimitados (públicos e privados) no plano gratuito
- GitHub Actions — CI/CD integrado, com minutos gratuitos generosos
- GitHub Pages — hospedagem estática gratuita
- Issues, Projects, Wiki — gestão de projeto embutida
- Code Review — PRs com diff, comentários, aprovações
- Copilot — sugestão de código integrada
- Ecossistema — milhares de integrações, marketplace, APIs
- Comunidade — 100+ milhões de desenvolvedores, descoberta de projetos, network
Para um desenvolvedor individual, é praticamente imbatível de graça. Para uma equipe, os planos pagos são competitivos.
Mas tem o lado que não está na página de preços: o controle.
O que o Gitea entrega
Gitea é um fork community-driven do Gogs. Escrito em Go, leve, open source, e compatível com grande parte do ecossistema Git.
O meu Gitea está rodando em um subdomínio próprio, deploy feito via CapRover (um PaaS open source que eu também self-hosto — mas isso é assunto para outro artigo).
A stack é simples:
- Container Docker
gitea/gitea:latest - Proxy reverso gerenciado pelo CapRover com SSL automático via Let’s Encrypt
- Banco SQLite (ou MySQL/PostgreSQL, dependendo da escala)
- Acesso com autenticação
Gitea vs GitHub: a comparação honesta
Onde o GitHub ganha
1. Ecossistema. O GitHub tem Actions, Packages, Pages, Copilot, Codespaces, Discussions, Sponsor, e milhares de integrações de terceiros. O Gitea tem Actions (compatível com GitHub Actions), Packages, Pages, mas tudo numa escala menor, mantido pela comunidade.
2. Community discovery. No GitHub você descobre projetos por estrelas, trending, explore. No Gitea, não existe “descobrir repositórios” — cada instância é isolada. Se você quer visibilidade, GitHub ainda é o lugar.
3. CI/CD nativo. GitHub Actions é maduro, rápido, e tem uma marketplace imensa. Gitea Actions está evoluindo rápido (é compatível com a mesma sintaxe), mas exige você configurar seus próprios runners.
4. Copilot. Não existe equivalente integrado no Gitea. Você pode usar uma ferramenta externa (Continue.dev, Cody, etc.), mas não é nativo.
Onde o Gitea ganha
1. Controle total. O repositório é seu. O servidor é seu. Os dados são seus. Não existe “GitHub alterou a política de privacidade”, “GitHub baniu meu repositório”, “GitHub está com downtime generalizado”. No Gitea, se cair, é problema meu — e eu prefiro meus problemas aos problemas de terceiros.
2. Performance. Gitea é escrito em Go. Um binário só, consumo de RAM irrisório (cerca de 100MB). Roda em qualquer VPS de entrada. GitHub, por ser SaaS, às vezes tem lentidão em horários de pico — você não controla.
3. Privacidade real. Repositórios privados no GitHub não são “privados” no sentido absoluto — o código passa pelos servidores da Microsoft, é escaneado por bots, e está sujeito a termos de uso que podem mudar amanhã. No Gitea, privacidade é literal: o código não sai do seu servidor.
4. Sem limites artificiais. GitHub tem limites de tamanho de arquivo (100MB por arquivo, 2GB por repositório recomendado), limites de Actions (minutos por mês), limites de Pages (500MB, 100GB/mês). No Gitea, os limites são os do seu hardware.
5. Custo previsível. GitHub grátis é ótimo até você precisar de mais minutos de Actions, mais storage, mais colaboradores privados. Aí vira 21/mês, $49/mês. Gitea é zero de licenciamento — o custo é o VPS que você já tem.
6. Integração com a infraestrutura. Como o Gitea roda no mesmo servidor que meus outros serviços (DashBot, Assistentia, CapRover, Wallabag, etc.), a integração é natural. Scripts de deploy, hooks, automações — tudo na mesma rede Docker, sem depender de conectividade externa.
A tabela resumo
| Aspecto | GitHub | Gitea |
|---|---|---|
| Tipo | SaaS (nuvem) | Self-hosted (seu servidor) |
| Código | Open source? Não (partes são proprietárias) | 100% open source (MIT) |
| Linguagem | Ruby (no backend) | Go |
| Performance | Variável (depende do horário) | Leve, 100MB RAM, responde em ms |
| CI/CD | GitHub Actions (maduro) | Gitea Actions (compatível, em evolução) |
| Pages | Sim, limitado | Sim, com seu próprio domínio |
| Copilot | Nativo | Não (precisa ferramenta externa) |
| Privacidade | Código na nuvem da Microsoft | Código no seu servidor |
| Limites | 100MB/arquivo, 2GB/repo | Sem limites artificiais |
| Custo | Grátis até R$ ~130/mês (Pro) | Grátis (só o VPS) |
| Manutenção | Zero (SaaS) | Você atualiza, faz backup, monitora |
| Comunidade | 100M+ devs | Por instância (isolada) |
| Descoberta | Trending, explore, estrelas | Não existe |
| SSH | Porta 22 (git@github.com) | Porta customizada |
O que eu perdi migrando?
Sinceramente?
Quase nada.
O que mais senti falta no começo foi o ecossistema de descoberta — aquele “deixa eu ver o que tal pessoa tá fazendo” que o GitHub entrega bem. Mas isso é um hábito de consumo, não uma necessidade de trabalho.
O GitHub Actions eu substituí por scripts de deploy manuais (e eventualmente por Gitea Actions nos projetos que precisam de CI). O GitHub Pages eu substituí pelo Quartz + Docker (que é como este blog roda). O Copilot eu substituí pelo Hermes e por ferramentas de IA locais.
Cada substituição exigiu um pouco de configuração inicial, mas o resultado final é um ecossistema que funciona do meu jeito, nos meus termos.
E a parte chata?
Self-hosting não é grátis (no sentido de trabalho). Você precisa:
- Atualizar o container periodicamente (segurança)
- Fazer backup do banco de dados e dos repositórios
- Monitorar se o serviço está no ar
- Gerenciar SSL, DNS, firewall
- Resolver problemas quando algo quebra
No GitHub, tudo isso é responsabilidade deles. No Gitea, é sua.
A pergunta que você precisa se fazer é: o que pesa mais? O esforço de manter um serviço ou o desconforto de depender de um terceiro para algo que você considera essencial?
Pra mim, a resposta foi clara. Por isso tenho movido cada vez mais serviços para minha própria infra. Gitea foi o primeiro. CapRover veio junto. O banco de dados PostgreSQL está no mesmo cluster. O blog está no mesmo servidor. E aos poucos, vou trazendo mais coisas para cá.
Um adendo sobre o mirror
Uma estratégia interessante que adotei foi manter um espelho (mirror) dos repositórios do Gitea para o GitHub. Existe um container específico para isso (gitea-mirror) que sincroniza automaticamente os repositórios.
Isso me dá o melhor dos dois mundos:
- O repositório principal fica no Gitea, no meu servidor, sob meu controle total
- Um mirror público vai para o GitHub, para visibilidade e colaboração externa
- Se o GitHub cair, o mirror não me afeta — o repositório real continua funcionando
- Se o Gitea cair, o GitHub ainda tem uma cópia (defasada, mas existe)
Essa redundância é o tipo de tranquilidade que eu não tinha quando tudo estava só no GitHub.
A decisão é sua
Não estou dizendo que todo mundo deveria migrar para Gitea amanhã. O GitHub é uma plataforma excelente, e para muita gente — talvez a maioria — faz todo o sentido continuar usando.
Mas se você, como eu, sente um desconforto crescente com a concentração de serviços essenciais nas mãos de poucas empresas, vale a pena conhecer as alternativas. Gitea é uma porta de entrada para um modelo diferente de relação com a tecnologia: você no controle.
O primeiro passo é instalar. O segundo é migrar um repositório. O terceiro é perceber que você não sente falta do GitHub — e isso, para mim, foi a maior surpresa de todas.