Hospedagem tradicional vs publicação por agente de IA não é uma disputa entre antigo e novo. É uma diferença de contrato.

Na hospedagem tradicional, você normalmente gerencia uma conta, um painel, um diretório público, DNS, SSL, permissões, banco de dados, e-mail e, em muitos casos, aplicações que continuam rodando naquele servidor. Na publicação por agente de IA, a pergunta costuma ser menor: o agente terminou os arquivos do site; como eles viram uma URL pública, verificável e compartilhável?

Se você escolhe pela ferramenta mais famosa, pode criar atrito desnecessário. Se escolhe pelo contrato certo, o deploy deixa de ser um improviso no fim da conversa.

O que é hospedagem tradicional

Hospedagem tradicional é o modelo em que um provedor entrega uma conta de hospedagem e você administra o site dentro dela.

Em ambientes com cPanel, por exemplo, a documentação oficial de File Manager mostra uma interface para gerenciar arquivos e pastas da conta. O mesmo painel permite trabalhar com web root, document root, upload de arquivos, permissões, compressão, extração e busca dentro de public_html.

A documentação de Domains também mostra que a gestão de domínios envolve document root, redirecionamento HTTPS, Zone Editor e, em alguns casos, limites ou recursos habilitados pelo provedor.

Isso é poderoso porque concentra muita operação em um só lugar. Mas também significa que o deploy é só uma parte de um ambiente maior.

O que é publicação por agente de IA

Publicação por agente de IA é um fluxo em que o agente não apenas escreve ou altera arquivos, mas também usa uma ferramenta para publicar o resultado e devolver evidência.

No Site no Ar, o contrato é propositalmente estreito:

  • public/index.html como página inicial;
  • páginas e assets preservados sob public/;
  • alterações versionadas por Session e Version;
  • slug público em <slug>.sitenoar.app;
  • URL final e status de deploy como resposta verificável.

A documentação de Publicação descreve esse fluxo. A Configuração mostra como conectar o MCP em qualquer cliente compatível e usar o mesmo caminho de edição e deploy.

A diferença principal é esta: a ferramenta não tenta virar uma plataforma de hospedagem completa. Ela resolve a última etapa de sites estáticos gerados por IA.

Comparação rápida

Critério Hospedagem tradicional Publicação por agente de IA
Unidade de trabalho conta, domínio, pasta pública, app e servidor pacote publicável, slug, deploy e URL
Melhor encaixe sites mantidos, PHP, WordPress, e-mail e banco landings, microsites e protótipos estáticos
Caminho comum painel, FTP/SFTP, Git, arquivo compactado MCP, file tools e deploy versionado
Risco comum mexer na pasta errada ou quebrar app existente publicar pacote errado ou sem index.html
Evidência final arquivos no servidor, domínio, SSL, logs slug, URL, status e pacote enviado
Domínio próprio parte central da conta de hospedagem etapa separada após primeiro publish
Papel do agente operador de ambiente publicador de artefato final

A pergunta não é “qual é mais moderno?”. A pergunta é “qual deles tem menos decisões implícitas para esta entrega?”.

Quando hospedagem tradicional ganha

Hospedagem tradicional continua fazendo sentido quando o site é mais do que um pacote estático.

Bons casos:

  • site WordPress, PHP ou outra aplicação ligada ao servidor;
  • projeto que usa e-mail, banco de dados e arquivos no mesmo provedor;
  • cliente que já paga um plano de hospedagem e quer manter tudo ali;
  • domínio, SSL e redirecionamentos controlados pelo mesmo painel;
  • equipe que já conhece o painel e tem rotina de backup;
  • aplicação que precisa de recursos específicos do provedor.

Também há fluxos com Git. A documentação de Git Version Control do cPanel mostra que cPanel pode gerenciar repositórios e deploys, mas isso traz seu próprio contrato: acesso shell pode importar, a implantação depende de configuração e o estado do repositório precisa estar limpo.

Para um projeto mantido, esse controle pode ser desejável. Para uma landing criada agora por um agente, pode ser peso demais.

Quando publicação por agente ganha

Publicação por agente ganha quando o agente já terminou o site e a pessoa precisa de uma URL.

Exemplos:

  • landing de campanha gerada em HTML, CSS e imagens;
  • página de validação de startup;
  • microsite de evento;
  • página temporária de cliente;
  • protótipo estático que precisa de revisão;
  • site criado no Codex, Cursor, Claude Code, ChatGPT ou Gemini CLI.

Nesses casos, a saída esperada não deveria ser “subi no servidor”. Deveria ser algo auditável:

  • arquivos alterados;
  • confirmação de index.html;
  • slug escolhido;
  • URL final;
  • status do deploy;
  • limitações encontradas.

