Otimizar deploy WordPress com Git no cPanel sem root

Otimizar deploy WordPress com Git no cPanel sem root é o fluxo em que o push atualiza o código no public_html só com SSH do usuário da conta, repositório bare e hook post-receive — sem privilégio de administrador. Para colocar o pipeline no ar, siga estes passos:

1. Ative SSH na conta cPanel e confira se o Git do usuário responde no Terminal
2. Crie um repositório bare na home (fora do public_html)
3. Configure o hook post-receive com checkout seletivo e exclusões
4. Ignore wp-config.php, uploads e .env no .gitignore do projeto local
5. Adicione o remote, faça o primeiro push e valide o site em staging
6. Automatize build de assets e limpeza de cache só quando o hook terminar

Pré-requisitos

• Conta cPanel com SSH/Terminal liberado para o usuário (sem root e sem sudo)
• Git disponível no PATH do usuário (Git Version Control do painel ou binário via SSH)
• WordPress já instalado em public_html ou em subdomínio de staging
• Acesso local ao repositório do tema/plugin/código versionado (PHP 8.4+ recomendado no ambiente)
• Chave SSH do seu computador autorizada em ~/.ssh/authorized_keys da conta
• Backup recente de arquivos e banco antes do primeiro deploy em produção

Otimizar deploy WordPress com Git no cPanel sem root na prática

O gargalo clássico em hospedagem compartilhada ou revenda é a falta de root: você não instala serviços de CI no sistema nem altera o Git global do servidor. Ainda assim dá para otimizar deploy WordPress com Git no cPanel sem root usando apenas o home do usuário. A ideia é separar o “recebedor” do push (repositório bare) da árvore que o Apache/LiteSpeed serve (public_html), para o diretório .git nunca ficar exposto na web e o working tree de produção não brigar com merges manuais.

No Terminal do cPanel ou via SSH, confira o ambiente:

whoami
pwd
git --version
php -v
ls -la ~/public_html | head

Output esperado:
usuariocpanel
/home/usuariocpanel
git version 2.43.x
PHP 8.4.x (cli) ...
drwxr-x--- ... public_html

Se o Git não aparecer, use o ícone Git Version Control do painel quando existir, ou peça ao provedor o binário no PATH do jail da conta. O fluxo descrito abaixo funciona nos dois casos e se alinha a boas práticas de comparativo entre hospedagem de sites e VPS quando você ainda está em cPanel e não em servidor com root.

Repositório bare e chaves SSH do usuário cPanel

Versionamento remoto no cPanel começa com um bare repo na home, nunca dentro de public_html. Assim o push chega num caminho privado e só o hook escreve no document root. Crie a estrutura:

mkdir -p ~/git/seudominio.com.br.git
cd ~/git/seudominio.com.br.git
git init --bare
ls -la

Output esperado:
HEAD  config  description  hooks  info  objects  refs

No computador de desenvolvimento, garanta autenticação por chave (senha interativa quebra automação de CI local):

ssh-keygen -t ed25519 -C "deploy-seudominio" -f ~/.ssh/id_ed25519_cpanel
ssh-copy-id -i ~/.ssh/id_ed25519_cpanel.pub [email protected]

Teste o login sem senha e o Git remoto:

ssh -i ~/.ssh/id_ed25519_cpanel [email protected] "git --version && ls ~/git"

Output esperado:
git version 2.43.x
seudominio.com.br.git

No repositório local do tema ou do monorepo WordPress (sem core versionado se você preferir só custom code), adicione o remote:

git remote add cpanel [email protected]:~/git/seudominio.com.br.git
git remote -v

Quem prefere o Git Version Control do cPanel pode clonar ou criar o repo pelo painel e depois apontar o mesmo bare path; o essencial é o remote SSH do usuário, não o root. Para transferências pontuais de mídia fora do Git, o uso do FileZilla na hospedagem continua válido como complemento, nunca como substituto do pipeline.

Hook post-receive com checkout seletivo e exclusões

Automação de release no hook é o que transforma o bare em deploy real. Edite hooks/post-receive no bare com um script que faz checkout forçado em um diretório de trabalho e sincroniza para o alvo, protegendo configuração e uploads.

