Gitea self-hosted no Brasil: qual VPS escolher?

Resposta direta

Para rodar Gitea self-hosted no Brasil com boa experiência para um time pequeno, comece com uma VPS de 2 vCPUs, 4 GB de RAM, 60 a 80 GB de SSD ou NVMe, backup externo diário e firewall liberando apenas SSH, HTTP e HTTPS. Em ambientes de produção com muitos repositórios, pull requests frequentes e runners de CI separados, faz sentido subir para 4 vCPUs, 8 GB de RAM e 160 GB ou mais de disco rápido. O Gitea é mais leve que plataformas como GitLab, mas o gargalo costuma aparecer no armazenamento, nas operações Git via SSH e no banco de dados. Para equipes brasileiras, escolher datacenter no Brasil ou próximo do público reduz latência em clone, push, pull e navegação pela interface web.

Resumo rápido

• Gitea é uma boa opção self-hosted para times que querem controle sobre repositórios Git sem operar uma suíte pesada.
• Para produção pequena, use pelo menos 2 vCPUs, 4 GB de RAM e 60 GB de SSD ou NVMe.
• Disco rápido importa em clone, push, compactação de objetos Git, busca interna e backup.
• Banco externo como PostgreSQL ou MySQL é mais indicado que SQLite quando há vários usuários.
• Backups precisam incluir repositórios, banco de dados, anexos, arquivos LFS, configuração e chaves.
• Firewall, SSH com chave, HTTPS e atualização frequente são requisitos básicos, não extras.
• CI deve rodar em servidor separado quando os jobs consomem CPU ou memória de forma intensa.

Por que hospedar Gitea em VPS no Brasil

Hospedar Gitea em uma VPS no Brasil faz sentido quando a equipe quer manter o controle dos repositórios, das permissões, dos backups e da política de acesso. O Gitea entrega interface web para Git, issues, pull requests, releases, wiki, webhooks e integração com runners, mas consome bem menos recursos que uma instalação típica de GitLab. Em times pequenos, isso muda bastante a conta de infraestrutura. Um servidor que seria apertado para GitLab pode rodar Gitea com folga, desde que o disco e o backup sejam tratados com seriedade.

O ponto central é soberania operacional. Se a empresa trabalha com código sensível, projetos de clientes, automações internas ou bibliotecas privadas, manter o Git em servidor próprio reduz dependência de plataformas externas. Não elimina responsabilidade, claro. Você passa a cuidar de atualização, logs, certificados, firewall e restauração. A vantagem é decidir onde os dados ficam, quem acessa e como o ambiente evolui.

A localização do datacenter pesa mais do que muita gente imagina. Em navegação web, 150 ms de latência já incomodam. Em Git, a percepção varia conforme o tamanho do repositório e a quantidade de objetos transferidos. Um clone inicial de 2 GB sempre dependerá de banda, mas pushes pequenos, fetches frequentes e abertura de pull requests ficam mais agradáveis quando o servidor está em São Paulo, Fortaleza ou em outra região próxima dos usuários brasileiros. Para equipes distribuídas entre Brasil, América Latina e Estados Unidos, Miami pode ser uma alternativa intermediária, mas isso precisa ser medido com ping, traceroute e testes reais.

Também há um fator de custo previsível. Uma VPS com recursos fixos facilita estimar gastos mensais, principalmente quando o tráfego é moderado e os repositórios não geram transferência massiva. Ainda assim, não publique comparativo de preço sem revisão humana, porque valores, promoções, banda e condições de renovação mudam com frequência. No contexto brasileiro, provedores locais e globais podem atender bem, incluindo opções como LetsCloud, DigitalOcean, Vultr, Linode ou AWS Lightsail, desde que região, storage, backup e suporte sejam verificados nas páginas oficiais antes da contratação.

Como dimensionar CPU, RAM e processos do Gitea

O Gitea é econômico, mas não é mágico. O consumo real depende de usuários ativos, tamanho dos repositórios, número de operações Git simultâneas, webhooks, busca, anexos, Git LFS e banco de dados. Para um dev solo ou uma microequipe com 5 a 10 repositórios privados, 1 vCPU e 1 GB de RAM podem funcionar em laboratório. Em produção, porém, essa configuração deixa pouca margem para atualizações, backup, banco e picos de uso. O ponto de partida mais seguro é 2 vCPUs e 4 GB de RAM.