Esse é o motivo de o Site no Ar separar publicação de domínio. Primeiro você coloca o site no ar em uma URL própria. Depois, se o conteúdo estiver aprovado, segue para Domínios próprios.

O problema do deploy no fim da conversa

Agentes de IA tendem a terminar bem a parte de criação e tropeçar na parte de publicação quando o destino é ambíguo.

Um pedido como este é perigoso:

Coloca esse site no ar.

Ele não diz:

  • onde publicar;
  • se pode alterar o repositório;
  • qual pasta é publicável;
  • se o domínio próprio entra agora;
  • se o deploy deve ser preview ou produção;
  • o que conta como sucesso.

Na hospedagem tradicional, isso pode virar upload no diretório errado. Em uma plataforma de aplicação, pode virar deploy no ambiente errado. Em uma ferramenta focada em publicação de pacote, o espaço de decisão é menor, mas ainda precisa de instruções.

O prompt seguro para hospedagem tradicional

Quando você realmente quer usar hospedagem tradicional, trate o agente como operador de ambiente:

Prepare este site para hospedagem tradicional.
Identifique a pasta publicável e confirme se há index.html.
Não altere DNS, SSL, banco de dados ou arquivos existentes sem pedir confirmação.
Explique se o destino esperado é public_html, outro document root ou um fluxo Git.
Antes de publicar, mostre o plano e os riscos.
Depois do deploy, retorne domínio, caminho publicado, arquivos alterados e checklist de verificação.

Esse prompt força o agente a separar criação de operação. Ele também evita que um site novo sobrescreva um app existente.

O prompt seguro para publicação por agente

Quando a entrega é um site estático, o pedido pode ser mais direto:

Chame get_context, atualize os arquivos em public/ e publique com deploy no Site no Ar.
Use o slug campanha-julho.
Confirme que existe public/index.html.
Use o MCP do Site no Ar para enviar os arquivos.
Depois retorne URL final, slug, status do deploy e o que foi verificado.
Não configure domínio próprio neste primeiro passo.

Esse pedido combina com o ciclo real de criação por IA: gerar, publicar, abrir, revisar e iterar.

E onde entram Vercel e plataformas modernas?

Vercel, Netlify e plataformas similares não são hospedagem tradicional no sentido clássico, mas também não são apenas “upload de arquivo”.

A documentação de deployments da Vercel lista caminhos como Git, Vercel Drop, CLI, Deploy Hooks e REST API. A documentação de vercel deploy também mostra uso por terminal e CI, incluindo o fato de que a URL do deployment sai no stdout.

Isso é excelente quando o projeto é uma aplicação web, precisa de preview, build, logs, ambientes e operação contínua. Para uma landing estática gerada por IA, pode ser mais plataforma do que a tarefa exige.

O bom agente não escolhe “Vercel”, “cPanel” ou “Site no Ar” por hábito. Ele olha para o artefato e escolhe o menor contrato correto.

Como decidir em 5 perguntas

Use este checklist:

Pergunta Se sim, tende a apontar para…
O site depende de PHP, banco ou painel legado? hospedagem tradicional
O projeto vive em Git com previews e build? Vercel, Netlify ou plataforma de aplicação
O agente já tem HTML/CSS/assets finais? publicação direta por agente
O usuário precisa só de uma URL para revisar? Site no Ar
O domínio próprio precisa ser configurado já? separar deploy e DNS em etapas

Não existe vitória universal. Existe encaixe.

O cuidado com domínio próprio

Domínio próprio costuma ser onde a automação fica confusa.

Na hospedagem tradicional, o domínio pode estar acoplado à conta, ao document root e ao painel DNS. No Site no Ar, o endereço <slug>.sitenoar.app continua ativo e o Custom Hostname é uma etapa separada. A documentação de Verificação e DNS deixa claro que DNS pode levar de minutos a horas para convergir.

Por isso, para agentes, o melhor fluxo é:

  1. publicar em uma URL padrão;
  2. abrir e revisar o conteúdo;
  3. corrigir o site se necessário;
  4. só então configurar domínio próprio;
  5. verificar DNS e SSL sem ficar trocando registros a cada minuto.

Isso reduz o risco de misturar problema de conteúdo com problema de DNS.

Resumo prático

Use hospedagem tradicional quando o site precisa viver dentro de uma conta de hospedagem com painel, domínio, banco, e-mail, PHP, WordPress ou operação contínua já estabelecida.

Use publicação por agente de IA quando o agente gerou arquivos estáticos e falta apenas transformar o pacote em uma URL pública, verificável e fácil de compartilhar.

O melhor caminho não é o mais automático. É o caminho que deixa claro o artefato, o destino, a evidência e o próximo passo.

Para aplicar esse fluxo no Site no Ar, comece pela Configuração, revise o contrato de Publicação e use Site no Ar vs Vercel ou Site no Ar vs Netlify quando o projeto pedir uma plataforma maior.