☁️ Publicar pelo Cloudflare

Quando o site vira coisa séria: fechar o código, conferir antes de publicar, ou ganhar dinheiro com ele.

Pra quem é esta página: você tem um site feito de arquivos (HTML, CSS, imagens) guardado num repositório do GitHub e quer ele no ar, num endereço público — sem pagar hospedagem, sem precisar abrir o código pro mundo, e sem restrição sobre o que o site pode ser.

Você liga o Cloudflare no seu repositório uma vez. A partir daí, o seu dia a dia é só continuar trabalhando: você muda, envia pro GitHub, e o site se atualiza sozinho em cerca de um minuto. Nunca mais você publica nada na mão. Reserve uns 10 minutos pra fazer isso uma vez.

🛡️ Quem é a Cloudflare, afinal

provavelmente você já esbarrou nela hoje

Sabe aquela tela de "verificando se você é humano" que aparece por um segundo antes de um site abrir? Na maioria das vezes é a Cloudflare. Ela funciona como uma portaria na frente dos sites: filtra ataque e tráfego falso, e entrega o conteúdo pela máquina mais perto de quem está acessando.

Não é uma empresa pequena: pelos números dela, 1 em cada 5 sites da internet passa por lá, com máquinas em 337 cidades, em mais de 100 países — 95% da população conectada do mundo está a menos de 50 milésimos de segundo de uma delas. Ou seja: a mesma estrutura que fica na frente de meio mundo pode servir a sua página, de graça.

🎯 O que você ganha aqui

os três motivos que fazem alguém escolher este caminho

🔒O código pode ficar fechado. Seu repositório continua privado, só seu, e o site vai pro ar do mesmo jeito. Isso não custa nada — e nem todo serviço grátis oferece.
💼O site pode ser um negócio. Loja, serviço pago, a vitrine de um trabalho que fatura: sem restrição sobre o que você publica. ⚠️ Vale saber que isso não é padrão: há serviços grátis que proíbem uso comercial nas regras, mesmo funcionando tecnicamente. O exemplo mais comum é o GitHub Pages, que na documentação dele não permite hospedar um negócio ou loja de graça. Leia o que você aceitou antes de montar um negócio em cima.
👀Dá pra ver uma prévia antes de publicar. Trabalhando numa versão de teste, o Cloudflare a publica num endereço separado, só pra você conferir, sem tocar no site de verdade. Serve pra qualquer um que já publicou algo torto e queria ter visto antes.

⛔ Onde ele não serve: projeto com WordPress, PHP ou banco de dados. O Cloudflare não roda nada disso — aqui é pra site feito de arquivos. E se você quer só o mais simples possível, com o código aberto mesmo, publicar direto pelo GitHub tem menos passos que isto aqui.

🚀 Como fazer

três passos, uma vez só

Criar a conta no Cloudflare

grátis, sem cartão; uma vez na vida

É mais uma conta pra você ter — e é o principal custo de escolher este caminho. O plano grátis serve de sobra pra um site de arquivos.

1Vá em dash.cloudflare.com/sign-up e crie a conta com e-mail e senha.
2Confirme o e-mail. Não precisa cadastrar cartão nem comprar domínio pra seguir.

✅ Você deve ter: o painel do Cloudflare aberto, logado.

Importar o seu repositório no Cloudflare

é aqui que o deploy automático nasce

Este passo é de mouse, no painel do Cloudflare — e é o último assim: depois dele, tudo volta a ser conversando. A IA não conduz aqui porque aqui você autoriza o Cloudflare a acessar seus repositórios, e autorização se dá no navegador, logado como você. São poucos cliques; o único que pede atenção é o item 4, onde o GitHub pergunta o que você libera.

1Na barra lateral esquerda do painel, procure o grupo Build e clique em Compute; abaixo dele aparece Workers & Pages — clique nesse. (Atalho: a busca no topo da página, ou Ctrl + K, achando por "Workers".)