Com 2 vCPUs, o servidor consegue lidar melhor com compactação de objetos Git, requisições web, SSH, banco de dados e tarefas de manutenção. A RAM de 4 GB permite rodar Gitea, PostgreSQL ou MySQL, Nginx ou Caddy, agente de monitoramento e rotinas de backup sem depender de swap o tempo todo. Uma swap pequena, como 2 GB, pode ajudar em picos, mas não deve virar muleta. Se o servidor começa a usar swap continuamente, a experiência degrada e o disco sofre.

Para um time de 10 a 30 pessoas, com dezenas de repositórios e pull requests diários, considere 4 vCPUs e 8 GB de RAM. Esse perfil costuma ter webhooks para deploy, integrações com chat, builds disparados por push e anexos em issues. Mesmo que os runners fiquem fora do servidor principal, o Gitea ainda processa eventos, autenticação, permissões e consultas ao banco. Se você pretende usar runners no mesmo host, repense. Jobs de CI podem compilar imagens Docker, instalar dependências, rodar testes e consumir 100 por cento de CPU por vários minutos. Nesse caso, é melhor separar a camada de código da camada de execução, como explicamos no artigo sobre VPS para GitLab Runner e CI/CD.

Há sinais claros de subdimensionamento. Interface web lenta ao abrir repositórios grandes, clone via SSH oscilando, filas internas acumulando, banco com alto tempo de resposta e load average acima do número de vCPUs por longos períodos indicam falta de recurso ou gargalo de disco. Use ferramentas simples como htop, iotop, df -h, journalctl e métricas do provedor. Uma configuração prática para começar em produção pequena é Gitea com limite de processos adequado, PostgreSQL local, Nginx como reverse proxy e systemd controlando reinício automático. Em produção maior, separar banco, runners e storage de backup reduz risco operacional.

Disco NVMe, banco de dados e repositórios Git

Em Gitea, o disco não guarda apenas arquivos estáticos. Ele armazena objetos Git, índices, anexos, avatares, releases, logs, chaves, arquivos LFS e, em muitas instalações, o banco de dados. Por isso, escolher entre SSD SATA, SSD virtualizado e NVMe não é só detalhe de marketing. NVMe tende a entregar menor latência e mais IOPS, mas a disponibilidade varia por provedor, plano e localidade. Antes de afirmar que um plano tem NVMe, confira a documentação oficial ou a página comercial atualizada.

O impacto aparece em operações comuns. Um push para um repositório com muitos arquivos pequenos exige escrita e atualização de objetos. Um clone de repositório grande combina leitura sequencial, leitura aleatória e compressão. A interface web também acessa metadados, branches, commits e diffs. Se o banco está no mesmo disco, consultas e transações competem com os repositórios. Em times pequenos, isso não costuma ser dramático. Em times com muitos projetos, vira gargalo antes da CPU.

Para produção básica, reserve 60 a 80 GB de disco mesmo que os repositórios atuais ocupem apenas 10 GB. Git cresce com histórico, branches, tags, releases e anexos. Se você usa Git LFS para binários, imagens, datasets ou artefatos de build, o crescimento pode ser muito rápido. Um time que sobe arquivos de 200 MB por release pode consumir dezenas de gigabytes em poucos meses. Configure alertas quando o uso passar de 70 por cento e planeje expansão antes de chegar a 90 por cento.

A escolha do banco também muda a operação. SQLite é simples e serve para testes, dev solo e instalações pequenas com baixa concorrência. Para equipe real, PostgreSQL ou MySQL são escolhas mais robustas. PostgreSQL costuma ser uma boa combinação para Gitea por estabilidade, concorrência e ferramentas de backup. Um exemplo prático: Gitea em Docker, PostgreSQL em container separado com volume persistente, Nginx no host e backup diário com pg_dump. Se você já opera serviços containerizados, o guia de VPS para Docker ajuda a pensar em volumes, logs, atualizações e limites de recurso sem misturar tudo no mesmo diretório.

