Gitea, Forgejo ou GitLab em VPS: qual usar em 2026?

Gitea e Forgejo costumam ser escolhas mais proporcionais para uma VPS pequena e uma operação enxuta. GitLab Self-Managed faz sentido quando a equipe usará sua plataforma integrada e consegue sustentar a infraestrutura. A decisão certa não é só instalar uma forge: é conseguir atualizar, proteger o acesso, fazer backup e restaurar quando algo falhar.

Servidor Git próprio não é uma medalha de independência. É uma troca operacional. Você ganha controle sobre repositórios, dados e integrações. Em contrapartida, assume atualizações, HTTPS, chaves SSH, espaço em disco e recuperação após falhas.

Para um solo builder, a pergunta inicial não deveria ser “qual é o mais completo?”. A pergunta útil é: “qual opção consigo manter sem transformar meu repositório em mais um serviço abandonado na VPS?”.

Essa é a ideia de Autonomia Operável: auto-hospedagem só entrega autonomia quando acesso, atualização e restore também cabem na rotina de quem opera a instância.

Este é um comparativo documental, baseado nas documentações oficiais auditadas. Não há screenshot de uma instância operada pelo Runzos porque a pesquisa não registra teste próprio de instalação, backup ou restore.

Servidor Git próprio faz sentido para você?

Faz sentido quando você quer concentrar repositórios privados, integrações internas e automações em uma infraestrutura sob seu controle. Também pode ser uma boa escolha para uma equipe pequena que aceita ter responsabilidade explícita pela operação.

Não faz sentido apenas porque GitHub ou GitLab.com parecem caros, ou porque “self-hosted é sempre mais seguro”. O serviço gerenciado transfere parte relevante do trabalho: disponibilidade, atualizações de plataforma e manutenção do ambiente.

Em uma instância própria, a documentação do GitLab deixa claro que o administrador precisa proteger host, sistema operacional e software atualizado. O guia oficial de segurança do GitLab não trata controle da infraestrutura como sinônimo de proteção automática.

Continue em SaaS se sua equipe não tem alguém responsável pela instância. Faça o mesmo se a disponibilidade é crítica e não há plano de recuperação.

SaaS também pode ser mais adequado quando a colaboração pública ampla é o centro do projeto. A economia de uma VPS pode desaparecer no primeiro incidente sem backup utilizável.

O caminho próprio fica mais forte quando há uma razão concreta: repositórios internos, exigência de controle administrativo, integrações na rede privada ou uma operação que já mantém outros serviços. Nesse cenário, Git é só mais uma carga de trabalho. O servidor precisa de domínio, TLS, acesso SSH e observabilidade como qualquer outro app.

Qual cenário favorece Gitea, Forgejo ou GitLab?

Gitea, Forgejo e GitLab resolvem a função de hospedar código, mas não carregam o mesmo peso operacional. Compará-los apenas pela interface apaga banco, runner, armazenamento de arquivos e responsabilidade de atualização.

Quando Gitea faz sentido

O Gitea é uma escolha coerente para quem busca uma forge focada e quer começar com uma arquitetura pequena. A documentação oficial mostra instalação em Docker usando SQLite quando não há banco separado, além de opções com MySQL e PostgreSQL. Isso dá flexibilidade, mas não é autorização para tratar SQLite como resposta universal para toda equipe.

O ponto importante é não inventar uma “VPS mínima oficial” para Gitea. As fontes auditadas não fixam uma linha de base comparável para uso pequeno. Em vez de copiar benchmark de blog, faça um piloto com seus repositórios, monitore disco e memória, e separe a carga do runner quando CI entrar em cena.

Gitea Actions exige um act_runner independente. A própria documentação alerta para não confiar um runner a repositórios, organizações ou instâncias não confiáveis. A documentação de Gitea Actions ajuda a enquadrar a consequência: pipeline não é um botão gratuito. Ele executa código, consome imagens, cache, CPU e pode acessar segredos.

Quando Forgejo faz sentido

