cPanel, Vercel ou Site no Ar? A resposta certa depende menos da ferramenta e mais do tipo de projeto que você está tentando publicar.

cPanel é um painel de hospedagem tradicional. Vercel é uma plataforma para aplicações e sites com build, previews e operação moderna. Site no Ar é uma camada focada em publicar sites estáticos gerados por agentes de IA com file tools, slug e URL verificável.

As três opções podem publicar um site. O erro é usar as três como se resolvessem o mesmo problema.

A pergunta que decide quase tudo

Antes de escolher, responda:

O que já existe no fim do trabalho: uma conta de hospedagem, uma aplicação em desenvolvimento, ou um pacote estático pronto?

Se existe uma conta de hospedagem com domínio, e-mail, PHP, banco e arquivos, cPanel pode ser o centro natural. Se existe uma aplicação web com repositório, build e preview, Vercel tende a encaixar melhor. Se existe uma pasta final com index.html, CSS, imagens e a necessidade de uma URL, Site no Ar é o caminho menor.

Essa distinção evita dois erros comuns:

  • levar uma landing simples para uma plataforma complexa;
  • tentar operar uma aplicação real como se fosse só upload de arquivos.

Comparação direta

Situação cPanel Vercel Site no Ar
Site institucional em hospedagem existente forte possível, mas pode sobrar bom se for estático e gerado por IA
WordPress, PHP ou banco no provedor forte não é o encaixe principal não é o encaixe
App Next.js com previews fraco ou manual forte não é o encaixe principal
Landing estática gerada por agente possível, mas operacional possível, mas pode ser demais forte
Prova de conceito com URL rápida depende de acesso e painel bom se já houver projeto forte
Domínio e DNS no mesmo provedor forte forte dentro da plataforma etapa separada após o primeiro site
Agente precisa publicar sem sair do fluxo depende do acesso ao ambiente bom com CLI/API/MCP configurado forte com MCP e file tools

Nenhuma coluna deve vencer sempre. O objetivo é reduzir o número de decisões erradas que o agente ou a pessoa precisam tomar.

Quando escolher cPanel

Escolha cPanel quando o projeto pertence a uma conta de hospedagem tradicional.

Bons sinais:

  • o site usa PHP, WordPress ou outra aplicação hospedada no provedor;
  • a mesma conta cuida de domínio, e-mail, arquivos e banco;
  • a equipe já administra backups, SSL e arquivos pelo painel;
  • o cliente exige que o site continue naquele provedor;
  • o deploy precisa respeitar uma pasta pública existente;
  • o fluxo de publicação já passa por File Manager, FTP/SFTP ou Git no servidor.

A documentação de File Manager do cPanel mostra a lógica desse mundo: arquivos, pastas, web root, upload, permissões e extração de arquivos compactados. A documentação de Domains liga domínios a document root, DNS e HTTPS.

Para agentes de IA, isso significa que publicar em cPanel é uma operação de ambiente. O agente precisa saber onde pode mexer e onde não pode.

O prompt seguro para cPanel

Use algo assim:

Prepare uma publicação para cPanel.
Identifique a pasta final do site e confirme se existe index.html.
Não sobrescreva arquivos existentes sem listar o impacto.
Explique qual document root deve receber os arquivos.
Se o fluxo exigir ZIP, FTP, File Manager ou Git, descreva o passo a passo antes de executar.
No final, retorne arquivos alterados, caminho publicado, domínio testado e riscos pendentes.

Esse prompt deixa claro que o agente não está só fazendo upload. Ele está tocando uma conta de hospedagem.

Quando escolher Vercel

Escolha Vercel quando o projeto é uma aplicação ou site dentro de um fluxo de desenvolvimento moderno.

Bons sinais:

  • o projeto usa Next.js, SvelteKit, Nuxt ou outro framework com build;
  • existe repositório Git, branch, pull request e preview;
  • o time precisa de logs, ambientes, rollback e promoção;
  • há funções, runtime, variáveis, proteção ou integração de plataforma;
  • a entrega não é só uma pasta estática, mas uma aplicação mantida.

A documentação de deployments da Vercel lista métodos como Git, Vercel Drop, CLI, Deploy Hooks e REST API. O comando vercel deploy também é adequado para terminal e CI, e a própria documentação trata a URL do deployment como saída padrão do comando.

Vercel também tem um MCP oficial em beta para agentes interagirem com projetos, deployments, logs e documentação. Então não é correto dizer que Vercel não serve para IA. Serve, especialmente quando o agente está operando um projeto Vercel.

O prompt seguro para Vercel

Use algo assim:

