Você dá push, o seu VPS se atualiza sozinho

Você escolhe o repositório e a branch, e o painel clona o código no VPS, cria o webhook no GitHub e deixa tudo pronto. A partir daí, cada push nessa branch dispara um pull, roda os seus scripts de build e reinício, e fica registrado qual commit foi publicado. É o fluxo de uma plataforma tipo Vercel, num servidor onde você tem root e o preço não depende do tráfego que você tiver.

  • Webhook criado sozinho
  • Scripts de build e reinício
  • Histórico de commits

Ver planos · Criar conta grátis

É assim no painel

Deploy do GitHub: Deploy a partir do GitHub
Deploy a partir do GitHub. Branch, última sincronização e cada pull com passos e duração.
Deploy do GitHub: Scripts de build
Scripts de build. O que roda antes e depois de cada pull, com templates.

Um fluxo de deploy completo, sem YAML

A praticidade de uma plataforma tipo Vercel, num servidor que é seu.

  • Você vincula o repo pelo painel: Escolhe um repositório da sua conta do GitHub, a branch e um nome de projeto. A existência da branch é verificada antes de criar o deploy.
  • Webhook automático: O webhook é criado sozinho no GitHub, com verificação SSL. Não é preciso mexer na configuração do repositório.
  • Pull a cada push: Cada push na branch acompanhada dispara um git pull no VPS. Os pushes em outras branches são ignorados.
  • Scripts antes e depois: Um script antes do pull (por padrão descarta alterações locais) e um depois para instalar dependências, compilar ou reiniciar serviços.
  • Status visível: Clonando, fazendo pull, compilando, reiniciando, online ou erro com a mensagem. Você sabe em que pé está cada deploy.
  • Histórico de commits: Cada commit recebido fica registrado com SHA, mensagem, autor, data e arquivos adicionados, apagados e modificados, com link para o GitHub.
  • Redeploy manual: Você publica de novo com um botão quando precisar, sem fazer um commit vazio.
  • O app inteiro num lugar só: Você associa ao repo os seus domínios, serviços systemd e tarefas agendadas, e vê a aplicação inteira junta.
  • Várias branches, um VPS: Um mesmo repo pode ser publicado em branches diferentes dentro do mesmo VPS: produção e staging lado a lado.
  • Sem YAML para manter: Não há um arquivo de pipeline que quebra quando a sintaxe muda. Dois scripts de shell, que é o que na prática acaba rodando de qualquer jeito.
  • Sem minutos de build: O build roda no seu VPS. Não há cota de minutos nem fila de runners: o limite é a CPU que você já está pagando.

O seu primeiro deploy em minutos

  1. Conecte a sua conta do GitHub: Uma única vez, pelo painel.
  2. Escolha repo e branch: O código é clonado no VPS e o webhook é criado sozinho.
  3. Defina build e reinício: Por exemplo npm ci && npm run build e reiniciar o seu serviço.
  4. Publique com domínio: Você atribui um domínio com HTTPS e cada push o atualiza.
  5. Olhe o histórico: Cada commit publicado fica com o seu SHA, autor, mensagem e arquivos alterados. Se algo quebrou, você sabe exatamente com quê.

Como funciona por baixo, e o que levar em conta

  • Não há runner nem agente de CI: o webhook do GitHub avisa o VPS e o VPS faz git pull sobre o clone que já tem. Por isso o deploy demora o que o seu build demorar, e nada mais.
  • O script antes do pull descarta alterações locais por padrão. É de propósito: um arquivo mexido na mão no servidor é a causa mais comum de um pull falhar no meio de um deploy.
  • O script posterior é onde vai tudo o que é seu: instalar dependências, compilar, migrar o banco, reiniciar o serviço systemd do app.
  • Os pushes em outras branches são ignorados. Um mesmo repositório pode ser publicado em branches diferentes dentro do mesmo VPS, então produção e staging convivem sem se atropelar.
  • Cada combinação de repositório e branch é publicada uma vez por VPS.
  • Precisa de systemd rodando no VPS. Está verificado em produção no Ubuntu 22.04 e é compatível com 18.04, 20.04, 24.04 e 26.04; no 16.04 não está disponível porque o systemd 229 não sobe num host com cgroup v2.
  • É preciso ter a conta do GitHub vinculada com o token válido. Se o token vencer bem na hora de apagar um deploy, o webhook pode ficar pendurado no GitHub e é preciso apagá-lo na mão.
  • O build roda no VPS e usa a memória dele. No plano menor vale um repositório leve: compilar algo grande fica sem memória no meio do caminho.
  • Os administradores da Empresa editam e apagam deploys; os membros podem vê-los e criá-los.
  • Root real por SSH: o painel é um atalho, não uma jaula. Tudo o que ele faz com um botão você também pode fazer à mão.

Você também pode pedir ao Claude, ChatGPT ou Cursor

Tudo o que você vê no painel o seu agente de IA pode fazer pelo servidor MCP da ArduMaker: com a sua autorização, com o alcance que você der e com cada ação auditada. Ver o que o MCP faz

Perguntas frequentes

Preciso configurar o webhook no GitHub?

Não. Ele é criado automaticamente ao vincular o repositório.

O que acontece se eu der push em outra branch?

Ele é ignorado. Só a branch configurada dispara o pull.

Dá para compilar e reiniciar o meu app depois de cada deploy?

Dá, com o script posterior ao pull: você instala dependências, compila e reinicia o serviço systemd do seu app.

Consigo ver o que foi publicado e quando?

Consegue. Cada commit fica registrado com autor, mensagem, data e arquivos alterados, com link para o GitHub.

Serve como alternativa à Vercel ou ao Heroku?

Para apps que você quer rodar em servidor próprio, serve: você tem o mesmo fluxo de push para publicar, mas com root, sem limites de funções e com o preço fixo do VPS.

Preciso escrever um arquivo de pipeline?

Não. São dois scripts de shell: um antes do pull e outro depois. Não há YAML que quebra quando a sintaxe da plataforma muda.

Quanto demora um deploy?

O que o seu build demorar. Não há fila de runners nem minutos de CI: o webhook avisa, o VPS faz o pull e roda o seu script. A CPU é a que você já está pagando.

Posso ter produção e staging no mesmo VPS?

Pode. O mesmo repositório pode ser publicado em branches diferentes dentro do mesmo VPS, cada uma com os seus scripts e o seu domínio.

E se eu mexi num arquivo na mão no servidor?

O script antes do pull descarta alterações locais por padrão, justamente porque é a causa mais frequente de um deploy travar. Se você precisar de outro comportamento, esse script quem edita é você.

Dá para publicar de novo sem fazer um commit?

Dá, com o botão de redeploy. Não é preciso um commit vazio para forçar o pull.

Serviços que costumam andar juntos

  • Domínios e SSL: Subdomínio grátis ou o seu domínio com Let's Encrypt, proxy nginx com rollback e redirecionamentos de portas.
  • Serviços e tarefas agendadas: Crie serviços systemd para o seu app e tarefas agendadas (tipo cron) com logs, sem escrever systemctl.
  • Docker: Ative o Docker em um clique e gerencie imagens, contêineres, logs, volumes e redes pelo painel.

Do push à produção, no seu próprio servidor Vincule o seu repo e deixe cada commit ser publicado sozinho. Ver planos