O caminho até Workers & Pages na barra lateral. ⚠️ O painel do Cloudflare muda de tempos em tempos — se a sua tela estiver diferente desta, use a busca.
2Clique no botão Create application.
3Escolha importar um repositório (o botão aparece como "Import a repository" ou "Continue with GitHub", dependendo da versão do painel).
4Clique em adicionar conta do GitHub ("Add account") e depois em Install & Authorize. Quando o GitHub perguntar quais repositórios você libera, o mais simples é deixar em All repositories (todos): assim qualquer projeto que você criar depois já aparece aqui, sem configurar de novo. Dá pra ser mais restritivo — veja "O caminho mais cuidadoso", no fim deste passo.
5De volta ao Cloudflare, escolha o repositório na lista e clique em Next.
6Na tela de configuração, o nome do projeto já vem preenchido com o nome do repositório — é ele que vai virar o começo do seu endereço, e dá pra trocar aqui se quiser. No resto, deixe tudo como está e clique em Deploy (ou "Save and Deploy"). Como seu site é feito de arquivos prontos, não há nada pra "construir".

✅ Sinal de que deu certo: em menos de um minuto o Cloudflare abre a página do seu projeto, com um botão azul Visit no canto superior direito. Clique nele: é o seu site no ar. O endereço também aparece como link no topo da página, algo como meu-site.seu-apelido.workers.dev — não precisa digitar nem decorar nada.

⚠️ Se o deploy falhar dizendo que não conseguiu "buildar": volte nas configurações e coloque exit 0 no campo Build command, e no Build output directory a pasta onde estão seus arquivos (normalmente a raiz, um ponto: .). Isso diz "não tem nada pra construir, só publique os arquivos".

💡 De onde saem as duas partes do endereço

O endereço é montado assim: nome-do-projeto.apelido-da-sua-conta.workers.dev.

A primeira parte é o nome que apareceu na tela de configuração (item 6), copiado do nome do seu repositório. Se o repositório se chama meu-site, o endereço começa com meu-site.

A segunda parte é um apelido da sua conta no Cloudflare, criado quando você publica o primeiro projeto. ⚠️ Ele não tem relação com o seu usuário do GitHub — costuma sair do e-mail que você usou pra se cadastrar. Vale pra todos os seus projetos, e dá pra trocar depois em Workers & Pages, na opção Change ao lado de "Your subdomain".

Perdeu o endereço? Ele nunca some: abra Workers & Pages, clique no seu projeto e ele está no topo, no botão Visit e no quadro Domains and routes. Na aba Domains do projeto ele aparece por extenso, marcado como Production.

💡 O caminho mais cuidadoso: liberar só o repositório deste projeto

Deixar em "All repositories" não deixa nada público — seus repositórios seguem privados do mesmo jeito. O que muda é outra coisa: o Cloudflare passa a enxergar tudo que você tem hoje e tudo que você criar no futuro. Se um dia essa conexão for comprometida, o estrago é do tamanho do que você liberou. É a lógica de não dar a chave da casa inteira pra quem só precisa entrar na garagem.

Como fazer o restritivo: naquela mesma tela do GitHub, escolha Only select repositories e marque só o repositório deste site. É o que a própria Cloudflare recomenda na documentação dela.

⚠️ Mas saiba o preço, porque ele aparece só lá na frente: ao criar um segundo projeto, o repositório novo não vai aparecer na lista do Cloudflare — e nada na tela explica por quê. Pra liberar, vá em github.com/settings/installations, encontre Cloudflare Workers and Pages, clique em Configure e adicione o repositório. É rápido, desde que você lembre que é isso.

💡 Workers ou Pages? A tela oferece os dois — e a diferença importa

Dentro de Create application existem dois produtos parecidos: Workers (o endereço termina em .workers.dev) e Pages (termina em .pages.dev). Pra publicar um site de arquivos, os dois funcionam.

A diferença que importa pra você é pra onde a empresa está indo: a Cloudflare declara que todo o investimento e as features novas vão para o Workers daqui pra frente. O Pages continua funcionando e não foi desligado, mas é o caminho antigo.

Recomendação: use o Workers (a opção de importar repositório). Se você já criou um projeto no Pages, não precisa correr pra migrar.

Testar o ciclo: mudar e ver publicar sozinho

a recompensa — e o seu dia a dia daqui pra frente

A partir daqui não muda nada no seu jeito de trabalhar. Peça uma mudança e mande pro GitHub numa frase só:

Prompt · mudar e publicar de uma vez

Muda o título da página pra "Meu site no Cloudflare", salva um ponto no histórico e envia pro GitHub.

