Você está avaliando a migração do GitHub público para uma instância autogerenciada em sua própria infraestrutura, mas não tem certeza se o controle total da hospedagem git compensa a complexidade operacional ou se a nuvem gerenciada é mais segura. Ao final deste tutorial, você terá um roteiro técnico completo para comparar GitHub Enterprise Cloud versus Self-Hosted em VPS, decidir qual arquitetura atende aos seus requisitos de compliance e segurança, e executar a instalação com comandos validados.
Neste tutorial:
Contexto e Comparação Técnica: Cloud vs Self-Hosted
A escolha entre manter o GitHub Enterprise Cloud ou operar uma instância self-hosted (auto-hospedada) em uma VPS não é apenas financeira; é uma decisão estratégica sobre governança de dados, latência e responsabilidade operacional. Para equipes de DevOps e engenharia que lidam com código sensível, a localização dos dados muitas vezes dita a arquitetura. O GitHub Enterprise Cloud oferece alta disponibilidade gerenciada pela GitHub Inc., com atualizações automáticas e redundância global. No entanto, ele opera em datacenters terceirizados, o que pode ser um obstáculo para setores regulados como financeiro ou saúde, que exigem controle físico sobre os servidores. Por outro lado, a opção self-hosted coloca a responsabilidade da infraestrutura nas suas mãos, permitindo personalização profunda e isolamento total, mas exige que você gerencie patches de segurança, backups e escalabilidade. A tabela abaixo detalha as diferenças técnicas cruciais para a tomada de decisão:| Aspecto | GitHub Enterprise Cloud | Self-Hosted em VPS (GitHub Enterprise Server) |
|---|---|---|
| Gerenciamento de Infraestrutura | Totalmente gerenciado pela GitHub. | Você gerencia SO, rede, armazenamento e atualizações. |
| Localização dos Dados | Datacenters da GitHub (EUA/Europa). | Qualquer datacenter de sua preferência (ex: Brasil). |
| Customização | Limitada a configurações da plataforma. | Total acesso ao sistema de arquivos e banco de dados. |
| Custo Operacional (OpEx) | Maior, mas sem custo de manutenção de servidor. | Menor licença anual, mas alto custo de engenharia interna. |
| Conformidade (LGPD/GDPR) | Cumple padrões globais, mas dados saem do país. | Controle total para atender legislações locais rigorosas. |
| Atualizações | Automáticas e frequentes. | Você define o cronograma de upgrade (maior risco de desatualização). |
Se a sua prioridade é reduzir a carga operacional e focar puramente no desenvolvimento, a nuvem é superior. Se você precisa de latência mínima para desenvolvedores locais ou armazenamento de ativos gigantes sem limites rígidos de egressa, a instalação em VPS se torna atrativa.
Pré-requisitos de Infraestrutura
Antes de iniciar a instalação do GitHub Enterprise Server (GHES) em sua VPS, é fundamental garantir que o ambiente atenda aos requisitos mínimos de hardware e software. Uma configuração inadequada resultará em instabilidade severa durante o uso diário. 1. Recursos da VPS Para uma instância funcional de produção, recomendo fortemente um servidor com pelo menos 32 GB de RAM e 8 vCPUs. O banco de dados PostgreSQL e o serviço de rastreamento consomem memória intensamente. O disco deve ser SSD ou NVMe para garantir IOPS consistentes nas operações de git clone e push. 2. Sistema Operacional O GHES é otimizado para distribuições baseadas em Linux, sendo o Ubuntu Server 20.04 LTS ou 22.04 LTS a escolha mais estável e documentada. Certifique-se de que o kernel esteja atualizado. 3. Rede e DNS Você precisará de um domínio público configurado (ex:github.suaempresa.com.br). O servidor deve ter portas 80 (HTTP) e 443 (HTTPS) abertas na firewall para acesso externo, além das portas internas necessárias para o appliance. Configure os registros DNS A ou CNAME antes de começar.
4. Armazenamento
O disco raiz deve conter o sistema operacional e logs. O armazenamento de dados (repositórios, blobs, uploads) deve estar em um volume separado montado em /data. Isso facilita backups e expansões futuras sem parar o serviço principal.
Passo a Passo: Instalação Self-Hosted
A instalação do GitHub Enterprise Server segue uma metodologia de appliance (aplicativo pronto). Não é uma instalação viaapt-get simples; envolve provisionamento de uma imagem virtual ou ISO que contém todo o stack necessário.
Atenção: Este tutorial foca na instalação via ISO/Imagem em ambiente Linux, que é o método mais comum para VPSes customizadas.
1. Download da Imagem e Validação
Primeiro, baixe a versão mais recente do GitHub Enterprise Server diretamente do site oficial da GitHub. Você precisará de uma conta corporativa ativa para acessar o repositório de downloads. ```bash # Exemplo de comando para download via wget (ajuste a URL conforme a versão) wget https://enterprise.github.com/releases/VERSION_NUMBER/github-enterprise.VERSION_NUMBER.x86_64.iso # Valide a integridade do arquivo com a checksum fornecida sha256sum github-enterprise.VERSION_NUMBER.x86_64.iso ```2. Provisionamento da Máquina Virtual
Dependendo de sua hypervisor (KVM, XEN, VMware), você deverá criar uma nova VM e montar a ISO baixada como drive óptico. Defina o BIOS para bootar do CD-ROM. Se estiver usando um serviço de cloud que permite upload de imagem (como QEMU/KVM), converta a ISO para qcow2: ```bash # Conversão para formato qcow2 (comum em ambientes KVM/Libvirt) qemu-img convert -f raw -O qcow2 github-enterprise.iso ghes-appliance.qcow2 # Ajuste de permissões para o usuário libvirt/qemu chown qemu:qemu ghes-appliance.qcow2 ```3. Inicialização e Configuração de Rede
Ao iniciar a VM pela primeira vez, você verá uma tela de configuração inicial via console serial ou VNC. Você será solicitado a definir: 1. O hostname da máquina (deve corresponder ao seu DNS). 2. O gateway padrão. 3. Os endereços DNS. 4. Uma senha temporária para o usuárioadmin.
Após a configuração inicial, o sistema reiniciará e aplicará as configurações de rede. Verifique se a VM obteve um IP estático ou reservado no seu DHCP interno.
4. Acesso ao Painel de Administração (GHE Admin)
Acessehttps://github.suaempresa.com.br em seu navegador. O certificado SSL será autassinado inicialmente, gerando um aviso de segurança; aceite-o para prosseguir. Faça login com o usuário admin e a senha temporária.
No painel de administração, você deve configurar:
* **Licensing:** Insira sua chave de licença anual. Sem isso, a instância entrará em modo de avaliação limitada.
* **Email:** Configure o SMTP para notificações de segurança e recuperação de senha.
* **Storage:** Se tiver um disco separado em /data, monte-o conforme instruído pelo wizard do GHES.
Uma vez configurado, o GitHub Enterprise Server estará rodando sua própria instância do GitHub, com as mesmas funcionalidades do Cloud, mas rodando em seus servidores.
Verificação e Testes de Estresse
Após a instalação, não assuma que tudo está funcionando perfeitamente apenas porque o login ocorreu. Execute testes de integridade para garantir que o banco de dados, o sistema de arquivos e os serviços de rede estão comunicando-se corretamente. 1. Verificação de Status dos Serviços Use o comandoghe-status no terminal do appliance (acessível via SSH como admin) para verificar a saúde dos componentes principais:
```bash
ghe-status
# Output esperado: Todos os serviços devem estar em "up" ou "running"
# Ex: mysql - up, redis - up, ghe-web - up, git-server - up
```
2. Teste de Latência e Clone
Crie um repositório de teste via interface web e tente cloná-lo de um cliente externo. Meça o tempo de resposta.
```bash
# Medição de tempo de clone para um repo vazio
time git clone https://github.suaempresa.com.br/teste/empty-repo.git
```
Se a latência for alta, verifique se não há gargalos de I/O no disco ou limitação de CPU na sua VPS.
3. Validação de Backup
Configure uma rotina de backup imediatamente. No painel Admin, vá em "Backup & Restore" e configure o destino (S3, NFS ou SCP). Execute um backup manual para verificar a integridade do arquivo gerado.
```bash
# Comando via SSH para forçar backup imediato (exemplo)
ghe-backup
```
Troubleshooting Comum
Problemas em instâncias self-hosted são inevitáveis, especialmente durante a fase de ajuste fino. Abaixo estão os cenários mais frequentes e suas resoluções. 1. Erro "Internal Server Error" ao fazer Push Geralmente causado por falta de espaço em disco ou permissões incorretas no volume de dados. Verifique o uso do disco comdf -h. Se o disco estiver cheio, limpe logs antigos em /var/log ou expanda o volume.
2. Problemas de Certificado SSL/TLS
Se você substituiu o certificado autassinado por um Let's Encrypt ou comercial e os serviços pararam, verifique se as permissões do arquivo de chave privada estão corretas. O usuário do serviço (geralmente git ou ghe) precisa ler o arquivo.
```bash
# Corrigindo permissões de certificado
sudo chown git:git /etc/ssl/certs/suaempresa.crt
sudo chmod 644 /etc/ssl/certs/suaempresa.crt
```
3. Lentidão no Banco de Dados
O PostgreSQL é o coração do GHES. Se o sistema estiver lento, verifique se a VPS tem memória RAM suficiente para manter o shared_buffers e work_mem adequados. Monitore com top ou htop.
4. Falha no Sync de GitHub Actions
Se você usa runners self-hosted, certifique-se de que eles estão na mesma rede de baixa latência com o appliance. Firewalls bloqueando portas TCP aleatórias altas podem impedir a comunicação entre o runner e o servidor principal.
Perguntas Frequentes
Posso migrar do GitHub Cloud para Self-Hosted facilmente?
A migração não é automática. Você precisará exportar repositórios, wikis e issues via API ou ferramentas de terceiros, e importá-las na nova instância. A configuração de autentação (SSO/LDAP) também precisa ser refeita do zero.Qual a frequência de atualizações necessárias?
Diferente da nuvem, você é responsável por aplicar patches de segurança. Recomenda-se atualizar para a versão mais recente a cada 3 a 6 meses para garantir proteção contra vulnerabilidades críticas no código do próprio GitHub.Posso usar o GitHub Actions em uma instância self-hosted?
Sim, o GitHub Enterprise Server suporta GitHub Actions. No entanto, os runners (executores) devem ser provisionados e gerenciados por você dentro da sua rede privada, o que adiciona complexidade operacional comparado aos runners públicos da GitHub.É possível rodar isso em uma VPS de baixo custo?
Tecnicamente sim, mas não recomendado para produção. Uma instância mínima (16GB RAM) pode funcionar para times pequenos (até 50 usuários), mas o desempenho cairá drasticamente com o aumento de repositórios e atividade de CI/CD.Como faço backup dos dados?
Utilize a ferramenta nativaghe-backup. Ela cria um snapshot consistente do banco de dados e do sistema de arquivos. Armazene esses backups em um local externo, como um bucket S3 ou outro servidor NFS, para evitar perda total em caso de falha de hardware.