Prepare este projeto para deploy na Vercel.
Confirme framework, comando de build, pasta de saída e variáveis necessárias.
Publique como preview, não produção, a menos que eu confirme.
Depois retorne URL do deployment, ambiente, branch ou commit, status e logs relevantes.
Se faltar configuração, pare e explique antes de tentar corrigir.

Aqui o agente precisa respeitar plataforma, ambiente e ciclo de release. A resposta final deve falar de deployment, não apenas de URL.

Quando escolher Site no Ar

Escolha Site no Ar quando o site é estático e pode ser mantido sob public/.

Bons sinais:

  • o agente gerou index.html, CSS, imagens e JavaScript;
  • a entrega é uma landing, microsite, campanha ou protótipo;
  • você quer uma URL pública sem configurar pipeline;
  • o trabalho nasceu em Codex, Cursor, Claude Code, ChatGPT ou outro agente;
  • o domínio próprio pode vir depois da primeira revisão;
  • a resposta final precisa ser slug, status e URL.

A documentação de Publicação mostra como o agente edita public/index.html, assets e public/sitemap.xml pelas file tools antes de publicar com deploy. A Configuração usa o mesmo prompt central em todos os clientes compatíveis.

O Site no Ar é deliberadamente menor do que cPanel e Vercel. Ele não tenta cuidar de e-mail, banco, runtime ou operação de app. Ele resolve o último passo de uma categoria específica: arquivos de site criados por agente virando URL.

O prompt seguro para Site no Ar

Use algo assim:

Chame get_context, atualize os arquivos em public/ e publique com deploy no Site no Ar.
Use o slug demo-cliente.
Confirme que index.html está na raiz do pacote.
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 publish.

Esse prompt é pequeno porque o contrato também é pequeno.

Como escolher por tipo de projeto

Landing page de campanha

Se a landing foi gerada por IA e já tem arquivos finais, use Site no Ar.

Se a campanha faz parte de um projeto maior em Vercel, use Vercel para manter preview e histórico.

Se o cliente exige publicar dentro da hospedagem atual, use cPanel com um plano explícito de document root e backup.

Site WordPress ou PHP

Use cPanel ou outro ambiente tradicional compatível com a stack.

Site no Ar não é o caminho para aplicação dinâmica. Vercel também não é substituto direto para uma conta PHP compartilhada quando o projeto depende desse runtime.

App moderno com framework

Use Vercel quando o projeto depende de build, preview, branch, logs e operação contínua.

Site no Ar pode servir para uma versão estática exportada ou uma landing isolada, mas não deve ser usado para fingir que uma aplicação dinâmica virou estática.

Protótipo de cliente

Use Site no Ar quando a prioridade é abrir uma URL para revisar conteúdo, layout e proposta.

Depois da aprovação, você decide se o protótipo continua como site estático, migra para Vercel ou entra em uma hospedagem tradicional do cliente.

Site de cliente com domínio próprio

Separe publicação e DNS.

Primeiro publique em uma URL verificável. Depois configure domínio próprio com calma. No Site no Ar, siga Domínios próprios. Em cPanel ou Vercel, siga o painel da plataforma escolhida e confirme os registros de DNS antes de declarar que terminou.

O erro de tratar IA como atalho universal

Agentes de IA não eliminam contratos de deploy. Eles tornam contratos ruins mais perigosos.

Se o destino é cPanel, o agente precisa entender conta, pasta, permissões e domínio. Se o destino é Vercel, precisa entender build, ambiente, preview e logs. Se o destino é Site no Ar, precisa entender Site ID, arquivos, slug e URL.

Quando o prompt ignora isso, a automação vira chute.

Um pedido melhor:

Analise este projeto e recomende entre cPanel, Vercel e Site no Ar.
Considere stack, pasta publicável, necessidade de build, domínio, Git, preview e se o resultado é estático.
Não publique ainda.
Responda com a recomendação, riscos e checklist de verificação.

Só depois disso vale pedir o publish.

Resumo prático

Escolha cPanel quando o projeto pertence a uma hospedagem tradicional com painel, domínio, banco, e-mail, PHP ou rotina operacional existente.

Escolha Vercel quando o projeto é uma aplicação web ou site mantido com Git, builds, previews, ambientes e logs.

Escolha Site no Ar quando o agente precisa manter arquivos estáticos e transformá-los em uma URL pública com o mínimo de caminho operacional.

Para continuar comparando, leia Hospedagem tradicional vs publicação por agente de IA, Site no Ar vs Vercel e Por que agentes de IA não deveriam usar GitHub Pages para publicar.