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

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

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.

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

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: 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. Não é um produto à parte: está no painel de qualquer VPS da ArduMaker, junto com o root real por SSH. Ver planos

Como funciona por dentro

A documentação técnica do que há nesta página: o que cada ferramenta faz, o que muda, como verificar e quais ferramentas MCP a operam.

  • Deploy do GitHub: Clona, faz o build e publica um repo do GitHub no VPS; deploy a cada push, histórico por fases e rollback.

Toda a documentação

Compare com outras plataformas

Comparativos com dados públicos e fontes, que também dizem quando a outra opção é melhor.

Ver todos os comparativos