Também pense no layout. Separe dados do Gitea em um caminho previsível, como /var/lib/gitea ou um volume Docker nomeado. Mantenha logs com rotação. Evite guardar backups no mesmo disco como única cópia. Um snapshot do provedor é útil para restauração rápida, mas não substitui backup externo versionado. Se o disco corromper, a conta for comprometida ou uma exclusão acidental sincronizar para o snapshot, você precisa de outra cópia.

Backups, snapshots e plano de restauração

Backup de Gitea precisa ser pensado como recuperação de serviço, não como uma pasta copiada de vez em quando. Para restaurar uma instância de forma confiável, você precisa dos repositórios Git, banco de dados, arquivos LFS, anexos, avatares, configuração, chaves SSH, certificados ou configuração do reverse proxy e, se aplicável, segredos usados em webhooks. Perder qualquer uma dessas partes pode transformar um incidente simples em horas de reconstrução manual.

Uma estratégia prática para time pequeno combina três camadas. A primeira é dump diário do banco, por exemplo pg_dump para PostgreSQL ou mysqldump para MySQL. A segunda é cópia incremental dos dados do Gitea para storage externo, usando restic, borg, rclone ou ferramenta equivalente. A terceira é snapshot do servidor antes de atualizações importantes. Snapshot ajuda em rollback rápido, mas depende do provedor e deve ser confirmado por plano. Backup externo ajuda quando o problema afeta o servidor inteiro, a conta ou o volume principal.

A frequência depende do risco aceitável. Se a equipe faz pushes o dia inteiro, backup diário pode perder trabalho demais. Nesse caso, rode dump de banco a cada 6 horas e sincronização incremental de repositórios em janelas menores. Para dev solo, backup diário com retenção de 7 diários, 4 semanais e 6 mensais costuma ser suficiente. Para produção com cliente final, defina RPO e RTO. RPO responde quanto dado você aceita perder. RTO responde quanto tempo você aceita ficar fora do ar.

Teste de restauração é o ponto que separa backup real de sensação de segurança. Uma vez por mês, suba uma VPS temporária, instale a mesma versão do Gitea, restaure banco e dados, aponte um domínio de teste e faça login com um usuário comum. Depois clone um repositório, abra uma issue, confira anexos e valide pull requests antigos. Esse exercício revela caminhos errados, permissões quebradas e dumps incompletos antes do dia do incidente.

Para operação mais organizada, documente comandos. Um exemplo simples de rotina inclui parar o serviço, fazer dump do banco, compactar diretórios de dados, enviar para storage externo e reiniciar. Em ambientes com alta atividade, prefira backups consistentes sem longas interrupções, usando dump transacional do banco e ferramentas que lidem bem com arquivos em uso. O objetivo não é criar uma arquitetura enorme, é garantir que o repositório da empresa não dependa de uma única máquina sem plano de volta.

Segurança para Gitea self-hosted em produção

Gitea exposto na internet precisa de uma superfície de ataque pequena. Comece pelo SSH. Desative login por senha, use chaves fortes, troque ou proteja a porta se isso fizer sentido no seu contexto e limite usuários com acesso ao servidor. O Git via SSH continuará funcionando para desenvolvedores, mas o acesso administrativo ao sistema operacional deve ser restrito. Separar usuário do serviço, permissões de diretório e chaves reduz o impacto de erro humano.

No firewall, libere apenas o necessário. Em uma instalação comum, as portas públicas serão 22 para SSH, 80 para emissão e renovação de certificados e 443 para HTTPS. Se o Gitea escuta internamente na porta 3000, essa porta não precisa ficar aberta para a internet. Use Nginx, Caddy ou Traefik como reverse proxy. Caddy simplifica certificados TLS automáticos. Nginx dá controle fino e é muito conhecido por equipes de infraestrutura. Qualquer escolha funciona, desde que HTTPS esteja ativo e redirecionamento de HTTP para HTTPS esteja configurado.

