Cursor Agent + Site no Ar: deploy automático sem linha de terminal

O que significa sem linha de terminal

Publicar com Cursor Agent sem linha de terminal não quer dizer publicar sem critério. Quer dizer que você não precisa sair do editor para lembrar comandos de build, abrir painel de hospedagem, compactar arquivos ou repetir um deploy manual no fim da conversa.

O agente continua trabalhando dentro do projeto. Ele lê a estrutura, identifica a saída publicável, confirma se existe index.html, usa o MCP do Site no Ar e acompanha a publicação até ter uma URL final. O seu papel é dar limites: qual pasta pode ser enviada, qual slug deve ser usado e o que precisa ser verificado antes de considerar a entrega pronta.

Se o MCP ainda não está configurado no Cursor, comece pelo guia Cursor + MCP: como configurar o Site no Ar no seu workflow ou pela documentação de Cursor. Este texto assume que o servidor remoto já aparece no painel de MCP do editor.

Onde o Cursor Agent entra no deploy

O melhor uso do Cursor Agent é tirar a ambiguidade entre “o site está pronto localmente” e “o site está publicado”. Ele consegue revisar arquivos, rodar o fluxo padrão do projeto quando for necessário e chamar a ferramenta de publicação sem trocar de ambiente.

Um fluxo seguro fica assim:

Esse desenho evita o erro de transformar o agente em um botão de deploy escondido. A publicação vira parte da conversa, mas cada decisão importante continua aparecendo na resposta final.

Prompt para publicar sem digitar comandos

Depois que o Site no Ar estiver conectado, use um pedido fechado. Troque o slug e a pasta quando já souber os valores:

Use o Cursor Agent para publicar este projeto pelo MCP do Site no Ar.

Objetivo: colocar a versão atual no ar sem eu digitar comandos de deploy.

Regras:
1. Revise o projeto e identifique a pasta publicável.
2. Rode build somente se o projeto exigir.
3. Confirme que a pasta final tem index.html na raiz.
4. Publique pelo MCP do Site no Ar.
5. Slug desejado: minha-campanha
6. Depois abra a URL final e verifique home, CSS, imagens e links principais.

Na resposta final, informe arquivos alterados, slug usado, URL,
status do deploy, comandos executados e resultado da verificação.
Se faltar decisão humana, pare antes de publicar.

O trecho “se faltar decisão humana, pare” é importante. Slug ocupado, domínio próprio, warnings de build ou arquivos fora da pasta final são decisões que podem mudar a entrega. O agente deve explicar o bloqueio em vez de improvisar.

Quando deixar o agente rodar build

Em sites estáticos simples, talvez não exista build. Em projetos com Astro, Vite, Next exportado ou outro framework que gere uma pasta final, o build pode ser necessário antes do publish.

Peça para o agente justificar:

Antes de publicar, diga se este projeto precisa de build.
Se precisar, rode o comando padrão do package.json.
Se não precisar, explique qual pasta já está pronta para publicar.

Essa pergunta protege dois lados. Você evita publicar código-fonte que ainda não virou site final e também evita rodar comandos desnecessários quando a pasta já contém HTML, CSS, JS e assets finais.

O contrato de publicação é o mesmo para todos os clientes: index.html vira a home, outros arquivos .html viram rotas e CSS, JavaScript, imagens e fontes seguem os caminhos enviados.

O que não automatizar no escuro

Algumas decisões parecem pequenas, mas afetam produto, marca ou cliente. Deixe explícito quando o Cursor Agent deve parar:

• escolher outro slug quando o desejado estiver ocupado;
• remover arquivos antigos de um Site já existente;
• publicar em um Site de produção em vez de um rascunho;
• aceitar warnings de build;
• configurar domínio próprio;
• publicar arquivos com variáveis ou secrets faltando;
• trocar links de CTA sem confirmação.

Para entregas de cliente, use um modo em duas etapas:

Prepare o plano de publicação pelo MCP do Site no Ar.
Não envie arquivos ainda.
Mostre pasta final, slug proposto, arquivos principais e riscos.
Depois que eu aprovar, publique e verifique a URL.

Esse fluxo continua sem linha de terminal para você, mas cria uma pausa de aprovação onde ela faz sentido.

Como verificar a URL final

Não aceite apenas “deploy concluído”. A resposta final deve dizer o que abriu e o que foi conferido.

Peça:

Depois do deploy, abra a URL publicada e verifique:
- se a home carrega a partir de index.html;
- se CSS e imagens aparecem;
- se links internos principais funcionam;
- se a versão publicada parece a versão local esperada;
- se o slug final é o slug aprovado.

Se a página abrir sem estilo, normalmente faltou um asset em public/ ou o HTML aponta para um caminho local. O agente deve corrigir os arquivos e republicar no mesmo Site quando a intenção for atualizar a mesma URL.

Próximo passo

Cursor Agent + Site no Ar funciona melhor quando o deploy vira um ritual repetível: revisar, preparar saída, publicar, verificar e registrar a URL. Para um roteiro mais amplo de criação de landing, leia Como criar e hospedar uma landing page com Cursor em 5 minutos. Para o publish direto a partir do editor, o guia Como publicar sites direto do Cursor sem sair do editor mostra um pedido ainda mais enxuto.

O ganho não é esconder a infraestrutura. É fazer o agente terminar a entrega no mesmo lugar onde criou o site, com evidência suficiente para você confiar na URL publicada.