Segundos depois de subir, o Cloudflare percebe sozinho e republica o site. Volte no endereço, atualize a página, e a mudança está lá. Você não publicou nada na mão — e nem abriu o painel do Cloudflare de novo.

✅ O extra que você ganhou: quando quiser testar algo arriscado sem mexer no site que está no ar, peça pra IA trabalhar numa versão paralela. O Cloudflare publica essa versão num endereço separado — o seu endereço normal com um prefixo na frente, marcado como Preview na aba Domains do projeto. O site de verdade continua intocado até você aprovar.

📚 Pra entender melhor

leitura, não passo a passo

⚖️ Cloudflare, GitHub Pages e Hostinger

os três publicam a partir do GitHub, com atualização automática — a escolha é sobre o que você está publicando

	GitHub Pages	Cloudflare	Hostinger
Custo	Grátis	Grátis	Pago
Fim comercial	Não permitido	Pode	Pode
Código fechado	Só pagando	Pode, de graça	Pode
Prévia antes de publicar	Não	Sim	Só nos planos maiores
Site em WordPress	Não	Não	Sim

Em uma frase cada. O GitHub Pages é o mais simples: sem conta nova, a IA liga conversando. O Cloudflare entra quando você bate num dos três motivos acima. O Hostinger é outra categoria — você paga por um servidor de verdade, com WordPress, PHP, banco e e-mail: indispensável se for isso que você precisa, desperdício se o site é feito de arquivos. Velocidade não decide nada aqui: os três são rápidos de sobra pra um site pessoal.

💡 Por que o "não permitido" do GitHub Pages é o item mais sério da tabela

Todos os outros itens são capacidade: faz ou não faz. Esse é regra. A documentação do GitHub diz que o Pages "não é destinado nem permitido" como hospedagem grátis pra rodar um negócio, uma loja ou um serviço pago. Ele funciona, ninguém vai te pegar — e é justamente isso que o torna traiçoeiro.

Não é sobre tamanho nem sobre fiscalização: é sobre em que terreno você constrói. Um site que ganha importância na sua vida não deveria morar num lugar cujas regras dizem que ele não devia estar ali — no dia em que ele crescer, você muda de casa às pressas, justamente quando menos pode ficar fora do ar.

Os limites de uso do Pages seguem a mesma lógica e são bem folgados: 100 GB de tráfego por mês e 1 GB de site, ambos "soft" (nada é desligado automaticamente, o GitHub conversa antes). Site pessoal não chega perto disso — o problema nunca foi o tamanho.

De onde saiu cada afirmação (verificado em 30/07/2026):

Conectar repositório e publicar a cada envio: developers.cloudflare.com · Builds e GitHub integration. Formato do endereço (<nome-do-worker>.<subdomínio-da-conta>.workers.dev) e como trocar o subdomínio: workers.dev.
Site estático sem framework: build command em branco ou exit 0: developers.cloudflare.com · Static HTML.
Plano grátis: 100.000 requisições/dia, requisições a arquivos estáticos gratuitas (pricing); 3.000 minutos de build/mês (limits & pricing).
Investimento concentrado no Workers em vez do Pages: migrate from Pages to Workers.
Rede: "Cloudflare powers 1 in 5 sites on the Internet", 337 cidades e 95% da população conectada a menos de 50 ms: cloudflare.com/network.
GitHub Pages grátis publica só de repositório público: docs.github.com · products.
Uso comercial não permitido no GitHub Pages ("is not intended for or allowed to be used as a free web-hosting service to run your online business, e-commerce site…"), limites soft de 100 GB/mês e 1 GB de site: docs.github.com · GitHub Pages limits.
Hostinger: deploy de repositório Git pelo hPanel, com implantação automática: Central de ajuda da Hostinger. A prévia (staging) existe, mas só nos planos Business, Cloud e WordPress Pro, e é voltada a WordPress: staging na Hostinger.

⚠️ Ressalva honesta: os nomes dos botões no painel do Cloudflare mudam com frequência — se a tela não estiver igual à descrita, procure o equivalente ("importar repositório", "conectar ao Git"). E o número de centros de dados da Hostinger vem de fontes de terceiros, não de página oficial da empresa; trate como ordem de grandeza.