Pular para o conteúdo
Infrastructure
Como publicar um site estático com HTTPS e domínio próprio

Como publicar um site estático com HTTPS e domínio próprio

Ciro Cesar Maciel6 min de leituraFeito com ajuda de IA

Nesta página · 11 seções
  1. O que é um site estático, de verdade
  2. O que o Hoster resolve
  3. Publicar pela CLI
  4. Publicar pela API HTTP
  5. Publicar por um agente
  6. Apontar um domínio próprio
  7. Quando isso não basta
  8. Perguntas frequentes
  9. Para continuar lendo
  10. Publicar sem montar a infraestrutura
  11. Fontes

Publicar um site estático é pegar a pasta gerada pelo build e colocá-la num lugar onde qualquer pessoa consegue abrir pelo navegador, com HTTPS e um endereço que você controla. Parece pouca coisa, mas é aí que muita gente trava: precisa de servidor, certificado, cache e uma forma de apontar o domínio sem quebrar o e-mail.

O que é um site estático, de verdade

Um site estático é um conjunto de arquivos prontos: HTML, CSS, JavaScript e imagens. O servidor não monta página nenhuma no momento da visita; ele apenas entrega o arquivo que já existe. Um site feito em Vite, Astro, Next com exportação estática ou um painel React compilado cai nessa categoria.

Isso significa que você não precisa de um processo rodando no servidor. Precisa de um lugar que sirva arquivos, de preferência perto de quem visita.

O que o Hoster resolve

Quando você publica, o Hoster resolve quatro coisas que normalmente dariam trabalho:

  • Subdomínio. Cada projeto é um subdomínio. meu-site responde em https://meu-site.hoster.myinfrastructure.click. O nome é o que você escolhe ao criar o projeto, e o endereço não muda nas publicações seguintes.

  • HTTPS. O certificado é emitido sem você mexer em nada. O endereço já nasce com cadeado.

  • Cache. Os arquivos são servidos pela borda da rede Cloudflare, o que reduz a ida à origem nas visitas seguintes. Você escolhe a estratégia de cache por projeto (desenvolvimento, equilibrada ou agressiva). Fora da estratégia de desenvolvimento, arquivos com hash no nome, como index-BosabLVq.js, recebem cache longo automaticamente.

  • Domínio próprio. Você aponta um domínio seu, como meusite.com, e o Hoster emite o certificado para ele também.

Além disso, cada publicação vira uma versão. As versões antigas ficam guardadas, e voltar a uma delas é uma operação só, sem republicar.

Publicar pela CLI

O caminho mais direto é a CLI. Depois de gerar o build, o comando é este:

bunx @ciromaciel/hoster-cli login hk_...
bunx @ciromaciel/hoster-cli deploy --project meu-site --dir ./dist

A chave hk_ sai do painel, em Chaves de API. O login grava a chave localmente e você não precisa repetir. Em um pipeline de CI, o padrão é passar a chave por --token, lida de um secret, sem gravar nada no disco.

As opções principais são:

OpçãoO que faz
--projectnome do projeto, que vira o subdomínio
--dirpasta de build publicada
--mainarquivo de entrada, index.html por padrão
--tokenchave de API, para CI

Para uma aplicação de página única, como uma SPA em React Router, nada precisa ser configurado. Se alguém abrir /sobre/equipe direto, o Hoster serve o arquivo de entrada e o roteador do próprio app resolve a rota.

Publicar pela API HTTP

Se você quer integrar a publicação a uma ferramenta própria, a API aceita o envio arquivo a arquivo ou um .zip inteiro. O fluxo de envio arquivo a arquivo tem três passos: criar ou atualizar o projeto, enviar cada arquivo com o mesmo identificador de versão e, por fim, confirmar a versão. Sem essa confirmação, nada do que subiu aparece no site, então o site anterior continua no ar até o último passo.

Para um .zip, o endpoint recebe o arquivo direto e publica. Só .zip é aceito como arquivo compactado; outros formatos são recusados antes de tocar no site que já está no ar.

