O que é
Você desenvolveu uma página, um site estático, um tema ou um plugin, e quer pôr no ar sem FTP. Peça
ao agente: “publica o repositório github.com/empresa/site em landing.meusite.com, a pasta dist
depois do build”. Ele configura o deploy do site a partir do Git ou de um pacote (.zip,
.tar.gz), roda o build num ambiente isolado, guarda um ponto de restauração e publica. Se algo der
errado, ele volta o site ao que era antes.
O deploy também funciona pela API para automações: dá para um
GitHub Actions publicar com uma chave gwm_, ou deixar o servidor publicar sozinho a cada push.
Para onde publica
- Site Custom: o
htdocsinteiro ou uma pasta dele (ver Criando um site Custom). - WordPress: a pasta de um tema ou plugin (
wp-content/themes/<nome>ouwp-content/plugins/<nome>). Núcleo,wp-config.phpe uploads nunca são tocados.
Mautic e aplicações não recebem deploy por aqui. Aplicação Node.js tem o deploy próprio (ver Node App).
De onde vem o código
| Fonte | Como |
|---|---|
| Git (público) | URL https:// do repositório e a branch |
| Git (privado) | O painel gera uma chave de deploy para você cadastrar no repositório (GitHub: Settings → Deploy keys) |
| Pacote | URL https:// de um .zip ou .tar.gz (o .zip do GitHub funciona; uma pasta única na raiz vira a raiz) |
Outras opções do deploy: a pasta do código a publicar (dist, build, public), a pasta de
destino dentro do htdocs, o comando de build com a versão do Node.js, e os caminhos que o
deploy não apaga no destino (por exemplo, uploads).
O build isolado
Com um comando de build (npm ci && npm run build, por exemplo), o servidor compila o código numa
jaula gVisor, a mesma do Node App: sem acesso aos outros sites, código só leitura, 2 GB de
memória, 2 núcleos e até 15 minutos. O que sai do build é o que vai para o ar.
O npm ci exige o package-lock.json no repositório. Sem ele o build falha, e a mensagem chega
inteira ao agente: use npm install no comando.
O que vai e o que não vai para o ar
O código é baixado numa pasta só do sistema e publicado como o usuário do site, espelhando o que
saiu do código (o que foi removido do repositório some do site). Ficam de fora: .git, .github,
node_modules, arquivos .env* e links simbólicos. Ficam preservados no destino: .well-known
(SSL), .user.ini, os arquivos de controle do painel e o que você listar em “não apagar”.
Voltar um deploy
Antes de cada publicação, o painel guarda um ponto de restauração dos arquivos com o id do deploy. “Volta o último deploy” restaura os arquivos como estavam. Com a aprovação ligada na chave, voltar espera o seu “sim”.
Publicar a cada push
O deploy tem um webhook próprio para o GitHub (assinatura X-Hub-Signature-256) ou o GitLab
(X-Gitlab-Token). Cadastrado no repositório, cada push na branch configurada publica sozinho;
push em outra branch é ignorado. O segredo do webhook só aparece para chave de Acesso total.
Níveis
- Configurar a fonte e gerar a chave de deploy: Acesso total.
- Publicar o que está configurado e voltar: Operar.