Como montar um ambiente de staging automatizado com Git no seu VPS
Se você já perdeu o sono publicando uma atualização direto no site "de produção" (aquele que os seus clientes ou visitantes veem) e torcendo pra não quebrar nada, este guia é pra você. Vamos criar um ambiente de staging: uma cópia paralela do seu site, isolada, onde você testa tudo antes de qualquer coisa chegar ao público. E o melhor: usando Git, a atualização vira só um comando.
Staging é o seu "ensaio geral". Nada que acontece lá afeta o site real — é o lugar ideal pra testar atualizações, plugins, mudanças de código ou configurações novas com segurança.
Pré-requisitos
Este guia é voltado para quem tem um VPS GeHost com acesso root/SSH (a linha VPS é diferente da hospedagem compartilhada com cPanel — aqui você tem o ambiente todo na sua mão). Antes de começar, tenha em mãos:
- Acesso SSH ao seu VPS (usuário e chave ou senha configurados).
- Git instalado no servidor.
- Um subdomínio ou domínio separado para o staging (por exemplo, um subdomínio de teste apontando pra pasta do ambiente de staging).
- A stack da sua aplicação já rodando localmente ou em um repositório Git (GitHub, GitLab, Bitbucket ou até um repositório só seu, no próprio VPS).
Passo 1 — Crie um repositório "bare" no VPS
Um repositório "bare" é um repositório Git que não tem os arquivos do projeto visíveis, só o histórico — ele funciona como o destino para onde você vai enviar ("dar push") o seu código. É a peça-chave da automação.
- Conecte no seu VPS via SSH.
- Crie uma pasta dedicada para os repositórios, por exemplo dentro do seu usuário (algo como uma pasta "git" ou "repositorios").
- Dentro dela, crie uma nova pasta com o nome do seu projeto terminando em ".git" e inicialize um repositório bare nela (o comando é git init --bare executado dentro dessa pasta).
Passo 2 — Crie a pasta de destino do staging
Separe uma pasta só para os arquivos "vivos" do ambiente de staging — é para essa pasta que o servidor web (Nginx, Apache ou o serviço que você usa) vai apontar quando alguém acessar o subdomínio de teste. Mantenha essa pasta separada da pasta do site de produção, para não haver risco de mistura.
Passo 3 — Configure o "hook" de deploy automático
Aqui está a mágica: o Git permite configurar um script chamado post-receive, que roda automaticamente sempre que você envia código novo para o repositório bare. Esse script pega o código recém-enviado e o "descompacta" direto na pasta do staging.
- Dentro do repositório bare, entre na pasta "hooks".
- Crie um arquivo chamado exatamente post-receive (sem extensão).
- Nesse arquivo, escreva um pequeno script que copia os arquivos recebidos para a pasta de staging (usando o comando git --work-tree apontando para essa pasta, junto com git checkout).
- Dê permissão de execução a esse arquivo (comando chmod +x no nome do arquivo).
Dica da Sensei: se a sua aplicação precisa reiniciar um serviço depois do deploy (por exemplo, reiniciar um processo Node.js), você pode incluir esse comando de reinício no final do mesmo script post-receive. Assim, um único "push" atualiza o código E reinicia a aplicação.
Passo 4 — Aponte o subdomínio de staging para a pasta certa
No seu painel de controle do VPS ou na configuração do seu servidor web, crie o subdomínio de staging e faça-o apontar para a pasta que você criou no Passo 2. Se a sua aplicação usa um processo próprio (como Node.js rodando numa porta específica), configure um proxy reverso para esse subdomínio também.
Passo 5 — Configure seu computador para enviar o código
No seu computador, dentro do projeto, adicione o repositório do VPS como um "remote" do Git (um destino de envio). O comando é git remote add, seguido de um nome (por exemplo "staging") e do endereço SSH do repositório bare que você criou no Passo 1.
A partir daí, sempre que quiser atualizar o ambiente de staging, basta rodar git push staging (seguido do nome da sua branch). Em segundos, o código novo estará no ar — só no staging, seguro, longe do site real.
Passo 6 — Teste, valide e só depois vá para produção
- Acesse o subdomínio de staging e confira se tudo funciona como esperado.
- Rode os testes automatizados do seu projeto, se você tiver algum.
- Só depois de validar no staging, repita o processo de deploy (ou faça o merge da branch) no repositório de produção.
Uma boa prática é manter branches separadas: uma para staging (onde tudo é testado primeiro) e outra para produção (que só recebe código já aprovado). Isso evita publicar algo "pela metade" sem querer.
Vai além disso?
Se o seu projeto crescer e você quiser um pipeline mais robusto — com containers, filas, cache ou múltiplos serviços rodando junto — lembre que o VPS é o seu ambiente, com Docker, Redis, bancos de dados e tudo mais disponível para você configurar. Qualquer dúvida na hora de montar esse fluxo, é só chamar o suporte pelo painel — estamos aqui para ajudar você a evoluir sem medo de quebrar o que já está no ar.