Atenção: um hook mal escrito pode sobrescrever wp-config.php ou apagar wp-content/uploads. Sempre teste em subdomínio de staging antes de apontar para public_html de produção.

cat > ~/git/seudominio.com.br.git/hooks/post-receive << 'EOF'
#!/bin/bash
set -e
TARGET="/home/usuariocpanel/public_html"
WORK="/home/usuariocpanel/deploy-work/seudominio"
BRANCH="main"

mkdir -p "$WORK"
git --work-tree="$WORK" --git-dir="/home/usuariocpanel/git/seudominio.com.br.git" checkout -f "$BRANCH"

rsync -a --delete \
  --exclude 'wp-config.php' \
  --exclude '.env' \
  --exclude 'wp-content/uploads/' \
  --exclude 'wp-content/cache/' \
  --exclude '.git/' \
  "$WORK"/ "$TARGET"/

# Opcional: limpar OPcache via CLI se disponível na conta
# php -r 'if (function_exists("opcache_reset")) { opcache_reset(); echo "opcache ok\n"; }'

echo "Deploy concluído em $(date -u +%Y-%m-%dT%H:%M:%SZ)"
EOF
chmod +x ~/git/seudominio.com.br.git/hooks/post-receive

No projeto local, mantenha um .gitignore explícito para não versionar segredos nem mídia:

wp-config.php
.env
wp-content/uploads/
wp-content/cache/
wp-content/upgrade/
*.log
node_modules/
.DS_Store

Faça o push inicial a partir da máquina de desenvolvimento:

git push cpanel main

Output esperado:
Enumerating objects: ...
Writing objects: 100% ...
remote: Deploy concluído em 2026-04-12T14:22:01Z
To 203.0.113.10:~/git/seudominio.com.br.git
 * [new branch]      main -> main

Confira no servidor se wp-config.php e uploads permaneceram intactos:

ssh [email protected] 'test -f ~/public_html/wp-config.php && echo config_ok; du -sh ~/public_html/wp-content/uploads 2>/dev/null || echo uploads_ausente_ok_se_staging'

Output esperado:
config_ok
128M    /home/usuariocpanel/public_html/wp-content/uploads

Se o site usa HTTPS após o deploy, valide o redirecionamento com o fluxo de redirecionar site HTTP para HTTPS já aplicado no .htaccess ou no painel, para não misturar URL de assets após a troca de arquivos.

Staging, build de assets e rotina segura de release

Pipeline de entrega contínua em cPanel fica mais seguro quando o TARGET do hook aponta primeiro para um subdomínio (staging.seudominio.com.br) com cópia do banco e constantes de debug controladas. Só depois de smoke test (home, login wp-admin, um formulário e uma página WooCommerce se houver) você altera TARGET para public_html ou promove com um segundo remote.

Para temas com npm/vite/webpack, rode o build na máquina local ou em CI externa e version only a pasta dist/build já compilada — a conta cPanel sem root raramente tem Node recente no PATH. Exemplo de ordem local:

npm ci && npm run build
git add -A && git status
git commit -m "release: assets e templates"
git push cpanel main

Evite rodar migrações pesadas de plugins no mesmo segundo do rsync em horário de pico. Prefira WP-CLI só se a hospedagem oferecer o binário no usuário; caso contrário, execute atualizações de banco pelo admin em janela controlada. Mantenha revisões e transients sob controle para o rsync não carregar lixo desnecessário a cada push.

Checklist rápido pós-deploy:

• HTTP 200 na home e em uma URL canônica interna
• wp-admin acessível com o mesmo usuário de sempre
• Permissões: diretórios 755 e arquivos 644 sob o UID da conta
• Nenhum .git visível via HTTPS em seudominio.com.br/.git/
• Uploads antigos ainda listados em wp-content/uploads

Quem administra vários sites na mesma conta pode repetir o padrão ~/git/siteA.git e ~/deploy-work/siteA com hooks distintos, sempre isolando configs. Se no futuro migrar para ambiente com root, o mesmo bare/hook se traduz para systemd timers ou runners, mas o modelo mental de “push → hook → rsync com exclude” permanece.

