Hospedar um site Astro começa por uma pergunta que muita gente pula: o seu build gera só arquivos ou também precisa de um servidor rodando? A resposta decide quais plataformas servem, quanto de configuração você vai fazer e o que pode dar errado depois.

Este guia explica essa diferença, mostra como publicar Astro na Cloudflare, na Netlify, na Vercel, numa hospedagem tradicional ou VPS e no Site no Ar, e termina com uma tabela para comparar. Nenhuma opção é a melhor em todos os casos; cada uma encaixa num tipo de projeto e de rotina.

Antes de escolher: o que o seu build gera

O Astro tem dois modos de entregar páginas, e um projeto pode usar os dois ao mesmo tempo. Se quiser revisar os conceitos, veja o que é Astro.

Modo O que o build produz O que a hospedagem precisa fazer
Estático (padrão) pasta dist/ com HTML, CSS, imagens e JS das ilhas servir arquivos
Sob demanda código de servidor gerado por um adapter executar esse código a cada requisição
Misto maioria das páginas em dist/, algumas no servidor as duas coisas, na mesma plataforma

Um site estático roda em praticamente qualquer lugar que entregue arquivos. Já a renderização sob demanda exige um adapter da plataforma, como os oficiais para Cloudflare, Netlify, Vercel e Node. Isso amarra o projeto a um ambiente de execução: trocar de hospedagem passa a envolver trocar o adapter e testar de novo.

Landing pages, sites institucionais, blogs e portfólios costumam ser 100% estáticos ou quase. Páginas sob demanda aparecem quando há formulário que grava dados, área com login ou conteúdo que muda a cada visita.

O guia de deploy do Astro resume as configurações típicas: comando de build astro build (ou npm run build) e diretório de publicação dist.

Cloudflare

A Cloudflare tem duas formas de hospedar Astro, Workers e Pages. O guia do Astro para Cloudflare registra que a Cloudflare recomenda Workers para projetos novos.

Para um site estático, você cria um arquivo de configuração do Wrangler apontando os assets para ./dist e publica com astro build seguido de wrangler deploy. Também dá para ligar um repositório do GitHub ou GitLab e publicar a cada push. Para páginas sob demanda, instala o adapter @astrojs/cloudflare, que também dá acesso a recursos da plataforma, como KV e banco D1.

Pela página de preços dos Workers, existe um plano gratuito com uso limitado, e requisições a assets estáticos são gratuitas e ilimitadas. O código de servidor entra nos limites do plano.

Contexto que vale saber: em janeiro de 2026 a Cloudflare adquiriu a empresa que mantém o Astro. O anúncio afirma que o framework segue MIT e com suporte a qualquer plataforma, então isso não obriga ninguém a hospedar lá.

Encaixa bem quando você quer controle sobre a configuração, usa ou pretende usar KV, D1 e outros serviços da Cloudflare, e não se incomoda com Wrangler e linha de comando.

Netlify

Segundo o guia do Astro para Netlify, um site Astro estático não precisa de configuração extra. Você importa o repositório do GitHub, GitLab, Bitbucket ou Azure DevOps no painel, ou publica pelo netlify-cli. Para páginas sob demanda, roda npx astro add netlify, que instala o adapter.

A cada push no repositório, a Netlify faz um build novo. Isso funciona bem para times que já revisam mudanças por pull request.

A página de preços da Netlify lista um plano Free com limite de créditos; o consumo de banda, entre outros usos, desconta desses créditos.

Encaixa bem quando o projeto vive no Git, você quer prévia por branch e prefere configurar pelo painel.

Vercel

O guia do Astro para Vercel segue a mesma lógica: site estático sem adapter, páginas sob demanda com npx astro add vercel. Você importa o repositório e a Vercel detecta o Astro. Cada push gera uma prévia, e mudanças no branch principal viram produção. Também há deploy pela CLI.

Atenção ao plano gratuito: a página de preços informa que o Hobby é para uso pessoal e não comercial. Site de empresa ou de cliente pede um plano pago.

Encaixa bem quando o time já usa Vercel para outras aplicações e quer o site Astro no mesmo lugar, com prévias por pull request.

Hospedagem tradicional ou VPS

Um site Astro estático pode ir para qualquer hospedagem que sirva arquivos, inclusive a compartilhada com cPanel. Você roda o build na sua máquina e envia o conteúdo de dist/ para a pasta pública, como public_html, por gerenciador de arquivos, FTP ou SFTP.

Funciona, mas tudo fica com você: rodar o build a cada mudança, não esquecer arquivos no upload, limpar arquivos antigos que não existem mais no build e conferir o HTTPS.