Atualização também é segurança. Acompanhe releases do Gitea, do sistema operacional, do banco e do Docker, se usado. Não aplique atualização crítica diretamente em produção sem snapshot ou backup recente. Um bom fluxo é testar em uma instância menor com cópia anonimizada ou backup restaurado, validar login, clone, push, webhooks e interface administrativa, depois atualizar produção em janela combinada. Para times pequenos, isso pode parecer burocracia, mas evita perder uma manhã inteira por incompatibilidade simples.

Na camada do Gitea, revise cadastro público, autenticação, permissões padrão e políticas de organização. Se a instância é privada, desative registro aberto. Use 2FA para administradores. Remova usuários antigos. Rotacione tokens de acesso e webhooks que não são mais usados. Configure limite de tamanho para anexos e repositórios se o disco é pequeno. Se houver integração com runners externos, trate tokens como segredos. Nunca cole chave privada, token de API ou senha em arquivo de exemplo publicado.

Logs ajudam a detectar problemas. Monitore tentativas de login, falhas de SSH, uso anormal de CPU, aumento repentino de tráfego e crescimento inesperado do diretório de dados. Ferramentas simples como fail2ban, journald, UFW, alertas do provedor e checagem HTTP já reduzem bastante o risco. Segurança em Gitea self-hosted não precisa começar complexa. Precisa começar consistente.

Docker, reverse proxy e operação do serviço

Rodar Gitea em Docker é uma escolha popular porque facilita atualização, isolamento e reprodução do ambiente. Um docker-compose simples pode declarar Gitea, PostgreSQL, volumes persistentes e rede interna. O reverse proxy pode ficar no host ou em outro container. O ponto crítico é não confundir container descartável com dado descartável. Tudo que importa precisa estar em volume persistente, com backup e permissões corretas.

Um desenho comum usa Gitea escutando internamente em 3000, PostgreSQL em 5432 apenas na rede Docker, Nginx ou Caddy publicando HTTPS e volumes separados para /data do Gitea e dados do banco. Em uma VPS de 2 vCPUs e 4 GB, defina limites razoáveis de logs e acompanhe consumo. Containers sem rotação de log podem ocupar gigabytes sem aviso. Configure json-file com max-size e max-file ou use journald com política clara.

Docker ajuda muito em atualização. Você altera a tag da imagem, executa pull, recria o container e mantém os volumes. Mesmo assim, leia as notas da versão antes de subir. Mudanças de banco, migrações internas e alterações de configuração podem exigir cuidado. Em produção, evite tag latest. Use uma versão específica, por exemplo 1.22.x ou a versão estável recomendada no momento da implantação, e atualize de forma planejada.

Se o ambiente já usa automação de build, não coloque tudo na mesma VPS por comodidade. Runners de GitHub Actions self-hosted, builds Docker e testes automatizados competem com Gitea por CPU, RAM e disco. Um build Node, Java ou Go pode consumir 2 a 4 GB de RAM sozinho. Para esse cenário, vale separar o servidor Git do servidor de execução. O artigo sobre Cloud Server para GitHub Actions self-hosted runner aprofunda essa divisão e ajuda a evitar que um pipeline derrube a interface do Gitea.

Monitoramento não precisa começar com uma pilha enorme. Para uma primeira versão, configure uptime externo, alerta de disco, alerta de uso de RAM, checagem de certificado TLS e backup com notificação de sucesso ou falha. Depois, se o time crescer, adicione Prometheus, Grafana, Loki ou outra stack. O melhor monitoramento é aquele que alguém olha e entende. Um dashboard bonito que não dispara alerta quando o disco chega a 95 por cento não protege seus repositórios.

Tabela comparativa de perfis de VPS para Gitea

A escolha da VPS para Gitea self-hosted no Brasil fica mais simples quando você pensa por perfil de uso, não por menor preço. O mesmo Gitea pode atender um freelancer, uma agência com 15 pessoas ou uma software house com muitos projetos, mas o dimensionamento muda. A tabela abaixo usa configurações de referência, não planos comerciais fechados. Preço, localidade, bandwidth, tipo de storage e recursos como snapshots precisam ser confirmados no site oficial do provedor antes da publicação ou contratação.

