Cloudflare na frente do cluster auto-hospedado: vale a pena em 2026?

A pergunta volta toda semana num grupo de DevOps brasileiro: "subi meu cluster com três servidores na DigitalOcean, vale botar Cloudflare na frente?". A resposta curta é "quase sempre sim" — mas o "quase" carrega trade-offs que ninguém menciona até a primeira vez que algo quebra em produção e você passa duas horas debugando uma regra de cache que mascarou um 500 do app. Este post é a versão longa, com critérios mensuráveis, da decisão que você precisa tomar antes de mover o nameserver.

TL;DR — o resumo de 200 palavras

Cloudflare grátis virou padrão de fato pra qualquer site brasileiro com tráfego: protege contra DDoS sem limite contratual, emite certificado SSL automático, cacha assets em mais de 300 cidades, esconde o IP de origem do servidor e ainda entrega DNS com sub-10ms. Pra cluster auto-hospedado — seja HeroCtl, Coolify, k3s ou Docker Swarm — pôr Cloudflare na frente é decisão fácil em cerca de 90% dos casos.

Os 10% restantes têm trade-offs concretos: latência adicional de 10 a 30ms em rotas dinâmicas, TLS termina em Cloudflare por padrão (não é mais ponta-a-ponta até o seu servidor), regras de cache podem mascarar bugs sutis no app, e o lock-in cresce conforme você adota Workers, R2 e Pages.

Vale a pena quando: você quer DDoS protection sem pagar; cache global pra reduzir custo de banda; esconder o IP do servidor de scanners. Não vale quando: compliance financeiro/saúde exige TLS verdadeiramente ponta-a-ponta; você precisa de p99 abaixo de 50ms em rotas dinâmicas; o cluster já tem CDN edge interna em múltiplos data centers. Cluster com roteador integrado já cobre cerca de 60% do que Cloudflare oferece — combinar os dois é o caminho mais comum.

O que Cloudflare oferece grátis em 2026?

A oferta gratuita aumentou de tamanho ano a ano. Hoje, o plano grátis cobre o que era plano pago de 2019:

• DDoS protection sem limite contratual — Layer 3, 4 e 7. Cloudflare absorve ataques de centenas de Gbps sem cobrar excedente.
• Certificado SSL/TLS automático — emitido em minutos pelo próprio Cloudflare, renovado automaticamente. Wildcard requer plano Advanced Certificate Manager (US$ 10/mês).
• CDN global — mais de 300 cidades em mais de 120 países. Inclui São Paulo, Rio, Fortaleza, Curitiba e Porto Alegre.
• DNS authoritative — sub-10ms global médio, anycast, com APIs para automação.
• Bot protection básica — bloqueio de bots conhecidos e desafios JavaScript em tráfego suspeito.
• Cache de assets estáticos — extensões reconhecidas (CSS, JS, imagens, fontes) cacheadas por padrão.
• Page Rules — três regras grátis para forçar HTTPS, cache extra, redirects.
• Always Online — quando a origem cai, Cloudflare serve a última versão cacheada.
• Web Analytics — métricas de RUM (visitas, países, navegadores), sem cookies.

A linha de corte é generosa o suficiente pra que um site de 10 mil visitantes/dia rode 100% no grátis sem nenhum problema operacional.

E o que Cloudflare cobra extra?

Quatro planos: Free, Pro (US$ 25/mês por domínio), Business (US$ 250/mês por domínio) e Enterprise (sob consulta, em geral acima de US$ 5 mil/mês).

Workers e R2 têm tier gratuito independente do plano: 100 mil requisições/dia para Workers, 10 GB de armazenamento e 1 milhão de operações Class A/mês para R2. Para um site marketing modesto, dá pra rodar storage de imagens no R2 sem nunca chegar à fatura.

Cloudflare adiciona latência?

A pergunta honesta. Resposta também honesta: depende da rota.

