Como configurar um pipeline de CI/CD simples pra publicar automaticamente no VPS

Publicando seu projeto sozinho, sem drama: um CI/CD simples pro seu VPS

Olá! Aqui é a Sensei da GeHost 🌱 Se você já perdeu tempo subindo arquivo por FTP, esquecendo de atualizar um arquivo lá no servidor, ou teve aquele friozinho na barriga na hora de publicar uma alteração... este guia é pra você. Vamos montar, passo a passo, um pipeline de CI/CD (Integração Contínua / Entrega Contínua) bem simples: toda vez que você enviar (push) uma alteração pro seu repositório, ela é publicada automaticamente no seu VPS. Sem mistério, sem enrolação.

👉 Este guia é voltado pra quem já tem um VPS com acesso SSH e um projeto versionado com Git (por exemplo, no GitHub). Se você não tem certeza de qual é o seu tipo de acesso ao servidor, consulte seu contrato ou fale com o suporte antes de começar.

O que você vai precisar antes de começar

• Um repositório Git do seu projeto (GitHub, GitLab, etc.);
• Acesso SSH ao seu VPS (usuário e chave ou senha);
• Git instalado no VPS;
• Um pouquinho de paciência na primeira configuração — depois disso, é tudo automático! 😉

Passo 1 — Prepare uma pasta de deploy no seu VPS

Primeiro, acesse seu VPS via SSH e crie (ou use) a pasta onde o projeto vai viver. O jeito mais simples é já deixar essa pasta como um clone do seu repositório:

1. Conecte no VPS: ssh usuario@seu-servidor
2. Vá até a pasta onde o projeto vai ficar publicado (por exemplo, a raiz do seu site);
3. Clone o repositório ali: git clone URL_DO_SEU_REPOSITORIO .

Pronto — a partir de agora, publicar uma nova versão é, na essência, rodar um git pull nessa pasta. É exatamente esse comando que vamos automatizar.

Passo 2 — Crie uma chave SSH exclusiva pra automação

Por segurança, não use sua chave pessoal do dia a dia para a automação. Crie uma chave nova, só para esse fim:

1. No seu computador (ou direto no VPS), gere um par de chaves: ssh-keygen -t ed25519 -C "deploy-automatico"
2. Adicione a chave pública gerada no arquivo ~/.ssh/authorized_keys do usuário que vai fazer o deploy no VPS;
3. Guarde a chave privada com cuidado — ela é a "senha" que a automação vai usar pra entrar no servidor.

🔒 Dica da Sensei: nunca compartilhe a chave privada por e-mail, chat ou print. Ela deve ir apenas para o cofre de segredos da sua ferramenta de CI/CD, como você vai ver no próximo passo.

Passo 3 — Configure os segredos no seu repositório

Se você usa o GitHub, vá em Settings → Secrets and variables → Actions do seu repositório e cadastre:

• VPS_HOST — o endereço do seu servidor;
• VPS_USER — o usuário SSH usado pro deploy;
• VPS_SSH_KEY — a chave privada criada no passo anterior;
• VPS_PATH — o caminho completo da pasta do projeto no servidor.

Esses dados ficam criptografados pela própria plataforma e nunca aparecem no código — é assim que fazemos deploy automático sem expor senha ou chave em lugar nenhum.

Passo 4 — Crie o workflow de deploy

Agora vem a mágica. Dentro do seu repositório, crie o arquivo .github/workflows/deploy.yml com um conteúdo parecido com este:

name: Deploy no VPS

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Conectar e atualizar o servidor
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            cd ${{ secrets.VPS_PATH }}
            git pull origin main

Traduzindo: toda vez que alguém fizer push na branch main, o GitHub vai entrar no seu VPS via SSH e rodar um git pull automaticamente, atualizando o projeto publicado.

Quer ir além do git pull?

Se seu projeto precisa de passos extras — como instalar dependências ou reiniciar um serviço — é só encadear os comandos no mesmo bloco script, por exemplo:

script: |
  cd ${{ secrets.VPS_PATH }}
  git pull origin main
  npm install --production
  pm2 restart meu-app

Passo 5 — Teste com calma

1. Faça uma pequena alteração no projeto (algo simples, tipo mudar um texto);
2. Dê o commit e o push pra branch configurada;
3. Acompanhe a aba Actions do GitHub — você vai ver o passo a passo rodando ao vivo;
4. Confira se a alteração realmente apareceu no seu site/aplicação.

💡 Dica da Sensei: teste primeiro numa alteração pequena e reversível. Só depois de ver o pipeline funcionando redondinho é que vale confiar nele pra mudanças maiores.

Boas práticas pra dormir tranquilo

• Nunca versione senhas ou arquivos .env — mantenha esses dados só no servidor;
• Faça backup antes de mudanças grandes — combine seu pipeline com uma rotina de backup do seu projeto;
• Use uma branch de testes antes de publicar direto na main, se o projeto for mais sensível;
• Restrinja a chave de deploy a fazer só o que ela precisa — nada de usar uma chave com privilégios além do necessário.

Ficou com dúvida?

Automação é maravilhosa, mas também pode assustar na primeira vez — e tudo bem sentir isso! Se travar em algum passo, ou quiser ajuda pra adaptar esse pipeline ao seu projeto específico, é só chamar o suporte da GeHost ou dar uma olhada no seu painel do cliente. Estamos aqui torcendo pela sua automação! 🚀