Perfil de uso	Configuração recomendada	Banco de dados	Disco e backup	Quando faz sentido
Dev solo ou laboratório	1 a 2 vCPUs, 2 GB RAM, 40 GB SSD	SQLite ou PostgreSQL local	Backup diário externo, snapshot antes de updates	Repositórios pessoais, poucos pushes por dia, baixo risco operacional
Time pequeno em produção	2 vCPUs, 4 GB RAM, 60 a 80 GB SSD ou NVMe	PostgreSQL ou MySQL local	Backup diário, retenção semanal, alerta em 70 por cento de disco	5 a 15 usuários, dezenas de repositórios, issues e pull requests frequentes
Equipe com CI separado	4 vCPUs, 8 GB RAM, 160 GB NVMe quando disponível	PostgreSQL local ou gerenciado	Backups a cada 6 a 12 horas, snapshots planejados	15 a 40 usuários, webhooks, runners externos e repositórios maiores
Produção crítica	4 a 8 vCPUs, 8 a 16 GB RAM, 250 GB ou mais	Banco separado ou gerenciado	Backup versionado, teste mensal de restore, monitoramento ativo	Código de clientes, múltiplas organizações, exigência de recuperação rápida

Na prática, a configuração intermediária atende a maioria dos times que procuram Gitea. Ela dá folga para banco, reverse proxy, atualizações e crescimento moderado. Se o time tem muitos artefatos binários, Git LFS ou releases pesadas, aumente disco antes de aumentar CPU. Se a interface fica lenta com disco pouco usado, investigue banco, logs, DNS, latência e proxy antes de trocar de provedor.

Sobre provedores, compare região, tipo de disco, política de backup, facilidade de snapshot, limites de tráfego, suporte e forma de cobrança. LetsCloud pode ser avaliada quando a prioridade é infraestrutura com presença relevante para o público brasileiro, mas recursos como NVMe, localidades específicas, snapshots, backup automático e condições comerciais devem ser confirmados por plano. Provedores globais como DigitalOcean, Vultr, Linode, AWS Lightsail, Google Cloud e Azure também podem atender, cada um com modelo operacional diferente. A decisão boa é a que combina latência, previsibilidade, backup e capacidade de restauração.

Recomendações por perfil

Dev solo

Para um dev solo, o objetivo é manter o ambiente simples e barato sem abrir mão de backup. Uma VPS de 1 a 2 vCPUs, 2 GB de RAM e 40 GB de SSD pode rodar Gitea com tranquilidade se os repositórios forem pequenos e o acesso for baixo. Use Docker Compose, Caddy para HTTPS automático e PostgreSQL se você já quer uma base mais parecida com produção. Se preferir reduzir manutenção, SQLite funciona, mas faça backup consistente do arquivo de banco e dos repositórios. Configure UFW, SSH por chave, registro fechado e backup diário para um destino externo. Não deixe a única cópia do seu código em um volume sem restauração testada.

Time pequeno

Para um time de 5 a 15 pessoas, escolha 2 vCPUs, 4 GB de RAM e 60 a 80 GB de SSD ou NVMe. Esse perfil lida bem com pull requests, issues, webhooks, releases e vários repositórios privados. PostgreSQL local é uma boa escolha, desde que tenha backup automatizado e monitoramento de disco. Separe runners de CI em outra VPS ou cloud instance, principalmente se os pipelines compilam imagens Docker ou rodam testes pesados. Também vale padronizar permissões por organização, exigir 2FA para administradores e revisar tokens mensalmente. O ganho do Gitea aparece quando a equipe tem autonomia, mas essa autonomia precisa vir acompanhada de rotina operacional.

Produção com múltiplos projetos

Para produção com múltiplos clientes, squads ou projetos críticos, comece em 4 vCPUs, 8 GB de RAM e 160 GB de disco rápido, preferencialmente NVMe quando disponível no plano e na localidade. Avalie banco separado se o uso crescer ou se o backup precisar de janelas menores. Defina RPO e RTO por escrito, teste restauração mensalmente e monitore CPU, RAM, I/O, certificados, filas e crescimento de dados. Nesse perfil, snapshots são úteis, mas backup versionado externo é obrigatório. Se o time usa CI intensivo, mantenha runners isolados e com autoscaling quando possível. O servidor Gitea deve continuar responsivo mesmo quando pipelines estão em pico.