{"url":"https://runzos.com/gitea-vs-github-gitlab-2026/","slug":"gitea-vs-github-gitlab-2026","contentType":"artigo","intent":"aprender","title":"Gitea vs GitHub vs GitLab em 2026: quando vale sair do SaaS e hospedar seu Git?","metaDescription":"Gitea vs GitHub vs GitLab: veja quando uma VPS faz sentido, os riscos de operar Git próprio e como migrar sem perder sua colaboração. Compare os cenários.","publishedAt":"2026-09-28T11:15:44.000Z","updatedAt":"2026-09-28T11:15:44.000Z","contentText":"Auto-hospedar Git vale quando você aceita operar uma infraestrutura crítica, não apenas subir um container. Para quem não tem backup testado, rotina de atualização, acesso SSH de contingência e capacidade de restaurar a forge, GitHub.com ou GitLab.com costuma ser a decisão mais segura. Gitea ou Forgejo em VPS fazem sentido quando controle, integração local ou custo previsível justificam esse trabalho. A pergunta não é apenas “Gitea, GitHub ou GitLab?”. Ela é: quem assume o incidente quando o repositório, o runner ou o volume de dados falham? Git é distribuído, mas o trabalho de uma equipe não mora só no clone local. Issues, pull requests, permissões, releases, webhooks e pipelines também fazem parte do produto. Nossa leitura é simples: self-hosted Git não é medalha de maturidade técnica. É uma troca consciente entre serviço gerido e responsabilidade operacional. Esse comparativo separa quatro caminhos que costumam ser colocados no mesmo saco: GitHub.com, GitLab.com, GitLab Self-Managed e Gitea ou Forgejo em servidor próprio. Comparação de bate-pronto Critério GitHub.com GitLab.com GitLab Self-Managed Gitea ou Forgejo Deployment SaaS do GitHub SaaS do GitLab Infraestrutura da organização VPS ou infraestrutura própria CI/CD GitHub Actions; runners hospedados ou próprios GitLab CI/CD GitLab CI/CD e runners Actions com runner instalado separadamente Responsabilidade operacional Menor na forge; runner próprio continua sob sua gestão Menor na forge; projetos e automações ainda exigem configuração Alta: capacidade, storage, backup e atualização Alta: forge, volumes, backup, patches e runner Migração Exige inventário além do espelho Git Importador de GitHub e procedimentos próprios por origem Acrescenta a operação da instância ao plano Gitea tem migração nativa de GitHub; outros caminhos exigem validação Melhor encaixe Ecossistema e serviço gerido Fluxo GitLab sem administrar instância Requisito institucional com operação estruturada Equipe pequena com VPS e restore já dominados Resposta curta: quando ficar no SaaS e quando hospedar Fique em GitHub.com ou GitLab.com se você não consegue reservar tempo para corrigir atualização, recuperar backup e investigar um problema de rede. O SaaS não elimina falhas, mas terceiriza uma parte relevante da operação da forge. Para solo builders, isso frequentemente custa menos do que parar um deploy para reconstruir um serviço interno. Uma forge em VPS passa a ser racional em três cenários. O primeiro é uma exigência concreta de controle sobre rede, dados ou integrações internas. O segundo é uma equipe que já mantém VPS, monitoramento e backup fora da máquina principal. O terceiro é um custo por assento ou uma arquitetura de automação que realmente justifica absorver a operação. GitLab Self-Managed e GitHub Enterprise Server atendem outra faixa de necessidade. O GitHub diferencia Enterprise Cloud, hospedado por ele, de Enterprise Server, auto-hospedado pelo cliente. O segundo é um appliance virtual, não um “GitHub grátis para instalar em Docker”. A própria documentação informa que mudar o sistema operacional subjacente ou instalar software de terceiros nele não é suportado. GitHub Enterprise Server é um appliance virtual voltado a demandas corporativas, não a uma VPS pequena para projeto pessoal. Já Gitea e Forgejo são forges auto-hospedadas mais diretas para esse cenário. A instalação do Gitea com Docker Compose usa volumes persistentes e termina a configuração inicial no navegador. Isso reduz a barreira de entrada, mas não reduz a responsabilidade depois do primeiro login. Gitea, Forgejo, GitHub e GitLab não são a mesma categoria GitHub.com versus GitHub Enterprise Server GitHub.com é um serviço SaaS. Você usa a plataforma, os recursos de colaboração e o ecossistema sem administrar a infraestrutura da forge. GitHub Actions também oferece runners hospedados pelo GitHub e opção de runners próprios. O uso de runner próprio pode ampliar seu controle, mas adiciona uma máquina que executa código e precisa de isolamento e atualização. GitHub Enterprise Server, por sua vez, é a opção auto-hospedada do GitHub Enterprise. Ele existe para organizações que precisam executar o produto na própria infraestrutura e definir controles como firewall, rede, IAM, monitoramento e VPN. Isso não o transforma em alternativa econômica para toda equipe. É uma escolha de ambiente e governança, com um modelo operacional corporativo. GitLab.com versus GitLab Self-Managed GitLab.com segue a lógica SaaS. GitLab Self-Managed desloca a plataforma para sua infraestrutura. A diferença é importante porque os requisitos oficiais do GitLab Self-Managed variam conforme a carga. Para nó único, a documentação traz baseline de 8 vCPU e, em ambiente de memória restrita, pelo menos 8 GB de RAM. Isso não é dimensionamento final para qualquer projeto, mas mostra que a plataforma exige mais planejamento do que uma forge leve. A conta também cresce com o uso. O GitLab recomenda storage compatível com S3 para instalações distribuídas e para todas as instalações. Nesse armazenamento entram LFS, artefatos de CI/CD, uploads, registry e backups. Se sua equipe usa pipelines, imagens e pacotes, não compare apenas o tamanho atual dos repositórios. Gitea e Forgejo: origem comum, decisões diferentes Gitea e Forgejo são forges auto-hospedadas que cobrem Git por SSH e HTTP, API, webhooks e automação. Forgejo se tornou hard fork no início de 2024, segundo a página comparativa mantida pelo próprio projeto. A diferença envolve governança, política de software livre e processo comunitário. Essa é uma fonte interessada, portanto não prova que Forgejo seja tecnicamente superior. A visão geral do Gitea Actions também deixa claro que a automação é uma camada própria da operação. A decisão prática não precisa virar guerra de tribos. Se a governança comunitária e a direção do projeto importam para sua organização, Forgejo é uma escolha legítima. Se Gitea atende seu fluxo e sua equipe já conhece a ferramenta, isso também é válido. Em ambos os casos, confira a versão usada, o calendário de patches e a compatibilidade do seu pipeline antes de migrar tudo. Gitea e Forgejo compartilham origem, mas seguiram decisões diferentes de governança e comunidade. Para quem é cada caminho? Para quem é GitHub.com GitHub.com é a escolha padrão para Rafael quando o objetivo é entregar produto, não administrar uma forge. Ele também serve bem a projetos que dependem do ecossistema do GitHub e aceitam serviço gerido. Se houver runner próprio, essa máquina ainda precisa de isolamento e atualização. Para quem é GitLab.com e GitLab Self-Managed GitLab.com encaixa em times que querem o fluxo da plataforma sem operar a instância. GitLab Self-Managed só entra quando compliance, rede restrita ou integração interna são exigências reais e a organização já tem responsável por capacidade, storage, backup e atualização. Para quem são Gitea e Forgejo Gitea ou Forgejo servem ao solo builder e à equipe pequena que já operam VPS, Docker, SSH e backup externo. Forgejo também pode encaixar quando governança comunitária importa. Nenhuma das duas escolhas dispensa piloto de migração, runner e restore. Onde cada caminho ganha GitHub.com ganha quando ecossistema e disponibilidade gerida valem mais que controlar a forge. GitLab.com ganha para quem quer usar GitLab sem absorver a operação da instância. GitLab Self-Managed ganha quando requisito institucional justifica uma plataforma integrada e a operação já existe. Gitea ou Forgejo ganham quando controle deliberado e uma forge mais direta compensam cuidar de VPS, dados e automação. O vencedor padrão para a persona principal é SaaS. Gitea ou Forgejo só vencem quando a rotina de VPS e recuperação já é parte do trabalho, não uma intenção para depois da migração. Custo total: assento SaaS versus Custo de Plantão Chamamos de Custo de Plantão a parte da conta que não aparece na tela de contratação. Ela reúne a VPS, o domínio, o volume persistente, backup externo, storage para artefatos, atualização, monitoramento e o tempo de alguém que precisa reagir quando o serviço para. Preços de plano, franquias de CI e armazenamento mudam. Por isso, comparar uma mensalidade fixa com uma VPS de entrada gera uma conclusão frágil. O cenário correto inclui o uso real de Actions ou pipelines, crescimento de LFS, registry, retenção de artefatos e a disponibilidade de quem faz manutenção. No GitLab Self-Managed, essa diferença fica clara. O requisito oficial varia por carga e o uso de object storage pode concentrar LFS, artefatos, uploads, registry e backups. Além disso, se blobs estiverem em object storage, o comando de backup do GitLab não os inclui automaticamente: é preciso habilitar o backup no provedor de storage. A documentação de backup do GitLab merece entrar no seu plano antes da migração, não depois de uma falha. Gitea e Forgejo não têm uma baseline oficial única de RAM nesta pesquisa. Evite repetir números genéricos de fóruns como se fossem recomendação do projeto. Comece pelo seu volume de repositórios, usuários, LFS, webhooks e CI. Depois, acompanhe consumo e deixe margem para atualização e recuperação. Uma VPS é recomendação contextual apenas depois desse diagnóstico. Se você já consegue manter a operação, veja uma VPS para rodar sua forge e apps self-hosted. Consulte condições, preço e disponibilidade diretamente nessa rota antes de contratar. A VPS é a parte visível; a operação contínua e a recuperação formam o Custo de Plantão. CI/CD, runners e integrações: o que quebra numa migração apressada CI não é um detalhe de interface. Ele executa código, acessa segredos e entrega artefatos. Em Gitea, o Gitea Runner executa os workflows separadamente da forge. A documentação alerta para não usar runner não confiável nem oferecê-lo a repositórios, organizações ou instâncias não confiáveis. Forgejo segue a mesma arquitetura: o Forgejo Runner busca e executa workflows, sendo instalado e configurado à parte. Esse desenho exige duas decisões: onde o runner vai rodar e quais projetos podem enviar jobs para ele. Tratar o runner como simples extensão do painel mistura execução de código com a interface que guarda colaboração e permissões. Não houve teste próprio do Runzos, benchmark nem screenshot de instância para este comparativo. Os requisitos de documentação indicam o que sua equipe deve validar; eles não substituem um piloto com seus workflows, seus dados e seu plano de restauração. Outro erro comum é assumir que Actions compatível significa Actions idêntico. Gitea Actions suporta apenas um subconjunto de permission scopes de GitHub Actions. checks, deployments, id-token, security-events e pages, por exemplo, aparecem como não suportados na documentação. As limitações documentadas de Gitea Actions não impedem uso, mas obrigam um piloto por workflow. Faça esse piloto com um repositório não crítico. Rode build, teste, publicação de artefato, webhook e integração externa. Liste secrets, variáveis, permissões e dependências de marketplace. Só depois decida se vale adaptar YAML, trocar action ou manter aquele projeto em SaaS. Como migrar sem descobrir tarde que clone não é recuperação “Clone Não é Recuperação” seria uma boa frase para este momento, mas o conceito central deste artigo é outro: Custo de Plantão. Ainda assim, a ideia importa. Um espelho Git preserva commits e branches. Ele não garante que issues, pull requests, comentários, wiki, releases, webhooks, permissões, pacotes e configurações de CI cheguem ao destino do jeito que sua equipe precisa. Gitea possui formulário nativo para migrar de GitHub. Para incluir issues e pull requests, a documentação pede ao menos username. Para GitLab, ela direciona o leitor a uma ferramenta não afiliada. Isso basta para mostrar que migração depende da origem e do objeto envolvido. GitLab também tem importador de GitHub, enquanto um GitHub Enterprise Server auto-hospedado muda o procedimento e pode exigir endpoint de API com token de escopo api. Antes de desligar a origem, monte um inventário e teste uma amostra representativa. Item O que validar Responsável Espelho Git Branches, tags e clone por SSH e HTTPS Responsável técnico Colaboração Issues, PRs ou MRs, comentários, wiki e releases Dono do projeto Automação Webhooks, secrets, variáveis, YAML e artefatos Responsável por CI/CD Dados grandes LFS, registry, uploads e retenção Responsável pela plataforma Recuperação Backup externo, restauração, clone e acesso à issue Responsável de operação Contingência Acesso SSH, chaves, firewall e documentação do incidente Responsável de infraestrutura O teste de restore é o divisor entre cópia e plano de recuperação. Em staging, restaure banco e diretório ou volume de dados. Depois, confirme clone e acesso a uma issue. Não há teste próprio do Runzos para prometer tempo de recuperação, então trate o resultado como uma verificação que sua equipe precisa executar. Commits e branches são só uma parte; a migração precisa testar colaboração, automações, permissões e recuperação antes do corte. Discurso oficial versus evidência operacional O GitHub apresenta Enterprise Server como caminho para organizações que precisam rodar na própria infraestrutura e definir controles de firewall, rede, IAM, monitoramento e VPN. O discurso é coerente: controle pode ser necessário quando há requisito institucional. A evidência operacional limita a interpretação. GitLab documenta requisitos variáveis de CPU, memória, storage e backup. Gitea e Forgejo separam a execução de CI em runners independentes. Logo, controle de dados não remove trabalho. Ele transfere o trabalho para sua organização. A reconciliação do Runzos é: escolha a camada que você consegue recuperar numa manhã ruim. Para um solo builder sem rotina de incidentes, SaaS é controle de risco terceirizado. Para uma operação com soberania, automação local, custo por assento ou restrição de rede realmente relevantes, Gitea ou Forgejo em VPS pode ser uma decisão racional. GitLab Self-Managed e GHES entram quando a exigência e a capacidade operacional já existem. FAQ: dúvidas sobre Gitea, GitHub e GitLab Gitea e Forgejo substituem GitHub Actions? Podem substituir parte dos fluxos, mas não devem ser tratados como equivalentes automáticos. Gitea Actions usa runner separado e suporta apenas parte das permissões documentadas no GitHub Actions. Forgejo também depende de runner próprio. O caminho seguro é testar cada workflow, cada secret e cada integração antes de desativar o pipeline original. GitHub pode ser auto-hospedado de graça em uma VPS? Não no sentido de instalar GitHub.com como um container gratuito. O produto auto-hospedado do GitHub Enterprise é o GitHub Enterprise Server, distribuído como appliance virtual. Ele atende uma necessidade enterprise específica e não foi documentado como alternativa leve para VPS de projeto pessoal. Quanto de VPS preciso para GitLab Self-Managed? O GitLab informa que o requisito varia conforme carga. Para nó único, sua documentação traz baseline de 8 vCPU e, em ambiente com memória restrita, pelo menos 8 GB de RAM. Use isso como ponto de partida oficial, não como garantia. Projetos com CI, registry, LFS e muitos usuários precisam considerar storage e operação adicionais. Posso migrar só com git clone --mirror? O espelho resolve a camada Git, como commits, branches e tags. Ele não prova migração completa de issues, pull requests, comentários, wiki, releases, webhooks, permissões e pipelines. Faça inventário desses itens e execute um piloto em repositório não crítico antes do corte definitivo. Auto-hospedar Git é mais seguro? Não automaticamente. A infraestrutura própria pode permitir controles de rede, IAM e monitoramento adequados à sua organização. Porém, patch, backup, firewall, runner e recuperação passam a depender da sua operação. Segurança é resultado de configuração e rotina, não do local onde o container roda. Veredito: a escolha certa é a que você consegue recuperar GitHub.com e GitLab.com são boas escolhas quando produtividade e disponibilidade gerida pesam mais do que controlar cada camada. Gitea e Forgejo fazem sentido para quem já aceita o Custo de Plantão e quer uma forge leve sob gestão própria. GitLab Self-Managed e GitHub Enterprise Server pertencem a cenários com exigência institucional e operação compatível. Não migre por ideologia nem por uma comparação rasa de mensalidade. Migre quando houver motivo concreto e um plano testado para backup, restore, runner, acesso e atualização. A VPS é parte da resposta, não a resposta inteira. ★","category":{"name":"Ferramentas Dev","slug":"ferramentas-dev"},"tags":[{"name":"Gitea","slug":"gitea"},{"name":"GitHub","slug":"github"},{"name":"GitLab","slug":"gitlab"},{"name":"Git auto-hospedado","slug":"git-auto-hospedado"},{"name":"VPS","slug":"vps"},{"name":"DevOps","slug":"devops"}],"author":{"name":"Maicon Ramos","slug":"maicon_ramos"},"faq":[{"question":"Gitea e Forgejo substituem GitHub Actions?","answer":"Podem substituir parte dos fluxos, mas não são equivalentes automáticos. Gitea Actions e Forgejo Runner exigem runner separado, e permissões ou actions podem divergir. Teste cada workflow, secret e integração antes de desativar o pipeline original."},{"question":"GitHub pode ser auto-hospedado de graça em uma VPS?","answer":"Não como uma instalação gratuita do GitHub.com. O produto auto-hospedado é o GitHub Enterprise Server, distribuído como appliance virtual para necessidades corporativas específicas."},{"question":"Quanto de VPS preciso para GitLab Self-Managed?","answer":"A necessidade varia conforme a carga. A documentação traz baseline de 8 vCPU para nó único e pelo menos 8 GB de RAM em ambiente com memória restrita. CI, registry, LFS, storage e número de usuários aumentam a necessidade operacional."},{"question":"Posso migrar só com git clone --mirror?","answer":"O espelho preserva commits, branches e tags, mas não comprova a migração de issues, pull requests, comentários, wiki, releases, webhooks, permissões e pipelines. Faça inventário e piloto antes do corte."},{"question":"Auto-hospedar Git é mais seguro?","answer":"Não automaticamente. A infraestrutura própria permite controles específicos, mas patch, backup, firewall, runner e recuperação passam a depender da sua operação. Segurança resulta de configuração e rotina, não apenas do local do servidor."}]}