Seu site no ar com um comando. Sem YAML.

Sim — é o caso principal. Você sobe a pasta já buildada (dist/) e o fallback de SPA vem ligado: requisição sem extensão de arquivo cai no seu index.html, então não há 404 ao recarregar numa rota interna. Não precisa configurar regra de rewrite, não precisa descobrir nome de arquivo de config.

Pode. Aponta um CNAME para proxy.hoster.myinfrastructure.click, salva o domínio no painel e clica em verificar. O certificado é emitido pela Cloudflare for SaaS. Enquanto o CNAME não propaga, o status fica "pending" — é a propagação de DNS, não a nossa fila.

O caminho de volta é o mesmo de ida: um hoster deploy com a versão anterior, e em segundos o site está no ar de novo — sem console, sem ticket, sem esperar pipeline. O que ainda não existe é histórico automático: não guardamos versões, então a volta depende de você ter o build anterior. E como o deploy troca os arquivos no lugar, há uma janela curta — proporcional ao tamanho do site — em que um acesso pode pegar 404. Se o seu tráfego não tolera essa janela, vale esperar o deploy versionado por prefixo, que já está em desenvolvimento e resolve atomicidade e rollback de uma vez.

Você já tem o seu site: ele é a mesma pasta que você buildou, servida como arquivos estáticos por HTTP. Não há formato nosso, build proprietário nem banco prendendo nada — e se você quiser puxar o que está no ar, um "wget -r -np -k https://seu-site.myhoster.click/" traz tudo e abre no navegador local. Sendo exato: o wget é ferramenta sua, não comando nosso; um "hoster pull" oficial está no backlog. Migrar daqui é apontar o mesmo dist/ para outro lugar.

Fica. TTFB mediano de 139 ms, medido de São Paulo em 25/08/2026 com 15 amostras via curl — e 142 ms repetindo o teste com query única, para não medir cache quente. Para referência, a Vercel deu 137 ms no mesmo momento e pelo mesmo método: hoje é empate técnico. Vale dizer que nem sempre foi: em 18/08 estávamos em 532 ms, porque o worker consultava banco e storage a cada requisição sem cache de borda. Publicamos aquele número enquanto ele era ruim e publicamos este agora — os dois medidos igual, com data ao lado, para você poder conferir. Os arquivos vêm da rede da Cloudflare, com HTTPS e cache em três estratégias que você escolhe no painel.

O Hoster publica site estático e SPA — é isso que ele faz, e faz em dois comandos. Fora desse recorte: não há SSR (Next com renderização no servidor, Nuxt SSR, Remix), não rodamos funções ou API routes, não há ISR, não buildamos por você, não há preview por branch, redirects ou headers customizados além do HTTPS forçado, rollback nem logs de acesso. Preferimos essa lista publicada agora a você descobrir em três semanas — e se o seu caso está nela, a gente diz na hora e aponta o que serve.

No Cloudflare R2, servidos por Cloudflare Workers, com os metadados em D1. A região do bucket não está declarada na nossa configuração — por isso não afirmamos "origem no Brasil" em lugar nenhum desta página. Quando declararmos, publicamos aqui.

São três estratégias: development (no-cache, no-store), balanced (padrão, max-age de 1 hora) e extreme (30 dias, para assets com hash no nome). A letra miúda que preferimos dizer: o deploy não limpa o cache sozinho. Com balanced, alguém que já visitou pode ver a versão antiga por até uma hora. Há um botão de limpar cache no painel, e enquanto você itera o recomendado é development.

Ainda não: não coletamos uptime hoje, e preferimos não publicar número que não medimos. Quando a coleta existir, ela vira uma página pública com série histórica — verificável, não uma frase de marketing na landing. Enquanto isso, o canal é direto: você fala com quem escreveu o código, pelo WhatsApp, e não com uma fila de suporte.

Não precisa de cartão para fazer deploy. O que os planos limitam é o número de projetos — 3, 9 ou 99, e 1 sem plano —, e ao atingir o limite o botão de criar projeto simplesmente desabilita: site no ar continua no ar, e não há cobrança de excedente aparecendo na sua fatura. Tamanho de upload e banda não têm checagem no nosso código hoje; o teto real é o da plataforma abaixo, e dizemos isso em vez de apresentar como uma política nossa.

Dá, e é a mesma linha que você roda no terminal. Guarde a chave como secret HOSTER_TOKEN e chame o deploy com --token no workflow. Não há action própria para instalar nem plugin para configurar.

MCP (Model Context Protocol) é o padrão que deixa um agente de IA usar ferramentas externas. O nosso é um servidor remoto: você conecta com uma linha, sem chave nenhuma no comando — o cliente te manda ao navegador para autorizar — e o agente ganha catorze ferramentas — listar projetos, ler o estado de um, trocar variáveis, mexer no cache, apontar domínio, verificar SSL e apagar projeto. Na prática você para de colar a documentação no chat: o agente descobre sozinho o que existe e qual o estado atual. O endereço é https://hoster.worker.myinfrastructure.click/mcp.

Conecta. Nosso servidor implementa a revisão 2026-07-28 do MCP, que é stateless — cada requisição carrega tudo o que precisa, sem handshake e sem sessão —, e o SDK oficial já negocia essa revisão. Um cliente de era anterior que sonde o servidor recebe a lista de versões que falamos, com o código que a spec define para isso, então ele sabe exatamente com quem está falando em vez de falhar em silêncio.

A autorização resolve isso na raiz: você aprova no navegador e o token pode ser só de leitura — nesse caso as ferramentas que alteram ou apagam nem aparecem para o agente, então não é questão de ele se comportar, elas não existem naquela sessão. Valem ainda três garantias: as ferramentas destrutivas são marcadas como tal no protocolo e o cliente pede sua confirmação antes de executar; apagar projeto exige um parâmetro de confirmação explícito; e cada requisição valida a posse, então o agente nunca alcança projeto de outra conta. Se o agente só precisa consultar, autorize com escopo de leitura. A chave hk_ não entra no MCP: ela é a credencial da API REST e da CLI, e é por lá que o CI publica.