Checklist pos-deploy em VPS com Docker e Nginx: o que validar antes de comemorar

Um deploy pode terminar sem erro no terminal e ainda assim deixar algo importante quebrado. A home pode abrir, mas a rota interna falhar. O container pode estar de pe, mas a API nao conectar no banco. O formulario pode salvar contato, mas nao enviar e-mail. A tag do Google pode carregar, mas a conversao nao disparar. Em site editorial, o conteudo pode estar no ar, mas sitemap, feed ou ads.txt ainda apontarem para uma versao antiga.

Por isso, pequenas empresas que publicam em VPS precisam de um checklist pos-deploy. Ele nao precisa ser complexo. Precisa ser repetivel, claro e usado antes de considerar a publicacao concluida.

Este guia organiza uma validacao pratica para ambientes com Docker, Nginx, backend, banco, formulario, Google Ads, AdSense e conteudo tecnico.

1. Confirme se a versao certa foi publicada

O primeiro erro pos-deploy e validar a versao errada. Antes de testar comportamento, confirme se o que esta em producao corresponde ao commit, imagem ou pacote esperado.

• registre commit, branch ou tag publicada;
• confira se a pipeline terminou com sucesso;
• verifique data e horario do deploy;
• confirme se frontend e backend foram atualizados;
• anote quem executou e quem validou.

A pagina de gestao de mudancas tecnicas ajuda a transformar essa etapa em rotina com criterios de sucesso, evidencia e rollback.

2. Teste a entrada publica do site

Abra o dominio como um visitante abriria. Depois, teste tambem as variacoes que costumam quebrar em migracoes e ajustes de proxy.

• dominio raiz responde em HTTPS;
• versao com www redireciona ou responde conforme definido;
• HTTP redireciona para HTTPS;
• certificado TLS cobre os nomes usados;
• rotas internas do React abrem ao recarregar a pagina;
• rotas de API sao encaminhadas para o backend correto;
• Nginx nao aponta para porta antiga ou container errado.

Se o site usa Cloudflare, confira tambem se o proxy esta coerente com o desenho do ambiente. O artigo DNS, Cloudflare e e-mail mostra por que site e e-mail precisam ser validados separadamente.

3. Confira containers, portas e redes

Em VPS com Docker, o sistema pode ter varios containers convivendo: frontend, backend, banco, proxy, jobs e ferramentas auxiliares. O ponto critico e separar porta interna, porta exposta e rota publica.

Checklist de Docker:

• containers esperados estao rodando;
• containers antigos nao estao recebendo trafego por engano;
• nomes de servico batem com a configuracao do Nginx;
• volumes de banco permanecem montados;
• variaveis de ambiente foram carregadas;
• health checks nao indicam falha;
• logs nao mostram reinicio em loop.

O guia de deploy em VPS aprofunda arquitetura, Docker Compose, Nginx, SSL, banco e validacao.

4. Valide backend, banco e migrations

Quando o deploy inclui backend, nao basta o container estar online. A aplicacao precisa iniciar, conectar no banco, aplicar migrations quando houver e responder endpoints essenciais.

• health check do backend responde;
• logs de inicializacao nao mostram erro de banco;
• migrations foram aplicadas na ordem correta;
• endpoint publico de configuracao responde;
• API de artigos e materiais retorna dados;
• nao ha erro recorrente em logs de backend;
• pool de conexao nao esta saturado.

Se o deploy mudou schema ou conteudo, confirme tambem se existe backup recente. O artigo Backup e restauracao de banco explica por que restore testado importa mais do que apenas ter um arquivo salvo.

5. Teste a jornada real do visitante

Depois dos testes tecnicos, navegue pelo site como usuario. Isso pega problemas que status HTTP sozinho nao mostra.

• home carrega com layout correto;
• menu e rodape navegam para paginas importantes;
• artigos abrem e exibem indice, termos tecnicos e relacionados;
• busca do topo retorna resultados;
• materiais gratuitos abrem;
• recomendacoes e links externos funcionam;
• paginas legais e politica editorial estao acessiveis;
• nenhum bloco importante sobrepoe texto ou quebra em mobile.

Para portais que dependem de AdSense, essa etapa e parte da qualidade editorial. Navegacao confusa, pagina quebrada ou conteudo inacessivel prejudicam usuario, indexacao e monetizacao.

6. Teste formulario, SMTP e UTM

Formulario merece teste real em producao controlada. A tela pode mostrar sucesso mesmo quando a notificacao por e-mail falha, entao valide a jornada inteira.

