Implementar no teu próprio servidor significa dar a um agente acesso semelhante a SSH a uma máquina que estás a pagar, onde outras coisas podem já estar alojadas. Esse é um nível de confiança diferente de publicar num subdomínio gratuito, e a configuração reflete isso — alguns campos, preenchidos uma vez, e depois cada build seguinte é um botão. Aqui estão as perguntas que as pessoas realmente fazem antes e depois de configurar um.
O que preciso para criar um destino?
Cinco coisas, em Definições → Implementação:
- Um nome que reconheças mais tarde — "prod-vps", "cliente-hostgator", o que quer que sobreviva a um menu suspenso às 23h
- Anfitrião e porta
- Credenciais SFTP
- Um caminho de webroot
Sem tokens de API, sem CLI para instalar no servidor, sem tarefa cron para vigiar. Se o teu anfitrião disponibiliza acesso SFTP — o que cobre quase todos os hosts partilhados, todos os VPS, todas as caixas WordPress geridas — ficas pronto em cerca de dois minutos.
Palavra-passe ou chave?
Chave, se o teu anfitrião suportar. As palavras-passe funcionam bem e guardamo-las associadas à tua conta, mas uma chave é um segredo a menos por aí — a diferença entre "revogar uma chave" e "repor uma palavra-passe em todos os sítios onde essa palavra-passe foi reutilizada" se algo correr mal mais tarde. Muitas configurações SFTP de alojamento partilhado barato só oferecem autenticação por palavra-passe, e isso também está bem. Só não reutilizes essa palavra-passe noutro lado.
Como encontro o caminho de webroot correto?
Este é o campo em que as pessoas se enganam da primeira vez, porque a resposta errada ainda parece plausível. Não é o seu diretório pessoal, não é /var/www — é exatamente a pasta a partir da qual o seu servidor web está configurado para servir conteúdo.
| Servidor | Webroot típico |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — ou algum caminho que um programador anterior nomeou há três anos por razões que já ninguém recorda |
Se não tiver a certeza, coloque um test.txt descartável na pasta que julga ser a correta usando qualquer cliente SFTP e depois verifique se carrega em yoursite.com/test.txt. Se se enganar aqui, o deploy vai à mesma reportar sucesso — o agente escreve fielmente os ficheiros na pasta errada, e fica a olhar para um site em produção que não mudou, sem perceber porquê.
Um destino pode cobrir mais do que um domínio?
Sim, e esta é a parte que poupa tempo real depois do teu primeiro site. Um destino é um servidor e um conjunto de credenciais — não está associado a um único domínio. Em Gestão de Domínios associas cada domínio a um destino com a sua própria substituição de webroot. Correr três sites a partir de um VPS com blocos de servidor Nginx?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
Um destino, três associações. Não estás a introduzir uma palavra-passe SSH três vezes, nem a manter três destinos quase idênticos que se desalinham no dia em que rodas uma chave e te esqueces de um deles. Clica em implementar em qualquer um dos três domínios e já sabe qual o servidor e qual a pasta — nunca escolhes no momento da implementação.
O que faz o agente realmente quando se liga?
Primeiro, olha à volta — apenas leitura, nada é escrito ainda. Essa inspeção está a verificar:
- Uma pasta vazia
- Uma versão anterior deste mesmo build
- Uma instalação antiga de WordPress
- Um marcador de "brevemente" que o teu anfitrião colocou lá por predefinição
Isso decide a estratégia. Um webroot vazio recebe um carregamento direto. Um webroot com algo já lá dentro é tratado com mais cuidado, porque muitas configurações reais têm coisas a viver ao lado do site que não devem desaparecer:
- A
.well-knownpasta para validação de SSL - Um
uploadsdiretório que ninguém colocou no git - A
wp-config.phpque ninguém quer que seja tocado
A tarefa aqui está mais próxima de "perceber o que mudou e reconciliar" do que "apagar e substituir".
Depois, antes que um único byte seja substituído, o webroot existente é capturado como uma versão no seu próprio host. Não é um registo de base de dados, não é uma diferença que calculamos e esperamos que esteja certa — é um instantâneo real do que lá estava. Isto importa mais no primeiríssimo deploy para qualquer alvo, porque esse deploy está sempre a pousar sobre algo, mesmo que esse algo seja nada. Pasta vazia, instantâneo vazio. Um site estático de há cinco anos que ninguém se lembra de ter criado — preservado exatamente, de graça, antes de ser tocado. Esse primeiro deploy é também aquele de que está menos certo, por isso é aquele onde isto mais importa.
Isto envia o meu código-fonte ou o site já compilado?
O site compilado, sempre. Para um site estático, isso são as páginas geradas. Para uma compilação de framework — Next.js, Vite, o que quer que o tipo de site exija — é o resultado compilado, a pasta dist ou build , nunca a árvore de código-fonte. Penso que esta é a decisão certa mesmo que signifique que não pode entrar via SSH e correr npm run dev contra o que está no servidor. Enviar o código-fonte significaria que o seu webroot de produção precisaria de um runtime Node e de um conjunto de ferramentas de compilação só para servir HTML — transformando uma máquina de hosting partilhado que nunca foi feita para correr um pipeline de build numa que passa a correr, e transformando cada deploy em "esperar que o servidor tenha memória suficiente para terminar npm install". Enviar apenas o resultado compilado mantém o webroot exatamente aquilo que um servidor de ficheiros estáticos espera. Aborrecido. Aborrecido é o que se quer às 2 da manhã quando algo está mal e está a olhar para aquela pasta a tentar perceber o que está realmente a ser servido.
Como sei que um deploy funcionou mesmo?
Depois do upload, o agente acede ao URL em produção e verifica se este resolve — nem 500, nem página em branco. O que quer que encontre, mais qualquer coisa que tenha notado durante a inspeção e sobre a qual queira a sua opinião ("este webroot tem uma pasta wp-content que deixei intacta, confirme que é o esperado"), fica no fio de conversa da build. Este é o padrão em toda esta plataforma: nem sucesso silencioso, nem falha silenciosa que se transforma num pedido de suporte. O agente diz-lhe o que viu e o que decidiu, no mesmo fio de conversa onde pediu a build.
O que está realmente no histórico de versões?
Cada deploy adiciona uma versão — não apenas o primeiro. Portanto, o histórico não são as suas compilações traçadas contra uma linha temporal abstrata; é a sequência literal do que foi servido a partir daquele webroot, por ordem, começando pelo que quer que lá estivesse antes de aparecer. A versão um é sempre esse estado anterior à plataforma, capturado automaticamente. Não precisa de pensar nisso.
O que é que reverter restaura, exatamente?
A versão anterior em produção, exatamente — não uma nova execução de uma compilação antiga, não uma aproximação. Os ficheiros reais que estavam a servir tráfego antes. Essa é uma garantia significativamente mais forte do que a maioria das funcionalidades de "rollback" que já usei noutros sítios, que normalmente significam "voltar a fazer deploy a partir de um commit antigo" e assumem silenciosamente que o seu processo de compilação é determinístico e que o seu ambiente não sofreu alterações desde então. Aqui, reverter é uma restauração de um instantâneo conhecido e válido, e é por isso que é seguro recorrer a ele sob pressão — não está a raciocinar sobre se o rollback se poderá comportar de forma diferente daquilo que está a reverter.
E o momento em que realmente precisa dele nunca é calmo; é "a nova compilação partiu o checkout e o tráfego está em produção neste momento".
Um clique, versão anterior restaurada, pronto. O raciocínio por detrás de tratar isto como uma funcionalidade de primeira classe em vez de um extra é explicado em Iterar sem medo — vale a pena ler uma vez, antes de precisar. Tanto o histórico como o controlo de restauro estão disponíveis no cartão da build e na vista de histórico do próprio alvo.
Isto também faz backup da minha base de dados?
Não, e prefiro dizê-lo claramente do que deixar alguém presumir o contrário. O histórico de versões no host cobre aquilo que este pipeline de deploy colocou no webroot. Se o seu site tiver uma base de dados, ou uploads de utilizadores, ou qualquer outra coisa que sofra alterações fora dos deploys, isso é uma questão completamente separada — reverter não lhe toca e não deve ser confundido com uma estratégia de backup que o faça.