Problemas comuns e como resolver

Sintoma: permission denied ao fazer git push via SSH

Causa: chave não está em authorized_keys do usuário cPanel, shell da conta desabilitado ou path do remote incorreto.
Solução: confira SSH Access no painel, cole a chave pública em ~/.ssh/authorized_keys com permissão 600 na chave e 700 em .ssh, e use o remote no formato usuario@host:~/git/repo.git. Teste antes com ssh usuario@host sem senha.

Sintoma: site quebrou após o push (tela branca ou missing wp-config)

Causa: rsync sem --exclude removeu wp-config.php ou sobrescreveu .htaccess crítico; ou checkout trouxe branch errada.
Solução: restaure wp-config.php do backup da conta, ajuste o hook com as exclusões listadas, force BRANCH correta e redeploy. Em seguida limpe cache de plugin/OPcache se existir na conta.

Sintoma: hook não roda (push ok, arquivos antigos no public_html)

Causa: post-receive sem bit de execução, shebang inválido ou set -e abortando no rsync por path inexistente.
Solução: chmod +x hooks/post-receive, rode o script manualmente com bash -x apontando WORK/TARGET de teste e crie os diretórios com mkdir -p antes do checkout.

Sintoma: uploads sumiram ou galeria vazia

Causa: --delete no rsync sem excluir wp-content/uploads.
Solução: recupere uploads do backup cPanel, adicione --exclude 'wp-content/uploads/' e nunca versionar mídia de produção no Git. Trate mídia como artefato de backup, não de deploy.

Perguntas frequentes sobre otimizar deploy WordPress com Git no cPanel sem root

Dá para automatizar deploy de WordPress com Git no cPanel sem root?

Sim. Com SSH do usuário da conta, um repositório bare na home e um hook post-receive, o push atualiza o código no public_html sem privilégios de root. O fluxo usa apenas permissões do próprio usuário cPanel e Git Version Control ou Terminal.

O que é um repositório bare e por que usar no cPanel?

Um repositório bare guarda só o histórico Git, sem working tree de edição. No cPanel ele recebe o push e o hook post-receive faz checkout ou rsync para a pasta do site, evitando conflito entre arquivos de produção e o diretório .git.

Como evitar sobrescrever wp-config.php e uploads no deploy?

No hook, faça checkout seletivo ou rsync com exclusões de wp-config.php, .env e wp-content/uploads. Mantenha configuração e mídia fora do repositório ou em paths ignorados no .gitignore para o deploy não apagar dados de produção.

Preciso de Git Version Control do cPanel ou só SSH basta?

Os dois caminhos funcionam. O Git Version Control facilita clonar e puxar pelo painel; com Terminal/SSH você cria o bare, as chaves e o post-receive manualmente. Em contas sem o ícone Git, o fluxo via SSH do usuário costuma ser suficiente.

O deploy com Git no cPanel causa downtime no WordPress?

Em geral o downtime é mínimo se o hook atualiza arquivos de forma atômica ou rápida e você não roda migrações longas no meio do tráfego. Evite apagar a pasta inteira antes de copiar; prefira checkout em diretório e troca controlada, e teste antes em subdomínio de staging.

Conclusão

• Use bare repo na home + post-receive com rsync e exclusões para publicar sem root e sem expor .git.
• Proteja wp-config.php, .env e wp-content/uploads no .gitignore e no hook; valide sempre em staging.
• Padronize branch main, chave SSH e checklist HTTP/login após cada push para release previsível.

Leia também

• Comparativo de cache no cPanel: acelerar WordPress sem quebrar SSL
• Comparativo: criar staging WordPress no cPanel sem risco
• Otimizar imagens no WordPress sem plugin: do upload ao WebP

Precisa de ajuda com deploy WordPress no cPanel?

Uma hospedagem com SSH estável, Git disponível na conta e backups acessíveis reduz atrito na hora de automatizar o pipeline. Se quiser um ambiente alinhado a WordPress e cPanel com suporte para revisar SSH e permissões, fale com a equipe.

Ver planos de hospedagem de sites