Eu cuido da infraestrutura pesada da minha empresa no Brasil e nos Estados Unidos, e o meu CDN sai com terabytes de banda por dia. Já liguei o proxy da Cloudflare na frente dele pra ver no que dava — e tomei rate limit. Aqui embaixo eu conto os dois limites que derrubam desenvolvedor sem aviso: o upload de 100 MB, que falha em silêncio, e a política de uso justo, que é pública e não tem número.
Resposta rápida: os dois limites da Cloudflare que mais derrubam gente não estão na sua documentação de arquitetura. O primeiro é o tamanho máximo de upload com o proxy ativado: 100 MB no free — e 100 MB também no Pro, 200 MB só no Business. Passou disso, o upload não acontece, e não acontece calado. A saída é multipart ou um subdomínio com a nuvenzinha desativada e SSL seu. O segundo é a política de uso justo: a Cloudflare declara que pode limitar quem serve vídeo ou proporção desproporcional de arquivos grandes pela CDN sem contratar os produtos pagos dela — e não publica número nenhum. Eu testei na prática: liguei o proxy na saída do meu CDN de terabytes por dia e todas as requisições foram pra 300, 400, 500 ms. E não adianta tentar enganar: eu peguei um dev declarando chunk .ts de vídeo como JPG — funcionava só porque ainda não tinha tráfego de verdade.
Gravei esses 14 minutos e meio no canal @josimarjmv em 2 de julho de 2026, com a experiência na mão. Assista e leia junto: aqui embaixo eu fui na documentação e nos termos da própria Cloudflare conferir os números, e teve um que eu precisei corrigir — o do plano Pro.
🎧 PREFERE OUVIR? · 15 min
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Vou dar a minha carteirada antes de falar qualquer coisa. Eu sou CEO de uma empresa de tecnologia e sou hands-on: a parte operacional de infraestrutura, no Brasil e nos Estados Unidos, quem cuida sou eu. E sabe por quê? Porque isso aqui custa muito dinheiro. Eu tenho que pagar a conta. Então eu preciso entender essa camada pra entender o meu próprio negócio: onde eu invisto, onde eu não invisto, onde vale a pena código e onde não vale.
Como assim código? Onde eu vou investir o meu código: eu me prendo na Cloudflare ou eu compro a minha infraestrutura própria? Quando você paga a conta e tem a visão técnica de como a coisa funciona, aí você vira CEO hands-on — ou CTO hands-on, que deveria ser obrigação do CTO, e tem muito por aí que não é.
Então o que vem a seguir não é palpite de fora. São limites que eu descobri usando a Cloudflare em larga escala, com a conta chegando no meu nome. Não usei todos os recursos dela, e vou falar só do que eu usei.
Essa primeira aqui já vai matar um monte de gente de raiva, porque todo desenvolvedor já passou raiva com isso e eu duvido que esteja na documentação interna da sua empresa. Se tiver, eu retiro o que eu disse — comenta lá no vídeo pra calar a minha boca.
O plano free da Cloudflare tem um limite de upload quando o proxy está habilitado. Qual é o limite? 100 MB. Pausa aqui e tenta fazer um upload maior que isso agora.
Vou explicar com mais calma, porque "via proxy" confunde. Você tem uma VM. Na VM você tem um proxy com uma URL hospedada na Cloudflare, com a nuvenzinha laranja ativada. Quando você faz upload da sua máquina, o arquivo bate no proxy da Cloudflare e volta pra sua aplicação. Quando você sobe um arquivo com mais de 100 MB, de forma silenciosa, simplesmente não sobe. E até você descobrir isso, vai gastar umas horas.
Apuração minha, feita em 28/09/2026, porque número eu não repito de ouvido — e aqui eu me corrijo. Na tabela oficial de limites da Cloudflare o tamanho máximo do corpo da requisição é assim:
Ou seja: pagar o Pro não resolve o seu problema de upload. Se você ia assinar por causa disso, guarde o dinheiro. Repara no tamanho do estrago que essa informação evita — é o tipo de coisa que decide arquitetura e que ninguém te conta antes.
E o que fazer, na prática? Pega isso aqui e manda pro seu amigo agora:
Fui reler as políticas da Cloudflare e tem lá uma política de uso justo. E ela é muito pancada, no seguinte sentido: você bota um site HTML e JavaScript lá, e praticamente eles não limitam — deixam o pau quebrar, milhões de visita, sem reclamar. Só que, lógico, aí entra a política de uso justo deles.
O que é a política de uso justo? Não tem. Não tem número. O que eles têm são ferramentas e métricas qualitativas: se eles acharem que você está usando muito, ou que tem algum tipo de abuso, podem simplesmente tirar você do ar.
Checagem minha, 28/09/2026: isso está escrito, com todas as letras, nos termos específicos da Cloudflare para a CDN dos planos free, Pro e Business — nos Service-Specific Terms:
"Cloudflare reserves the right to disable or limit your access to or use of the CDN, or to limit your End Users' access to certain of your resources through the CDN, if you use or are suspected of using the CDN without such Paid Services to serve video or a disproportionate percentage of pictures, audio files, or other large files."
Traduzindo pro nosso português de produção: se você servir vídeo ou uma proporção desproporcional de imagem, áudio e arquivo grande pela CDN sem contratar os produtos pagos, eles podem limitar o seu acesso. Repara em duas palavras: "suspected" — basta a suspeita — e "disproportionate" — sem definir proporção nenhuma. Quem mede é a casa. E os produtos pagos pros quais ela aponta, nos mesmos termos, são a plataforma de desenvolvedor, o Images e o Stream. É exatamente o que eu digo na gravação: ela quer te jogar pro plano pago, pra você hospedar lá com ela, no R2.
Não tem nada de errado nisso — o terreno é deles. O problema é você desenhar capacidade em cima de uma regra que não tem número. Isso é o mesmo raciocínio que eu detalhei quando expliquei por que eu não uso GitHub, Supabase ou Firebase em produção: o problema nunca é a ferramenta, é morar dentro dela.
Anos atrás a gente fez um teste com a Cloudflare: ativamos o proxy dela na saída do nosso CDN. O nosso CDN sai com terabytes de banda por dia. Muitos tera. Adivinha o que aconteceu?
Rate limit. Todas as requisições ficaram extremamente lentas — cada uma gastando 300, 400, 500 milissegundos. A gente foi lá, desativou a nuvenzinha na hora, e ficou tudo bem. Só ficou tudo bem porque já tinha estrutura e SSL próprios: era um teste, não uma dependência.
E por que eu testei? Porque vai que dava certo. Se desse, a gente ia ter tráfego no mundo inteiro de graça. Eu testo — eu sou hands-on. Deu errado, tudo certo. A diferença entre testar e apostar é ter pra onde voltar em cinco minutos.
Guarda o detalhe de como o rate limit se manifesta, porque é a parte cruel: não cai, fica lento. Em site, lentidão é ruim. Em streaming, onde o player pede um chunk atrás do outro sem parar, meio segundo por requisição vira travada na cara do espectador — e aí você vai procurar bug no seu encoder, no seu player, na operadora do cliente. É o mesmo tipo de armadilha que eu desenhei quando expliquei de onde vem o delay de 40 segundos de uma live: o segundo some numa camada que ninguém estava olhando.
Agora a história engraçadíssima, que é a que mais ensina. Primeiro o contexto: a gente tem uma plataforma de vídeo e faz restream de câmera IP — escola, obra, esse tipo de coisa. Você pega o sinal da câmera IP, joga na nuvem e transcodifica pra funcionar no mobile e escalar pra muita gente. O caso clássico é a escolinha: as câmeras da escola viram link em formato web aberto, o cliente põe no site e no aplicativo dele, e os pais assistem do iPhone ou do Android.
Tinha um cliente nosso de câmera IP, de uns cinco, seis anos de casa, sempre excelente. Um dia ele mandou mensagem querendo reunião comigo, com um tom meio arrogante com os meninos do suporte, dizendo que ia cancelar o plano. Eu estava viajando. Quando voltei, falei: marca, eu sempre atendo cliente. Antes, pedi o de sempre: manda a pauta. Não dá pra entrar em reunião sem saber do que se trata.
A pauta veio: ele estava saindo da nossa empresa porque achava caro e ia montar a operação própria pras câmeras dele — e queria me oferecer uma parceria, me vender por metade do preço pra eu revender. Achei curioso, porque eu tenho estrutura própria e nem cobro tráfego. O cara dizendo que o meu plano é caro e que ia fazer mais barato com a conta na nuvem.
Beleza. Falei: antes da reunião, me manda um link de saída do seu sistema de câmera IP. Ele mandou. Eu fui ver o que ele tinha feito — ou o que o desenvolvedor gênio dele tinha feito. Aí é o dev chinelinho que eu tanto falo: não estudou.
Sabe o que o cara fez? Streaming, como você sabe, é isso: eu pego um vídeo e transformo ele em vários arquivos pequenininhos, os chunks, que vão transacionando ali em várias requisições. É assim que funciona o padrão do Netflix, do YouTube, de todo mundo. Pois bem: ele pegou o mime type dos arquivos chunk .ts e declarou como JPG. Fez a inversão pra enganar a Cloudflare, pra CDN achar que aquilo ali era imagem.
E a lógica dele até fecha no papel: se você não tem custo de saída de CDN de vídeo, é mamão. Você tem a captação da câmera IP, a transcodificação, e a saída de graça pelo DNS da Cloudflare com o proxy ativado. Custo zero de banda. Só que não é assim que a banda funciona.
Respondi pro cliente educado, em respeito aos anos que ele foi bom cliente. Falei: não carece de reunião, eu não tenho interesse na parceria, e eu vou te explicar o motivo técnico — mandei o print, mandei a regra da Cloudflare, falei "não bota isso em produção".
O motivo é o seguinte. Quando você usa a Cloudflare com o proxy ativado, ela ainda está cacheando os seus arquivos de vídeo — no caso dele, funcionava porque a proporção de vídeo diante dos arquivos estáticos ainda era pequena. Traduzindo: ele não tinha cliente. Estava em fase de teste. A Cloudflare não tinha derrubado ele ainda.
E aí mora o problema clássico: na minha máquina funciona; a hora que eu boto em produção, o pau quebra. Eu perguntei pra ele: o que vai acontecer quando você divulgar esse link e tiver centenas de pessoas por dia? Quando você bater 1 tera de tráfego? E eu faço questão de repetir: 1 tera de tráfego não é nada. Nada.
Conta minha, feita agora em 28/09/2026 — na gravação eu joguei por cima e avisei que dependia de bitrate, então aqui vai o número fechado. A 2 Mbps, uma hora assistida consome cerca de 900 MB: 1 TB dá algo em torno de mil horas assistidas. Numa entrega mais pesada, a 20 Mbps, a mesma hora consome 9 GB — e 1 TB não passa de cerca de cem horas. Em qualquer uma das pontas: é pouquíssima gente. Câmera de escola transmitindo o dia inteiro come isso num piscar de olhos.
Quando o seu uso de vídeo fica muito maior que o padrão de JavaScript, CSS e JPG, a Cloudflare fala "ô, bonitão" e vem o rate limit. Foi o que aconteceu comigo quando eu testei — e eu tinha terabytes por dia, exatamente o que ele estava planejando ter. E, sério: será que você vai enganar a Cloudflare mandando mime type? Nem vou entrar no mérito. Não dá.
Sobre o preço de fazer isso direito: eu cheguei a entrar em contato com eles pra comprar saída de CDN de verdade, e é caro pra caramba. Pra dar saída de chunk nesse volume, você cai nos planos enterprise, e saída de CDN é caríssima. A gente até usa pra throughput quando tem pico muito alto, porque nessa hora compensa — mas não é saída padrão. Esse é o cálculo que faltava na conta do cliente que achava o meu plano caro, e é o mesmo motivo que me fez migrar da nuvem pro on-premise.
Então, resumindo o que eu checo antes de botar qualquer coisa atrás da nuvenzinha:
.tar, .gz, pacote de download, material de produtora? Qualquer coisa que fuja do padrão da internet — HTML, JavaScript, CSS, JPG — entra no radar. Quando eles resolverem aplicar, não tem muito o que fazer.Eu gravei em 02/07/2026 e estou escrevendo isto em 28/09/2026. O teste do proxy na saída do meu CDN é de anos antes da gravação, e o caso do cliente de câmera IP é de alguns meses antes dela. Prefiro te avisar a fingir que é tudo do mesmo dia.
O que eu conferi hoje, na fonte: o teto de upload por plano — e foi aí que eu corrigi o meu próprio número do Pro — e o texto dos termos sobre servir vídeo pela CDN, que segue valendo do jeito que eu descrevi. Limite e preço de plataforma mudam. Antes de fechar arquitetura em cima disso, abra a documentação vigente: eu não vou te dar número que eu não vi na fonte hoje. E se você quer entender a fundo por que bloquear robô na Cloudflare também tem efeito colateral, eu já escrevi sobre o interruptor que derruba o seu Googlebot junto com o treino de IA — mesma empresa, mesma lógica de regra da casa.
TODA SEGUNDA · MEIO-DIA · AO VIVO
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Se você quer entender de infraestrutura de verdade — 20 anos de experiência com essa bagaça, de quem paga a conta e de quem bota a mão na massa —, eu vou fazer pessoalmente uma imersão presencial de infraestrutura em São Paulo, três dias, pegando ponta a ponta. Como assim ponta a ponta? A primeira coisa que eu preciso pra subir alguma coisa é IP público: como funciona, BGP, configuração, se eu posso ter o meu IPv4 e o meu IPv6, e quais são as pegadinhas que não te contam — igualzinho aos 100 MB deste artigo. Depois você precisa de hardware, depois de lógica, deploy, git, Docker, Kubernetes, depois de alta disponibilidade e redundância. "Ah, Josimar, você gastou 20 anos pra aprender e vai ensinar em três dias?" Óbvio que não dá pra ensinar detalhado, passo a passo, tudo o que você vai fazer. Mas dá pra te entregar o caminho, pra você não passar raiva — até porque, com inteligência artificial, hoje está de boa encontrar o como. O segredo é saber o que você tem que fazer. Essa é a manha. Data, valor e condição ficam na página da imersão, que é onde essa informação está certa — não numa gravação de julho. Um abraço e até a próxima.
Baseado na gravação do canal @josimarjmv publicada em 02/07/2026 (14min38), com transcrição própria das legendas do próprio vídeo. São da minha vivência e foram ditos na gravação: ser CEO hands-on de uma empresa de tecnologia e cuidar pessoalmente da infraestrutura pesada no Brasil e nos Estados Unidos, por ser quem paga a conta; o limite de 100 MB de upload no plano free com o proxy ativado e a falha silenciosa que consome horas; as saídas de multipart e de subdomínio com a nuvenzinha desativada e SSL próprio; a política de uso justo ser pública, sem número, baseada em métricas qualitativas, e valer para qualquer arquivo fora do padrão HTML, JavaScript, CSS e JPG; o teste feito anos atrás ativando o proxy da Cloudflare na saída do nosso CDN, que sai com terabytes de banda por dia, e o rate limit resultante com requisições de 300 a 500 milissegundos, resolvido desativando a nuvenzinha na hora por já haver estrutura e SSL próprios; a Cloudflare empurrar quem transaciona vídeo para o plano pago e para o R2; o restream de câmera IP de escolas e obras, transcodificado para formato web aberto para iPhone e Android; o cliente de cinco a seis anos de casa que anunciou a saída alegando preço, propôs parceria por metade do valor e mandou o link do sistema; o desenvolvedor dele ter declarado o mime type dos chunks .ts como JPG para enganar a Cloudflare; o esquema só não ter sido pego por ele ainda estar em fase de teste, sem proporção relevante de vídeo; a resposta educada recusando a parceria, com print e explicação técnica, em respeito aos anos de relacionamento; a afirmação de que 1 tera de tráfego não é nada e depende de cálculo de bitrate; o contato com a Cloudflare para comprar saída de CDN, considerada caríssima e restrita a planos enterprise, usada por nós apenas para throughput em picos muito altos; e o convite para a imersão presencial de infraestrutura de três dias em São Paulo, cobrindo IP público, BGP, IPv4 e IPv6, hardware, lógica, deploy, git, Docker, Kubernetes, alta disponibilidade e redundância. É apuração minha, feita em 28/09/2026, e não estava na gravação: a tabela oficial de limites da Cloudflare, com o tamanho máximo do corpo da requisição em 100 MB no Free, 100 MB no Pro — número que eu havia estimado em 200 MB na gravação e que aqui está corrigido —, 200 MB no Business e até 5 GB no Enterprise, ajustável pelo cliente em Network → Maximum Upload Size; e o trecho dos Service-Specific Terms da Cloudflare sobre a CDN dos planos Free, Pro e Business, "Cloudflare reserves the right to disable or limit your access to or use of the CDN … if you use or are suspected of using the CDN without such Paid Services to serve video or a disproportionate percentage of pictures, audio files, or other large files", com os produtos pagos indicados sendo a plataforma de desenvolvedor, o Images e o Stream. Também é conta minha, e não da gravação, a estimativa de consumo por bitrate: cerca de 900 MB por hora assistida a 2 Mbps, o que põe 1 TB em torno de mil horas, e cerca de 9 GB por hora a 20 Mbps, o que põe o mesmo 1 TB em torno de cem horas. Sobre as minhas imersões eu não repito preço, data nem condição aqui: essa informação é final e fica na página de cada imersão.