Publicar por um agente

Se o seu fluxo de trabalho usa um agente de código, como Claude Code ou Cursor, o Hoster expõe um servidor MCP. Conectar leva uma linha, sem colar chave em arquivo de configuração:

claude mcp add --transport http hoster https://hoster.worker.myinfrastructure.click/mcp

Na primeira vez, o cliente abre o navegador para você entrar e aprovar o acesso. A partir daí, o agente pode listar projetos, trocar a estratégia de cache, apontar um domínio e verificar o status de SSL.

Para publicar, há uma divisão de tarefas que vale entender. O agente pede uma autorização ao Hoster, que devolve um comando pronto. Esse comando você roda no seu terminal, e os arquivos vão direto para o Hoster. Os bytes do site não passam pela conversa com o agente, o que mantém o contexto limpo e evita colar arquivos grandes no chat.

Apontar um domínio próprio

Depois que o projeto está no ar, você pode apontar um domínio seu. No painel, ou pela API, informe o domínio. O Hoster mostra o registro que você precisa criar no seu provedor de DNS:

tipo:   CNAME
nome:   @  (ou www)
valor:  proxy.hoster.myinfrastructure.click

A propagação costuma levar alguns minutos e pode chegar a 24 horas. Enquanto o status estiver pending, o site continua acessível pelo subdomínio do Hoster. Quando o certificado do domínio for emitido, o status vira active.

Dois cuidados práticos. Se o domínio que você quer já estiver em uso por outro projeto, o Hoster recusa. E se você usa o registro @ para um CNAME, confira se o seu provedor de DNS aceita CNAME na raiz; caso contrário, use www.

Quando isso não basta

O Hoster serve arquivos estáticos. Não roda código no servidor: não há funções serverless, renderização no servidor nem rotas de API dentro do próprio projeto. Se o seu site precisa montar a página a cada visita ou responder a formulários sem um serviço externo, ele precisa de outra peça. Também não há configuração de redirecionamentos por arquivo (como _redirects ou _headers) nem build feito no servidor: você envia o resultado pronto.

Para a maioria dos sites de apresentação, documentações, landing pages e painéis single-page, isso é suficiente, e o que sobra é o que você precisava fazer manualmente.

Perguntas frequentes

Preciso de um servidor para publicar um site estático?

Não. Um site estático não precisa de processo rodando. Basta um lugar que sirva arquivos com HTTPS, e isso é o que o Hoster faz.

Quanto tempo leva para uma mudança aparecer?

Depois de publicar, a versão nova chega à borda em até um minuto. O navegador de quem já visitou o site pode guardar uma cópia por mais tempo, dependendo da estratégia de cache escolhida. Na estratégia equilibrada, o HTML é revalidado a cada carga.

Dá para voltar a uma versão anterior?

Sim. Cada publicação fica guardada como versão, e o rollback troca a versão no ar sem precisar reenviar os arquivos.

O domínio próprio troca o endereço do Hoster?

Não. O subdomínio do Hoster continua funcionando. O domínio próprio é um endereço adicional que aponta para o mesmo projeto.

Para continuar lendo

Publicar sem montar a infraestrutura

Subir um site não deveria exigir montar servidor, certificado e cache antes da primeira visita. O Hoster deixa o caminho curto: um build, um comando ou uma chamada, e o endereço já funciona com HTTPS. Conhecer o Hoster

Fontes

XLinkedInWhatsAppE-mail

Quem escreveu

Ciro Cesar Maciel

Sou marido, pai e trabalho com tecnologia há mais de duas décadas, construindo sistemas para grandes empresas e liderando times técnicos. Desde 2024 desenvolvo ferramentas digitais e aplico Inteligência Artificial para viver e trabalhar com mais clareza, e escrevo aqui sobre isso.

Todos os textos

Continue lendo

Comentários

Seu e-mail fica com Infrastructure para moderar e responder. O comentário aparece depois de aprovado.