Para páginas sob demanda, o caminho é o adapter @astrojs/node, que gera um servidor Node. Aí você precisa de um ambiente que mantenha esse processo rodando, como uma VPS com gerenciador de processos e proxy reverso. Nem toda hospedagem compartilhada oferece isso.

Encaixa bem quando o cliente já paga a hospedagem e quer manter tudo nela, ou quando você precisa de controle total do servidor e tem quem cuide dele.

Site no Ar

O Site no Ar é o destino de publicação para sites criados por agentes de IA. No tipo Landing Page, o site é um projeto Astro com o adapter @astrojs/cloudflare e saída estática: as páginas são pré-renderizadas, e uma página marcada com export const prerender = false é renderizada sob demanda, podendo ler variáveis, segredos, banco de dados e KV.

A diferença está em quem opera o processo. A sua IA, como Claude, ChatGPT, Codex ou Cursor, conectada pelo MCP, edita os arquivos. O Site no Ar roda bun run build a cada publicação, publica, guarda cada versão e devolve o link na conversa. Você não configura servidor, comando de build, diretório de saída nem certificado.

Se o build falhar, a publicação fica com status de falha, o erro diz o que corrigir e a versão anterior continua no ar. Para mudar algo, você pede à IA, ela publica de novo e o endereço continua o mesmo. Para começar com um site pronto, os templates Astro já vêm publicados com conteúdo de exemplo.

Todos os planos são pagos e sem fidelidade. O Básico custa R$ 10/mês, com 5 sites e 1 domínio próprio. Pro e Diamante incluem mais sites e domínios, métricas de visitas e Aplicações Web. Os valores atuais estão em Preços.

Encaixa bem quando quem cria e atualiza o site é a IA, e você quer o link no ar sem montar um pipeline. Se o seu fluxo é um repositório Git com revisão por pull request e CI do time, as plataformas acima conversam melhor com essa rotina.

Comparação lado a lado

Opção Site estático Sob demanda Como você publica Melhor para
Cloudflare Workers Sim, sem adapter Com @astrojs/cloudflare Wrangler ou integração com Git Quem quer controle e serviços da Cloudflare
Netlify Sim, sem configuração Com adapter da Netlify Git no painel ou netlify-cli Times com fluxo Git e prévias por branch
Vercel Sim, sem adapter Com adapter da Vercel Git no painel ou CLI Times que já usam Vercel em outras aplicações
Hospedagem tradicional Sim, upload de dist/ Só se o plano rodar Node Gerenciador de arquivos, FTP, SFTP Quem já tem plano e quer manter tudo nele
VPS Sim Com @astrojs/node e processo SSH, scripts próprios Quem precisa de controle total do servidor
Site no Ar Sim Páginas com prerender = false A IA publica pelo MCP Sites criados e atualizados por IA

Domínio próprio e HTTPS

Todas as opções acima aceitam domínio próprio. O trabalho muda pouco de uma para outra: você adiciona o domínio na plataforma, cria os registros DNS que ela indica no provedor do domínio e espera a verificação e o certificado.

No Site no Ar, o site começa em seu-endereco.sitenoar.app, que continua funcionando mesmo depois de ligar um domínio seu. Você ou a IA adicionam o domínio, o painel mostra os registros exatos (CNAME para subdomínios como www, A e AAAA para o domínio raiz) e o certificado HTTPS é emitido automaticamente. Se o DNS do domínio estiver na Cloudflare, dá para criar os registros com Configurar automaticamente. Detalhes em Domínios próprios.

Duas observações valem para qualquer plataforma:

  • seudominio.com.br e www.seudominio.com.br são endereços diferentes. Ligue os dois e escolha um principal para o outro redirecionar.
  • Mudanças de DNS podem levar de minutos a horas para se espalhar. Publique e revise o site no endereço padrão antes de mexer no domínio, para não confundir um problema de conteúdo com um problema de DNS.

Como decidir

Responda na ordem:

  1. O site precisa de páginas sob demanda? Se não, qualquer opção serve, inclusive hospedagem compartilhada. Se sim, descarte a compartilhada e escolha uma plataforma com adapter.
  2. Quem vai atualizar o site? Um time com Git e revisão de código tende a preferir Cloudflare, Netlify ou Vercel. Se as mudanças chegam por conversa com uma IA, o Site no Ar elimina a etapa de build e upload.
  3. O uso é comercial? Confira as condições do plano gratuito de cada plataforma antes de publicar o site de um cliente.
  4. Onde já estão o domínio e o resto da operação? Manter e-mail, DNS e outros serviços num lugar conhecido também conta.

Se a resposta for “a IA cria e atualiza”, o próximo passo é criar o site Astro com IA e publicá-lo direto da conversa.