Para rotas com cache (HTML estático, assets, imagens otimizadas), Cloudflare reduz latência. O usuário em Recife pega o conteúdo do POP de Fortaleza ou São Paulo em 15 a 40ms, em vez de fazer round-trip até seu servidor em New Jersey ou Frankfurt. Economia típica: 150 a 250ms por request.

Para rotas dinâmicas (API, dashboard logado, checkout), o tráfego passa pelo proxy do Cloudflare antes de chegar ao seu servidor. Isso adiciona entre 10 e 30ms em condições normais. O número exato depende de qual POP o usuário está conectado e onde está o servidor de origem.

Mensuramos no cluster público em produção: a média de tempo de resposta do manage.heroctl.com/v1/nodes é de 38ms sem proxy Cloudflare e 51ms com proxy ativado, requisitando do mesmo notebook em São Paulo. Um delta de 13ms — perceptível em benchmark, invisível para humano.

A latência só é dealbreaker em três cenários reais: jogos online, leilão financeiro de alta frequência, e cargas WebSocket de baixa latência (trading, colaboração ao vivo). Pro resto, os 13ms somem no tempo de render do navegador.

Cloudflare quebra TLS ponta-a-ponta?

Por padrão, sim. Veja os modos:

• Flexible (NUNCA use isso) — TLS só entre cliente e Cloudflare. Conexão Cloudflare → servidor é HTTP puro. Vulnerável a interceptação na perna interna.
• Full — TLS entre cliente e Cloudflare, e separadamente entre Cloudflare e servidor. Mas Cloudflare aceita certificado inválido/auto-assinado no servidor. Risco de man-in-the-middle entre Cloudflare e a origem.
• Full (strict) — TLS em ambas as pernas, e Cloudflare exige certificado válido na origem. Esta é a configuração mínima razoável.
• Strict (SSL-Only Origin Pull) — Cloudflare verifica que o certificado da origem foi emitido por uma CA pública e válida pro hostname. Mais seguro que Full strict.

Em todos esses modos, Cloudflare descriptografa o tráfego no meio do caminho. Eles veem corpo de request, headers, cookies — tudo. Para a maioria dos casos isso é aceitável (o contrato com Cloudflare é claro), mas em compliance estrito (saúde, financeiro, governo) pode quebrar requisito de auditoria.

A saída real para ponta-a-ponta:

• Authenticated Origin Pulls — Cloudflare apresenta um certificado cliente quando conecta na sua origem; o servidor só aceita conexões dessa cadeia. Continua descriptografando no meio, mas pelo menos só Cloudflare consegue chegar na sua origem.
• Cloudflare Tunnel + cliente mTLS na ponta — para apps internas, Tunnel substitui IP público e exige certificado de cliente.
• Gray cloud (DNS only) — desativa o proxy. Você perde DDoS protection, cache, WAF — mas ganha conexão direta cliente-servidor com TLS verdadeiramente ponta-a-ponta. É uma opção válida quando compliance manda.

Vou ficar lock-in com Cloudflare?

Depende exclusivamente de quais features você adota. Vamos por camada:

• DNS — trivialmente reversível. Mover nameserver leva 24 a 48h de propagação e nada quebra. Lock-in zero.
• Proxy + cache + WAF — reversível em horas. Você desativa o orange cloud, ajusta DNS para apontar direto pro servidor, reconfigura WAF na sua origem (se houver). Lock-in baixo.
• Workers — lock-in real. A API de Workers é proprietária; reescrever pra Lambda@Edge ou Fastly Compute@Edge custa de dias a semanas dependendo do código. Não é o pior caso, mas conte com retrabalho.
• R2 Object Storage — API compatível com S3, então código continua funcionando. Mas R2 não cobra egress (S3 cobra US$ 0,09/GB), então mover pra outro provedor encarece a conta. Lock-in econômico, não técnico.
• Pages — lock-in moderado. Build process é custom; rewrite pra Vercel/Netlify/static host genérico leva uma tarde, mas exige.
• Zero Trust — lock-in alto. Políticas, identidade, túneis: rewrite completo pra Tailscale/Twingate/equivalente.