Forgejo nasceu após um conflito de governança com a Gitea Ltd. O próprio projeto explica essa origem e se apresenta como substituto direto do Gitea. Esse histórico é um critério de escolha para quem dá peso a uma governança comunitária, não uma prova de que uma plataforma seja tecnicamente superior em todo caso.

Na operação, Forgejo documenta suporte a MariaDB 10.6 ou superior, MySQL 8.4 ou superior, PostgreSQL 14 ou superior e SQLite. Os bancos suportados pelo Forgejo dão opções de arquitetura, mas não substituem o teste com a versão que você pretende usar.

Forgejo Actions também é CI integrado, com workflows em .forgejo/workflows e runners para executar tarefas. A compatibilidade conceitual com outras ferramentas de Actions não garante paridade de sintaxe, marketplace ou comportamento. Antes de migrar uma automação crítica, valide um repositório de teste e tenha rollback documentado.

Quando GitLab faz sentido

GitLab Self-Managed é mais que um servidor Git. Ele reúne CI/CD e camadas de plataforma que podem fazer sentido para uma equipe que realmente vai usá-las. O erro comum é colocá-lo na mesma caixa de “forge leve” de Gitea e Forgejo.

Os requisitos oficiais do GitLab Self-Managed citam, para nó único, 8 vCPU e 16 GB de RAM como baseline. A documentação admite operação com ao menos 8 GB em ambiente limitado, com ressalvas. Ela também recomenda SSD e aponta que Gitaly é intensivo em I/O.

Esse requisito não torna GitLab uma escolha ruim. Ele só torna a escolha honesta. Se a equipe precisa de uma plataforma integrada e consegue dimensionar repositórios, banco, LFS, artefatos, uploads, registry e backups, GitLab pode reduzir a dispersão de ferramentas. Se você tem um repositório pessoal e uma VPS apertada, o conhecido pode ser desproporcional.

VPS, backup e manutenção: o custo que não aparece no plano

A mensalidade da VPS é apenas uma linha do custo. O restante aparece quando o disco enche, um runner acumula cache, uma chave vaza ou o banco precisa voltar depois de uma atualização ruim. Chame isso de custo operacional, não de surpresa técnica.

Para Gitea, backup não é só copiar o diretório de repositórios. A documentação informa que o processo inclui diretório de dados, com anexos, avatares, LFS, indexadores e SQLite quando usado.

O processo também inclui cópia dos repositórios e dump SQL. Para MySQL e PostgreSQL, a documentação recomenda considerar dumpers nativos por problemas conhecidos com XORM.

A documentação de backup do Gitea deve entrar no seu runbook, não só nos favoritos do navegador.

No GitLab, a recuperação exige a mesma versão e o mesmo tipo, CE ou EE, da origem. Backups também precisam contemplar arquivos de configuração e segredos. Isso muda a pergunta: não basta saber se existe backup; você precisa saber qual versão restaurará, onde estão os segredos e como o processo foi testado.

Uma rotina simples é mais útil do que uma arquitetura perfeita nunca exercitada: listar componentes, enviar cópias para armazenamento externo, registrar a versão da aplicação e testar restore em ambiente separado. O tempo, o custo e os erros dessa operação variam conforme a instância e não foram medidos nesta análise.

Se você já centraliza containers em uma VPS, uma VPS para rodar seu servidor Git pode ser uma escolha contextual. Compare o plano com a carga estimada e confirme preço, desconto e cupom na página de oferta antes de contratar. Infraestrutura deve seguir o uso, não o contrário.

Segurança mínima antes de convidar outra pessoa

Uma forge exposta à internet precisa de controles básicos antes de receber equipe, cliente ou código sensível. Não existe lista que elimine risco, mas existe uma diferença grande entre operar conscientemente e abrir uma porta sem plano.

1. Usar domínio com HTTPS/TLS válido para a interface web.
2. Restringir o acesso SSH ao necessário e revisar chaves autorizadas.
3. Fechar cadastro público quando ele não fizer parte do projeto.
4. Exigir confirmação de e-mail onde esse fluxo for usado.
5. Ativar ou impor 2FA conforme a capacidade da plataforma e a política da equipe.
6. Manter sistema operacional, forge e dependências atualizados.
7. Separar runner de repositórios ou instâncias não confiáveis.
8. Guardar segredos de pipeline fora de arquivos de workflow.
9. Fazer backup externo de dados, configurações e segredos.
10. Testar restauração antes de depender dela em uma falha real.

