Deploy automático precisa de contrato, não de fé

Gemini CLI + Site no Ar funciona melhor quando o deploy automático vira um contrato repetível: o agente sabe qual build rodar, qual pasta publicar, qual slug manter, como enviar os arquivos e qual evidência devolver no fim.

Sem esse contrato, “publique meu site” pode significar coisas diferentes: criar uma URL nova, sobrescrever um Site existente, publicar uma pasta errada ou entregar um link sem abrir a página. Com o MCP do Site no Ar, o fluxo pode ser automatizado, mas as decisões críticas continuam explícitas.

Este guia parte do mesmo setup do guia de Gemini CLI e do contrato de publicação. Se sua conta já foi migrada para outro cliente depois das mudanças recentes no ecossistema Gemini CLI, adapte os comandos do cliente, mas mantenha o mesmo contrato de deploy.

Quando automatizar faz sentido

Use um prompt de deploy automático quando:

  • a build do projeto já é conhecida;
  • a pasta publicável já foi validada pelo menos uma vez;
  • o slug já foi aprovado;
  • a página não exige revisão manual antes de ficar pública;
  • o agente consegue acessar os arquivos localmente;
  • você quer repetir publicação e verificação sem reescrever os mesmos passos.

Para primeira configuração, prefira o caminho mais curto: conectar o MCP, autenticar e publicar uma página pequena. O artigo Como publicar sites com Gemini CLI usando MCP cobre esse primeiro teste.

Checklist antes de dar autonomia

Antes de pedir deploy automático, deixe o Gemini CLI com uma lista objetiva:

Decisão Exemplo
Comando de build bun run build, npm run build ou nenhum, se já houver saída
Pasta publicável ./dist
Arquivo inicial index.html na raiz da pasta
Slug campanha-julho
Tipo de ação criar Site novo ou atualizar Site existente
Verificação final abrir URL e conferir assets principais
Bloqueios esperados login, limite de plano, slug ocupado, build quebrado

Esse checklist reduz duas classes de erro: publicar o lugar errado e declarar sucesso cedo demais.

Conecte e valide o MCP

Se o Site no Ar ainda não estiver registrado no Gemini CLI, adicione o servidor:

Terminal window
gemini mcp add --transport http sitenoar https://mcp.sitenoar.dev

Na sessão do Gemini, autentique:

/mcp auth sitenoar

Depois peça uma verificação sem upload:

Use o MCP do Site no Ar e teste a conexão.
Não publique nada.
Responda se a autenticação está pronta e quais ações de publicação você consegue executar.

Se você trabalha com mais de um agente, salve também o prompt oficial:

Me ajude a conectar o Site no Ar aqui. O guia oficial, com o passo a passo por cliente, está em https://sitenoar.dev/agent-setup-prompt.md

Ele ajuda o agente a alinhar ferramentas, pacote e expectativas antes de mexer no Site.

Prompt de deploy automático

Quando o site estiver pronto, use um prompt completo:

Automatize o deploy deste projeto pelo MCP do Site no Ar.


Contrato:
1. Rode o build padrão do projeto se a saída ainda não estiver atualizada.
2. Publique apenas a pasta ./dist.
3. Use index.html como página inicial.
4. Slug: campanha-julho
5. Se o Site já existir com esse slug, atualize o mesmo Site.
6. Envie os arquivos pelo fluxo canônico do Site no Ar.
7. Acompanhe o deploy até sucesso, falha ou bloqueio claro.
8. Abra a URL final e verifique se home, CSS e imagens carregam.


Na resposta final, informe arquivos alterados, slug,
URL final, status do deploy e resultado da verificação.
Não ignore erros. Se algo bloquear, pare e peça a decisão necessária.

Esse texto evita que o agente faça escolhas implícitas. Ele também deixa claro que automação não termina no upload; termina na URL verificada.

Atualizar uma URL existente

Para campanhas, propostas e demos, criar um Site novo a cada revisão costuma atrapalhar. Quando a intenção é manter o mesmo link, diga isso no prompt:

Atualize o Site existente do slug campanha-julho.
Não crie um novo Site se o slug já existir.
Publique a nova versão da pasta ./dist e confira a mesma URL final.

Esse detalhe muda a operação esperada. O agente deve procurar ou reutilizar o Site certo antes de iniciar o envio.

O pacote que deve ser enviado

O Site no Ar trabalha com arquivos versionados sob public/:

  • index.html, quando a publicação é uma página única;
  • arquivos sob public/, quando há múltiplas páginas ou assets.

Em um deploy automático pelo Gemini CLI, o agente chama get_context, inspeciona o repositório e altera os arquivos pelas file tools. Depois publica com deploy, sem montar um pacote intermediário para cada mudança.

Se o agente tentar resumir arquivos em texto, corrija o caminho:

Não cole o conteúdo dos arquivos.
Use o pacote local gerado pela build e envie pelo fluxo de upload do MCP.

Como transformar em rotina

Depois que o primeiro deploy automático funcionar, salve uma versão do prompt com variáveis:

Variável Exemplo
{{build_command}} bun run build
{{publish_dir}} ./dist
{{slug}} campanha-julho
{{mode}} criar ou atualizar
{{checks}} home, CSS, imagens

Essa rotina é útil para times que criam muitas páginas pequenas: landing pages de campanha, páginas de captura, propostas comerciais e protótipos para validação.

Para fluxos parecidos em outros clientes, leia Como automatizar o deploy de sites com Claude Code via MCP e Cursor Agent + Site no Ar: deploy automático sem linha de terminal. O princípio é o mesmo: o agente pode operar o deploy, mas a resposta final precisa trazer evidência.

Onde colocar uma trava manual

Nem todo deploy deve ir direto para produção. Use uma trava quando a página envolver cliente, anúncio pago, preço, domínio principal ou conteúdo jurídico:

Prepare o deploy e mostre o plano.
Não envie arquivos ainda.
Depois que eu aprovar, publique pelo MCP do Site no Ar.

Esse modo ainda economiza trabalho. O agente roda build, identifica pasta, confere pacote e mostra o que será publicado. A diferença é que o upload só acontece após aprovação.

Falhas que o agente deve classificar

Um bom fluxo automático transforma erro em decisão:

Falha Resposta esperada
Build quebrou mostrar comando e trecho relevante do erro
Pasta não existe pedir confirmação da pasta publicável
Login expirou pedir novo /mcp auth sitenoar
Limite de conta apontar limite antes de tentar de novo
Slug ocupado pedir decisão entre atualizar ou trocar slug
Deploy falhou informar estado final e próxima ação
URL não abre não declarar sucesso até investigar a falha

Se a resposta final não tiver status, URL e verificação, trate como deploy incompleto.

O próximo padrão do time

O melhor uso de Gemini CLI + Site no Ar não é publicar uma vez. É padronizar como cada site sai do agente para uma URL verificável: build, pasta, pacote, slug, deploy, abertura da URL e relato final.

Com esse contrato, o deploy automático deixa de ser um comando especial e vira parte natural do fluxo de criação. O agente ajuda a gerar e revisar o site, o Site no Ar cuida da publicação e você mantém controle sobre quando um link fica público.