• envie um contato de teste identificavel;
• confirme se o backend salvou o registro;
• confirme se o e-mail interno chegou;
• confirme remetente, Reply-To e assunto;
• verifique se UTM source, medium e campaign foram preservadas quando existirem;
• confirme se a mensagem ao usuario e clara;
• confira logs se houver atraso ou falha.

O artigo Google Ads, UTM e formulario conecta campanha, landing page, frontend, backend e e-mail de notificacao. Para falhas de envio, use tambem o playbook de formulario que salva mas nao envia e-mail.

7. Valide SEO tecnico, feed e AdSense

Sites editoriais precisam que a camada de descoberta continue funcionando depois de cada deploy. Um arquivo tecnico errado pode atrasar indexacao ou revisao de monetizacao.

• /sitemap.xml responde e contem rotas novas;
• /robots.txt nao bloqueia paginas importantes;
• /ads.txt continua acessivel na raiz;
• /feed.xml lista os artigos publicados;
• canonical e meta description estao coerentes;
• artigos novos aparecem em /artigos e no mapa do site;
• paginas de privacidade, cookies, termos, publicidade, autoria e fontes continuam acessiveis.

Essa validacao protege tanto SEO quanto AdSense. Ela tambem evita pedir revisao quando a producao ainda esta servindo bundle, sitemap ou backend antigos.

8. Confira tags e conversoes do Google

Se o site usa Google Ads, Analytics ou AdSense, abra o Tag Assistant depois do deploy. A tag global pode aparecer, mas isso nao garante que o evento certo esteja disparando no momento certo.

• Google tag aparece uma vez;
• Analytics recebe visualizacao de pagina;
• tag de Google Ads esta presente;
• evento de conversao dispara apos envio real do formulario;
• nao ha duplicidade evidente de tags;
• UTMs chegam ao lead e ao e-mail;
• AdSense nao mostra erro por ads.txt ausente ou dominio errado.

Para campanhas pagas, esse teste evita gastar midia sem medir resultado. Para monetizacao, ajuda a separar problema de rastreamento, aprovacao, inventario e tempo de preenchimento de anuncios.

9. Guarde evidencias do deploy

Sem evidencia, a empresa depende de memoria. Depois de validar, registre o que foi testado.

• data e horario da publicacao;
• commit ou versao;
• URLs testadas e status observado;
• resultado do formulario de teste;
• confirmacao de e-mail recebido;
• prints ou anotacoes do Tag Assistant;
• resultado de sitemap, robots, ads.txt e feed;
• trechos de logs relevantes;
• decisao final: manter versao, monitorar ou fazer rollback.

A pagina de evidencias tecnicas mostra como guardar provas uteis sem expor segredo, dado sensivel ou informacao desnecessaria.

10. Decida entre seguir, monitorar ou voltar

O checklist nao serve apenas para marcar itens. Ele precisa orientar decisao. Se algo critico falhou, defina se a versao pode ficar no ar, se precisa de correcao rapida ou se deve voltar.

Rollback costuma ser indicado quando:

• home ou rotas principais ficam indisponiveis;
• backend nao inicia ou nao conecta no banco;
• formulario comercial para de funcionar;
• erro afeta dados ou seguranca;
• sitemap, robots ou ads.txt ficam inacessiveis em momento sensivel;
• logs mostram falha recorrente sem causa clara.

Quando a falha e menor, pode fazer sentido manter a versao e abrir correcao. O importante e registrar a decisao e nao transformar cada deploy em improviso.

Checklist rapido pos-deploy

1. Confirme commit, pacote e horario publicados.
2. Teste dominio raiz, www, HTTPS e rotas internas.
3. Verifique Nginx, Docker, portas, redes e containers antigos.
4. Valide backend, banco, migrations e health check.
5. Navegue pela home, artigos, busca, materiais e paginas legais.
6. Envie formulario real e confira e-mail, logs e UTMs.
7. Abra sitemap.xml, robots.txt, ads.txt e feed.xml.
8. Use Tag Assistant para validar tags e conversao.
9. Guarde evidencias antes/depois.
10. Decida manter, monitorar, corrigir ou fazer rollback.

Um bom checklist pos-deploy reduz ansiedade porque transforma publicacao em processo. Ele nao elimina falhas, mas diminui o tempo para encontra-las, corrigi-las e aprender com elas.

Para pequenas empresas, isso e especialmente importante: o mesmo site que mostra conteudo, recebe leads, sustenta campanhas e busca aprovacao no AdSense precisa ser tratado como operacao. Publicar e apenas metade do trabalho. Validar e o que torna o deploy confiavel.