A recomendação operacional é: use o core Cloudflare (DNS + proxy + WAF + Page Rules) sem hesitar — você pode reverter num dia. Adote Workers/R2/Pages só com consciência clara de que está aceitando lock-in proporcional ao valor que aquela feature entrega.

Configuração mínima recomendada para cluster auto-hospedado

Sequência prática, sem segredo:

1. Crie conta no Cloudflare e adicione o domínio. O site vai escanear seus DNS records atuais e copiar para a nova zona.
2. Mude os nameservers no registrar (Hostinger, Registro.br, GoDaddy, onde quer que esteja). Espera de 4 a 48 horas pela propagação. Verifique com dig NS heroctl.com +short.
3. DNS records do cluster: crie um registro A para o domínio raiz apontando pro IP do servidor que recebe tráfego, e um registro A wildcard * apontando pro mesmo IP. Marque ambos com proxy ativado (orange cloud).
4. SSL/TLS mode: configure Full (strict). Isso exige que o cluster tenha um certificado válido. O roteador integrado do HeroCtl emite Let's Encrypt automaticamente — funciona out-of-the-box.
5. Always Use HTTPS: ON. Redireciona qualquer HTTP para HTTPS na borda.
6. HSTS: 6 meses, include subdomains, no preload por enquanto. Preload é decisão definitiva — não dá pra desfazer rápido se algo quebrar.
7. Page Rule de cache para assets estáticos: *heroctl.com/static/* → Cache Level: Cache Everything, Edge Cache TTL: 1 mês.
8. WAF managed ruleset (Pro+): ative o Cloudflare Managed Ruleset e o OWASP Core Rule Set em modo Block para regras de score alto.
9. Security Level: Medium. Low deixa passar bot demais; High desafia gente legítima.
10. Bot Fight Mode: ON no plano grátis. Controla scrapers básicos sem pedir CAPTCHA pro humano.

Depois de aplicar tudo isso, rode curl -I https://seudominio.com e confirme: header cf-ray presente, header server: cloudflare, header strict-transport-security com max-age longo.

Quando NÃO vale Cloudflare?

Quatro cenários onde a recomendação muda. Importam mais que parecem.

Cluster com CDN/edge interna robusta. Se você já roda em quatro ou cinco regiões geograficamente espalhadas, com balanceamento DNS por proximidade e cache local em cada região, a CDN do Cloudflare adiciona latência sem ganho. Vale rodar gray cloud (só DNS) e manter o resto direto.

Compliance financeiro ou de saúde com mTLS ponta-a-ponta obrigatório. A LGPD por si só não exige isso; mas auditorias específicas (PCI-DSS Level 1 com requisitos custom, certificações HIPAA estritas, frameworks bancários) podem exigir que tráfego cifrado nunca seja descriptografado em terceiro. Como Cloudflare descriptografa no meio do caminho, não passa.

Apps puramente internas (intranet/SaaS B2B fechado). Cloudflare Free não cobre Zero Trust avançado. Pra app que serve exclusivamente funcionários, Tailscale ou WireGuard nativo entregam mais com menos.

Sites pequenos sem tráfego e sem inimigo público. Blog pessoal de 200 visitas/mês, sem formulário de pagamento, sem dados sensíveis. DNS direto na Hostinger/Registro.br + Let's Encrypt do roteador integrado serve perfeitamente. Adicionar Cloudflare é cerimônia desnecessária.

Como Cloudflare interage com cluster de alta disponibilidade?

Aqui o desenho importa. Cluster com três ou mais nós serve tráfego em todos eles — não tem nó "principal" único. A configuração pragmática é:

• DNS round-robin com saúde: registre A records pro IP de todos os nós que rodam o roteador. Cloudflare faz health check (Pro+) e remove nó quebrado da rotação automaticamente.
• Failover de Cloudflare: ~30 segundos pra detectar nó morto e tirar da rotação (configurável até 5 segundos no Enterprise).
• Failover interno do cluster: o roteador integrado do HeroCtl reroteia tráfego entre nós saudáveis em cerca de 5 segundos. Eleição de novo coordenador acontece em ~7 segundos quando o nó-líder cai.

Combinado, downtime real percebido pelo usuário fica abaixo de 40 segundos no pior caso (Cloudflare detecta + cluster reage). Sem Cloudflare, fica em ~7 segundos (cluster sozinho). Com Cloudflare e configuração de monitoramento agressiva (Pro+), volta pra ~10 segundos. A escolha é clara: se você não precisa de DDoS protection, o cluster sozinho já é mais rápido. Se precisa, Cloudflare adiciona 30s de detecção em troca de proteção contra ataque.

Tabela comparativa: 12 critérios de decisão

A linha que decide pra maioria é "DDoS Layer 7 + esconde IP". Esses dois sozinhos justificam o plano grátis. As linhas pagas só fazem sentido com tráfego volumoso ou requisito formal de WAF.

Cloudflare grátis tem limite de tráfego?

Não há limite contratual de banda no plano grátis para tráfego web normal através do proxy. Mas existem três limites práticos que valem mencionar:

• Section 2.8 dos Terms of Service: o plano grátis é para sites cujo conteúdo principal é HTML, e Cloudflare reserva o direito de pedir upgrade se você usa o serviço primariamente para servir vídeo ou arquivos grandes. Na prática, raramente acionam — mas se você vira um host de vídeos pirateados de 50TB/mês, espera receber e-mail.
• Workers grátis: 100 mil requisições/dia. Acima disso, Workers Paid (US$ 5/mês) com 10M requisições incluídas.
• R2 grátis: 10GB de armazenamento, 1M Class A operations/mês, 10M Class B operations/mês. Acima, US$ 0,015/GB-mês.

Posso usar Cloudflare DNS sem o proxy?

Sim — modo "DNS only" (gray cloud). Você usa o DNS do Cloudflare (rápido, free, anycast global) mas tráfego vai direto pro seu servidor sem passar pelo proxy. Perde DDoS, cache, WAF, IP hiding — mantém só a infraestrutura DNS. Útil quando: compliance proíbe descriptografia em terceiro; você só quer DNS rápido sem mexer no path do tráfego; você está testando antes de ativar o proxy.

WAF grátis bloqueia SQL injection?

Cloudflare Free tem Bot Fight Mode e regras automáticas de mitigação para padrões óbvios, mas não tem o Managed Ruleset OWASP completo. Para bloqueio confiável de SQL injection, XSS, RCE patterns conhecidos, você precisa do plano Pro ou superior. Alternativa: rodar ModSecurity ou WAF próprio na sua origem — funciona, mas adiciona CPU e configuração.

Cloudflare tem datacenter no Brasil?

Sim. Em 2026 são cinco POPs brasileiros: São Paulo (dois POPs), Rio de Janeiro, Fortaleza, Curitiba e Porto Alegre. Latência típica de qualquer cidade do Sudeste para um POP fica abaixo de 20ms. O POP de Fortaleza atende muito bem o Nordeste por causa dos cabos submarinos que aterrissam ali (EllaLink, Monet, GlobeNet). Para o Norte, ainda é caminho mais longo — Manaus chega a Fortaleza em 80 a 120ms.

Como migrar nameservers da Hostinger pra Cloudflare?

Quatro passos. Demora menos de uma hora ativa, mais até 48h de propagação:

1. Cloudflare: adicione o domínio. O wizard escaneia seus DNS atuais e cria os records correspondentes na nova zona. Confira que copiou tudo — MX, TXT (SPF/DKIM/DMARC), CNAME, A. Erros de cópia aqui causam e-mail derrubado por uma semana.
2. Cloudflare: ele te dá dois nameservers (algo como kim.ns.cloudflare.com e walt.ns.cloudflare.com). Anote.
3. Hostinger: painel → Domínios → seu domínio → Nameservers → "Use custom nameservers" → cole os dois do Cloudflare. Salve.
4. Aguarde propagação. Verifique com dig NS seudominio.com +short. Quando aparecerem os nameservers do Cloudflare, o domínio está sob gestão deles. Records DNS continuam sendo editados no painel do Cloudflare daí pra frente.

Importante: enquanto a propagação acontece, parte dos usuários ainda resolve via Hostinger. Não desligue a zona velha até confirmar que 100% dos resolvers já trocaram (24 a 48 horas é seguro).

TLS termina onde? E2E quebra?

Em modo proxy (orange cloud), TLS termina em Cloudflare. Eles re-estabelecem outra conexão TLS pro seu servidor (em modo Full strict). Tecnicamente: descriptografa, processa, recriptografa. Para ponta-a-ponta verdadeiro: gray cloud (DNS only) ou Cloudflare Tunnel com configuração custom. Para a maioria das aplicações, "TLS verdadeiramente ponta-a-ponta" é menos importante do que parece — o ataque que isso protege (interceptação no meio da rede) requer atacante já dentro da rede do Cloudflare, cenário pouco realista.

Cloudflare Workers vs serverless do meu cloud — quando vale?

Workers são bons para: edge computing onde latência <50ms importa (geo-routing, A/B testing, rewrite de header); transformação leve de request/response; auth na borda (validar JWT antes de chegar na origem). Não são bons para: workload com mais de 30 segundos de runtime; integração heavy com bancos relacionais (latência de cold start de DB driver mata); código que precisa de bibliotecas que dependem de filesystem ou processo. Lambda da AWS continua melhor pra workload de runtime longo; Workers ganham na borda. Use ambos, não substitua um pelo outro.

Posso usar Cloudflare R2 com cluster auto-hospedado?

Sim — R2 é S3-compatível na API. Seu app usa aws-sdk configurado com endpoint de R2 e credenciais R2; código continua igual. Vantagem econômica: zero egress fee. Você pode servir downloads pesados (instaladores, vídeos de produto, backups) direto do R2 sem pagar por banda saindo. Desvantagem: durabilidade documentada é 99.999999999% (11 noves), mesma do S3, mas histórico operacional do R2 é mais curto. Para hot path crítico, alguns times preferem manter S3 e usar R2 só para cold storage e static delivery.

Origem caiu — Always Online resolve?

Em parte. Always Online serve a última versão cacheada de páginas HTML quando o servidor está fora. Mas: só funciona pra rotas que estavam sendo cacheadas; só serve a versão estática (sem dados dinâmicos atualizados); só dura enquanto Cloudflare mantém o snapshot (geralmente alguns dias). É uma rede de segurança boa pra blog estático e marketing. Não substitui alta disponibilidade real do cluster — pra app dinâmico, o que resolve é o cluster ter três nós e eleição automática quando um cai.

Fechando — combinando Cloudflare com cluster auto-hospedado

A combinação que recomendamos para 90% dos casos é: cluster auto-hospedado com três ou mais nós (alta disponibilidade real) + Cloudflare Free na borda (DDoS, cache, IP hiding). O cluster cuida de roteamento interno, certificados automáticos, failover entre nós em segundos. Cloudflare cuida de proteção pública, cache global e ofuscação de IP. As duas camadas se complementam — não competem.

Para começar do zero com essa combinação:

curl -sSL get.heroctl.com/install.sh | sh

Você fica com cluster funcional em três nós, certificado Let's Encrypt automático no domínio que escolher, painel web pra submeter jobs, alta disponibilidade real. Depois, adiciona Cloudflare Free na frente do domínio e configura conforme a seção "Configuração mínima" deste post. Total de tempo: uma tarde.

Mais leitura nesta linha:

• Deploy Docker em produção: do compose ao cluster — como sair do docker compose up e chegar em alta disponibilidade real, com os passos intermediários.
• Observabilidade sem Datadog: stack para startup — métricas, logs e tracing sem pagar US$ 2.000/mês de SaaS de observabilidade.

Cloudflare é uma das poucas ferramentas onde o tier grátis é tão bom que recusar é teimosia. Mas como toda escolha de infra, a parte difícil é entender exatamente onde a fronteira está — e, principalmente, onde ela passa por dentro do tráfego cifrado da sua aplicação.