Para: devs independentes e pequenos operadores receosos da "exposição acidental de repositório público" e dos incidentes de vazamento de segredos do GitHub, avaliando se devem rodar um servidor Git auto-hospedado (bare git, ou Gitea/Forgejo/GitLab). Nenhum passo de ataque aqui — só a decisão de qual é mais seguro para a sua configuração.
A visão deste site: a auto-hospedagem só funciona se você assumir o que o GitHub fazia
Este site mesmo roda um servidor Git auto-hospedado. Mas o motivo não é só "exposição acidental é assustadora" — é separar o alcance do impacto: um serviço comprometido não pode se propagar para outros. E porque auto-hospedamos, sempre incluímos junto backups externos para um servidor separado, nunca colocar segredos no git e monitoramento automatizado de CVE de dependências. A segurança da auto-hospedagem vem não de "não usar o GitHub", mas de fazer você mesmo o trabalho que o GitHub fazia.
1. O que a auto-hospedagem de fato elimina
Seu receio tem uma base válida. Os clássicos "incidentes públicos" do GitHub simplesmente não podem acontecer em um servidor auto-hospedado.
Repositórios públicos são continuamente rastreados por bots de varredura automatizada. Commite um .env ou uma chave de API por engano e os bots os pegam antes de um humano notar — explorados em minutos é comum (casos reais → uma chave vazou via repositório público e gerou cobrança fraudulenta · um .env inteiro exposto). A auto-hospedagem remove essa superfície pública. "Deveria ser privado mas foi público", "um segredo que você achou ter apagado persistindo em um fork público" — essas classes não podem ocorrer por design. Isso não é um conforto vago; é uma vantagem real.
2. O trabalho que você assume ao auto-hospedar
Este é o cerne. O GitHub cuidava de muita defesa por você por padrão, fora de vista. Auto-hospede e essas defesas não existem a menos que você as construa.
O GitHub cuidava disto
- Bloqueia commits de segredos (proteção de push)
- Alertas automáticos de CVE de dependências (Dependabot)
- Operação do servidor, patches, TLS
- 2FA, acesso granular, logs de auditoria
- Alta disponibilidade, backups redundantes
Agora é trabalho seu
- Adicionar um hook de detecção de segredos pré-commit
- Rodar você mesmo o monitoramento de CVE de dependências (cron)
- Aplicar patches nas vulnerabilidades do próprio servidor Git
- Gestão de chaves = efetivamente todo o controle de acesso
- Dados perdidos continuam perdidos, a menos que você prepare uma restauração
Dois são especialmente fáceis de não notar. Primeiro, um paradoxo: o vazamento de segredo que você mais teme é algo que o GitHub de fato impede por você, por máquina. A proteção de push do GitHub rejeita commits contendo o que parece ser uma chave de API. Um bare git auto-hospedado puro não tem essa verificação. A exposição acidental sumiu, mas o commit acidental não — então, se você auto-hospeda, um hook de segredos pré-commit é obrigatório.
Segundo, o próprio servidor Git vira alvo. Servidores cheios de recursos como o GitLab já tiveram várias vulnerabilidades sérias (execução remota de código não autenticada, ou seja, classe RCE), e um servidor auto-hospedado sem patches vira a porta de entrada. Mais recursos, mais superfície de ataque. Bare git puro + SSH tem a menor superfície; GitLab/Gitea são convenientes mas adicionam o fardo de perseguir patches você mesmo.
3. Como tornar a auto-hospedagem mais segura que o GitHub
O conjunto mínimo que torna a auto-hospedagem de fato — não cosmeticamente — segura. Só com isto "mais seguro que o GitHub" é verdade.
Barre segredos antes do commit
Minimize e aplique patches no servidor Git
Backups externos + uma restauração testada
Chaves separadas, menor privilégio, sem root
Rode você mesmo o monitoramento de CVE de dependências
4. Qual você deveria escolher?
Auto-hospedar não é "profissional" e o GitHub não é "amador". Decida com base em se você consegue continuar operando.
A auto-hospedagem se encaixa (se você atinge o nível)
- você quer remover a própria superfície de exposição pública
- você consegue continuar aplicando patches e fazendo backup do servidor
- você não quer código mantido por um terceiro / quer limitar o alcance do impacto
- você consegue adotar o hook de segredos e o monitoramento de dependências como um pacote
O GitHub pode ser mais seguro
- sem capacidade de continuar aplicando patches/fazendo backup → uma auto-hospedagem negligenciada é o mais perigoso
- você quer se apoiar na defesa automática de proteção de push / Dependabot
- você não consegue prover disponibilidade / backups redundantes por conta própria
- você consegue gerenciar repositórios privados com rigor (exposição é evitável por disciplina)
Em resumo, auto-hospedar significa assumir o trabalho que o GitHub fazia por você. Assuma-o e faça-o, e você remove uma grande classe de incidentes. Assuma-o e negligencie-o, e você pode acabar pior que o GitHub: um servidor sem patches, um segredo mal-commitado e um backup que você não consegue restaurar. E o envenenamento da cadeia de suprimentos (como o backdoor do xz-utils) é defendido por monitoramento contínuo de dependências onde quer que seu código viva.
O que este site faz por conta própria
Este site roda um servidor Git auto-hospedado (bare git puro + SSH) e o configura de modo que todo push também seja copiado para um backup em um servidor separado. Segredos (chaves, senhas, strings de conexão) nunca vão para o git ou a documentação, e o monitoramento de CVE de dependências roda via pnpm audit antes de cada deploy e diariamente. "Não usar o GitHub" não é o objetivo — remover a classe de exposição acidental enquanto se faz você mesmo todo o trabalho que o GitHub fazia é. Só fazer ambos torna a auto-hospedagem segura.
Leia a seguir
- Glossário: arquivos .env e segredos
- Incidentes: uma chave vazou via repositório público · um .env inteiro exposto
- Stacks: monitore CVEs de dependências por máquina com o osv-scanner · não ficar para trás nos CVEs
- Cadeia de suprimentos: quando um único npm install esvazia as suas credenciais (como repositórios privados acabam copiados como públicos, e por que o escopo do token decide isso)