Gitea documenta opções como DISABLE_REGISTRATION e confirmação de e-mail. GitLab documenta controles para restringir chaves SSH e novos usuários, exigir confirmação de e-mail e forçar 2FA.

A documentação de 2FA do GitLab explica as possibilidades da plataforma.

O administrador ainda precisa definir quem deve usá-las e como responderá a uma perda de acesso.

A segurança da CI merece atenção própria. Runner é uma camada de execução. Em projetos com contribuidores desconhecidos, trate cada workflow como código que pode disputar recursos ou tentar alcançar credenciais. “Integrado” descreve a interface; não elimina a responsabilidade de isolar e revisar a execução.

Qual faz sentido para cada perfil?

O veredito não é uma vitória de produto. Gitea é a escolha mais natural para simplicidade operacional, desde que banco, backup e runner não desapareçam atrás da palavra “leve”.

Forgejo entra quando a governança comunitária é um critério real e você aceita validar migração e compatibilidade.

GitLab entra quando o escopo de plataforma é necessário e a VPS foi dimensionada para isso.

Para quem quer infraestrutura brasileira, pagamento local e suporte em português, a alternativa contextual é conferir uma VPS brasileira para serviços auto-hospedados. A recomendação continua sendo a mesma: confira capacidade, condições e compatibilidade com sua carga antes de contratar.

FAQ sobre Gitea, Forgejo e GitLab em VPS

Gitea e Forgejo são compatíveis?

Forgejo se apresenta como substituto direto do Gitea, mas isso não equivale a prometer migração sem riscos. Versões, extensões, workflows e integrações podem exigir validação. Antes de trocar a plataforma de um projeto importante, teste a migração com uma cópia, confirme acesso SSH, push, permissões, Actions e rollback. A recomendação segura é tratar compatibilidade como hipótese verificável no seu ambiente.

Quanto de RAM o GitLab Self-Managed precisa?

A documentação oficial do GitLab cita baseline de 8 vCPU e 16 GB de RAM para nó único. Ela também menciona operação com pelo menos 8 GB em ambiente limitado, com ressalvas. Esse valor não inclui uma promessa de desempenho para toda carga. Repositórios, banco, LFS, artefatos, registry, backups e runners mudam a necessidade de recursos. Use o requisito oficial como ponto de partida e acompanhe o uso real.

Gitea roda com SQLite?

Sim. A documentação de instalação em Docker mostra SQLite em um cenário sem banco separado. Ela também apresenta configurações com MySQL e PostgreSQL. A escolha deve acompanhar o porte e a rotina operacional. SQLite pode simplificar um início pequeno, enquanto uma operação com mais usuários, integrações ou exigências de recuperação precisa ser avaliada com cuidado, incluindo como o banco entrará no backup.

Um servidor Git auto-hospedado substitui GitHub ou GitLab.com?

Pode substituir para alguns fluxos, especialmente repositórios privados e trabalho interno. Não substitui automaticamente a conveniência operacional de um serviço gerenciado, a colaboração pública ampla ou recursos que sua equipe já usa. A escolha não é binária: algumas equipes mantêm SaaS para projetos públicos e uma forge própria para repositórios internos. O melhor arranjo é o que sua equipe consegue operar e recuperar.

Conclusão: escolha a operação que você consegue recuperar

Gitea, Forgejo e GitLab atendem a perfis diferentes. Para solo builders e equipes pequenas, Gitea ou Forgejo tendem a ser escolhas mais proporcionais quando há disciplina de backup, atualização e controle de acesso. GitLab justifica sua infraestrutura quando a plataforma integrada será usada de verdade.

A melhor VPS não compensa um servidor sem responsável. Comece com uma carga compatível, documente a recuperação e só então aumente CI, LFS ou integrações. Esse é o limite prático entre ter um Git próprio e ter Autonomia Operável.