# 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.

URL: https://ardumaker.com/pt/servicios/deploy-github/

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

## É assim no painel

Capturas reais do painel da ArduMaker, não mockups.

![Deploy do GitHub: Deploy a partir do GitHub](https://ardumaker.com/screenshots/servicios/deploy-github-1.jpg)
**Deploy a partir do GitHub**. Branch, última sincronização e cada pull com passos e duração.

![Deploy do GitHub: Scripts de build](https://ardumaker.com/screenshots/servicios/deploy-github-2.jpg)
**Scripts de build**. O que roda antes e depois de cada pull, com templates.

## Escolha o repositório e ele fica publicado

No Apps a implantação é um único passo: você escolhe o repo e a plataforma faz o resto. Tudo o que é montado fica visível no VPS e pode ser alterado.

- Detecta o projeto: Node.js, site estático (Vite, React, Astro, HTML), Python (Django, FastAPI, Flask) ou um Dockerfile.
- Antes de implantar mostra como vai compilar, como vai servir e para onde o nginx aponta, com o detectado já preenchido. Você confirma ou altera.
- Recebe um endereço https automático; o seu domínio você adiciona depois em Domínios.
- Cada push no branch escolhido implanta de novo.
- Se algo falhar, diz em qual passo e leva você à aba do servidor onde está o registro.

## Antes de instalar

### Use quando

- Você tem um site, uma API ou um front em um repositório do GitHub e quer publicá-lo com HTTPS sem configurar um servidor.
- Você quer que cada push em um branch atualize o que está publicado, sem entrar por SSH.
- O projeto é Node.js, um site estático (Vite, React, Astro, HTML), Python (Django, FastAPI, Flask) ou traz seu Dockerfile.

### Não é o indicado se

- Você só precisa de um banco de dados ou Redis: para isso existem seus próprios apps.
- A aplicação já está publicada como imagem em um registro: implante com Docker.
- Você precisa de vários serviços que sobem juntos (app, fila, banco): use Docker com um Compose.

### Como testar que ficou funcionando

1. **Abra o endereço atribuído**: Ao terminar, o app mostra seu endereço https. Abra no navegador ou rode: curl -I https://seu-app.arducloud.com — deve responder 200 (ou o redirecionamento do seu app).
2. **Faça uma alteração e envie**: Mude um texto, faça git push no branch implantado e recarregue a página: a mudança aparece quando a implantação termina. O registro de cada implantação fica no VPS, aba Deploy.
3. **Se for uma API, chame um endpoint**: curl https://seu-app.arducloud.com/health (ou a rota que você tiver). Se responder 502, o app não subiu: veja o log do serviço no VPS.

### Dicas

- Antes de implantar é mostrado como será compilado, como será servido e para onde o nginx aponta. Revise: corrigir ali é mais rápido do que depois.
- Seu app deve escutar na porta que recebe na variável PORT, não em uma fixa.
- Em um site estático não fica nenhum processo rodando: o nginx serve a pasta compilada (dist, build ou out).
- Variáveis de ambiente e segredos ficam no VPS, não no repositório.
- O domínio automático serve para começar; o seu você adiciona depois em Domínios, com seu certificado.

## 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

O que vale a pena saber antes de começar, sem letras miúdas.

- 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](https://ardumaker.com/pt/mcp/deploy/)

## Deploy do GitHub: 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.

### Quais frameworks ele detecta sozinho?

Ao instalar o repo pelo Apps, os arquivos são lidos e é sugerido como compilar e iniciar: um Dockerfile roda como contêiner; Next.js, Nuxt, Remix, Express, NestJS e SvelteKit (node) compilam com npm e iniciam na porta 3000; Vite, Astro, Create React App e SvelteKit estático compilam e servem a pasta de saída; Django, FastAPI e Flask instalam o requirements.txt e iniciam com gunicorn ou uvicorn. É uma sugestão: você confirma ou muda.

### Como publico um app Django ou FastAPI?

Você vincula o repo e a branch. Com manage.py é detectado Django, que inicia com gunicorn; com fastapi no requirements.txt ou no pyproject.toml, o FastAPI inicia com uvicorn na porta 8000. As variáveis de ambiente e o comando se ajustam na configuração do deploy, o app fica como serviço que reinicia sozinho e o domínio vai com SSL automático.

### Posso hospedar o meu próprio servidor MCP ou um agente que rode 24/7?

Sim. Um servidor MCP remoto ou um agente é um app Node ou Python como qualquer outro: publica a partir do GitHub, coloca um domínio com HTTPS e ele fica rodando como serviço, sem limite de tempo de execução. Se tiver Dockerfile, roda como contêiner.

## Serviços que costumam andar juntos

Tudo roda no mesmo VPS e é gerenciado pelo mesmo painel.

- [Domínios e SSL](https://ardumaker.com/pt/servicios/dominios-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](https://ardumaker.com/pt/servicios/servicios-y-tareas/): Crie serviços systemd para o seu app e tarefas agendadas (tipo cron) com logs, sem escrever systemctl.
- [Docker](https://ardumaker.com/pt/servicios/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. Não é um produto à parte: está no painel de qualquer VPS da ArduMaker, junto com o root real por SSH. [Ver planos](https://ardumaker.com/pt/precios/)