No post anterior, montamos um blog completo com Hugo, GitHub, Cloudflare Pages e Pages CMS sem gastar um centavo. A stack funciona, é rápida, e para a maioria dos blogs pessoais vai continuar funcionando por muito tempo sem pedir nada em troca. Mas “grátis” não significa “sem limites”, e entender onde estão as paredes antes de bater nelas é o tipo de coisa que poupa dor de cabeça lá na frente.

Este post é o complemento prático daquele tutorial. Aqui vamos olhar para os limites reais de cada serviço gratuito da stack, discutir em que cenários eles começam a apertar, e listar alternativas para quando — ou se — isso acontecer. Nada de passo a passo de instalação; a ideia é dar o mapa geral para que você tome decisões informadas.

O preço do “grátis”#

Serviços gratuitos para desenvolvedores existem por razões bem concretas. O GitHub quer que você e seu time usem a plataforma até o ponto em que faz sentido pagar pelo plano Team ou Enterprise. A Cloudflare quer que seu domínio passe pela rede deles, porque mais sites significam mais dados sobre ataques e mais argumentos de venda para clientes corporativos. O Pages CMS é um projeto open source mantido por um único desenvolvedor que precisava da ferramenta e decidiu compartilhá-la.

Nenhuma dessas motivações é ruim — na verdade, o alinhamento de incentivos é o que faz o modelo funcionar. O GitHub não vai tirar seu repositório gratuito amanhã, e a Cloudflare não vai cobrar pelo bandwidth do seu blog de receitas. O ponto é que cada um desses serviços tem limites desenhados para separar o uso pessoal e de pequenos projetos do uso comercial em escala, e conhecer esses limites é parte de usar a stack com confiança em vez de com esperança.

Nas próximas seções, vamos passar por cada peça da stack — GitHub, Cloudflare Pages e Pages CMS — com números concretos e contexto suficiente para você avaliar se algum deles é relevante para o seu caso.

GitHub Free: o repositório tem paredes#

O plano gratuito do GitHub é extraordinariamente generoso para o que a maioria das pessoas precisa: repositórios públicos e privados ilimitados, colaboradores ilimitados em repos públicos, e funcionalidades suficientes para rodar projetos sérios sem pagar nada. Mas generoso não é infinito, e os limites que existem estão em lugares que afetam diretamente quem mantém um site estático.

Tamanho do repositório e dos arquivos#

O GitHub recomenda que repositórios fiquem abaixo de 1 GB e insiste fortemente que não passem de 5 GB. Não existe um hard limit publicado para o tamanho total — o que acontece na prática é que, acima de 5 GB, o suporte entra em contato pedindo que você reduza o tamanho ou mude de abordagem. Arquivos individuais têm um limite real de 100 MB via linha de comando; pelo browser, o teto cai para 25 MB. Qualquer push com um arquivo acima de 100 MB é simplesmente rejeitado.

Para um blog Hugo, isso raramente é um problema. Markdown pesa quase nada, e o repositório inteiro de um blog com centenas de posts dificilmente passa de algumas dezenas de megabytes. O risco mora nas imagens. Se você versionar fotos em alta resolução direto no repositório em vez de otimizá-las antes de commitar, o histórico do Git vai acumulando cada versão de cada arquivo, e o tamanho do repo cresce de um jeito que não é óbvio até você tentar clonar e perceber que está baixando gigabytes de JPEGs antigos.

Git LFS: 1 GB de storage, 1 GB de banda#

Para arquivos grandes que realmente precisam estar no repositório, o GitHub oferece o Git Large File Storage. O LFS armazena o arquivo fora do repo e deixa no lugar dele um ponteiro leve. O plano gratuito inclui 1 GB de armazenamento e 1 GB de banda por mês — e os dois limites são mais apertados do que parecem. Cada push de um arquivo consome storage cumulativamente (pushar o mesmo arquivo de 500 MB duas vezes esgota a cota), e cada download por qualquer pessoa ou CI consome banda. Para um blog pessoal com imagens otimizadas, você provavelmente nunca vai precisar de LFS. Mas é bom saber que o limite existe e que, se você esbarrar nele, os pushes são rejeitados silenciosamente.

GitHub Actions: 2.000 minutos para repos privados#

O GitHub Actions é gratuito e ilimitado para repositórios públicos usando runners padrão. Para repositórios privados, o plano Free inclui 2.000 minutos por mês de execução em runners Linux — o que equivale a mais de 33 horas de CI/CD. Se o seu repositório Hugo é público, esse limite simplesmente não se aplica. Se é privado, os 2.000 minutos são mais do que suficientes para a maioria dos fluxos: um build Hugo típico leva menos de um minuto, então você precisaria fazer mais de 60 deploys por dia para chegar perto do teto.

Vale notar que a Cloudflare Pages já cuida do build e deploy quando você conecta o repositório, então a maioria dos blogs Hugo nessa stack nem usa GitHub Actions para deploy. Os minutos só entram na conta se você configurar workflows adicionais — linting, testes, otimização de imagens, esse tipo de coisa.

O detalhe do repo público vs. privado#

A escolha entre repositório público e privado muda bastante a equação de limites. Com um repo público, você tem Actions ilimitado e visibilidade total do código — o que, para um blog, não é necessariamente um problema, já que o conteúdo vai ser publicado de qualquer forma. Com um repo privado, você ganha privacidade sobre rascunhos e configurações, mas entra no regime de cotas de Actions e Packages. Para a maioria dos blogs pessoais, manter o repositório público é a decisão mais simples e a que deixa mais margem dentro do plano gratuito. Se você tem razões para manter o repo privado — conteúdo sensível em rascunho, configurações que não quer expor — os limites do plano Free ainda são confortáveis para um único site com deploys moderados.

Cloudflare Pages Free: generoso, mas com teto#

A Cloudflare Pages é, de longe, a peça mais generosa dessa stack. Bandwidth ilimitado, requests ilimitados para conteúdo estático, SSL automático, CDN global, sites ilimitados — tudo no plano gratuito, sem pedir cartão de crédito. É o tipo de oferta que faz você desconfiar, mas a lógica por trás dela é sólida: a Cloudflare quer seu domínio passando pela rede deles, e hospedar sites estáticos é computacionalmente barato o suficiente para servir como porta de entrada. Os limites que existem não estão no tráfego, mas no processo de build e na escala de arquivos.

500 builds por mês — e é por conta, não por projeto#

Cada push para o repositório conectado dispara um build na Cloudflare. O plano gratuito permite 500 builds por mês, e esse é o limite que mais confunde as pessoas: ele é por conta, não por projeto. Se você tem três sites rodando na mesma conta Cloudflare, os três compartilham a mesma cota de 500 builds. Para um blog pessoal com um deploy por dia, são cerca de 30 builds por mês — confortável até com vários sites. O cenário onde isso aperta é o de times que fazem iterações rápidas com múltiplos pushes por dia em vários projetos, ou quem usa preview deployments extensivamente durante o desenvolvimento.

Na prática, o limite de builds é mais uma questão de disciplina de workflow do que uma restrição técnica. Consolidar mudanças em commits menos frequentes em vez de pushar cada vírgula resolve o problema para quase todo mundo. E se 500 builds por mês não forem suficientes, o plano Pro aumenta para 5.000 — mas a essa altura você provavelmente já tem um motivo comercial para pagar.

Um build por vez#

O plano gratuito processa um único build de cada vez. Se você faz push em dois projetos ao mesmo tempo, o segundo espera na fila até o primeiro terminar. Para um blog Hugo, onde o build inteiro leva segundos, isso é imperceptível. A limitação se torna relevante para sites maiores com processos de build mais pesados — frameworks JavaScript com etapas de bundling, otimização de imagens no pipeline, esse tipo de coisa — ou para contas com muitos projetos fazendo deploy simultaneamente. O plano Pro sobe para 5 builds concorrentes, e o Business para 20.

20.000 arquivos por site#

Cada site no plano gratuito pode ter no máximo 20.000 arquivos. Isso conta tudo que é deployado: HTMLs gerados, imagens, CSS, JavaScript, fontes, favicons. Um blog Hugo de porte médio fica muito longe desse número — mesmo com centenas de posts e imagens, dificilmente você passa de alguns milhares de arquivos. O limite começa a ser relevante para sites de documentação grandes com milhares de páginas, ou para projetos que geram muitos assets por página. Planos pagos elevam o teto para 100.000 arquivos.

Functions: o limite de 100.000 requests/dia vem do Workers#

Se você usar Cloudflare Pages Functions — código serverless que roda no edge — as requisições contam contra a cota do plano Workers Free, que é de 100.000 requests por dia, resetando à meia-noite UTC. Esse limite é compartilhado entre Pages Functions e qualquer Worker que você tenha na mesma conta. Para um blog estático puro, isso não se aplica — HTML, CSS, imagens e JavaScript estático não consomem essa cota. Ela só entra em jogo se você adicionar funcionalidades dinâmicas ao site, como um formulário de contato processado no edge ou uma API customizada. Ainda assim, 100.000 requests por dia é um volume considerável para funcionalidades auxiliares de um blog.

Pages CMS: grátis, open source — e os riscos que vêm com isso#

O Pages CMS ocupa uma posição diferente das outras peças da stack. GitHub e Cloudflare são empresas bilionárias oferecendo planos gratuitos como estratégia comercial; o Pages CMS é um projeto open source criado e mantido por Ronan Berder, um desenvolvedor que precisava de um CMS simples para sites estáticos e decidiu compartilhar a solução. É 100% gratuito, licenciado sob MIT, e pode ser usado tanto na versão hospedada em app.pagescms.org quanto deployado por conta própria no Vercel ou self-hosted. Não existe plano pago, não existe tier premium, não existe empresa por trás cobrindo custos de infraestrutura com receita de outros produtos.

Isso é ao mesmo tempo a maior qualidade e o maior risco do Pages CMS.

Projeto de um único desenvolvedor#

O Pages CMS não tem uma equipe, não tem funding público conhecido, e não tem uma organização sustentando o desenvolvimento. Isso não é uma crítica — muitos dos melhores softwares open source começaram exatamente assim. Mas significa que a velocidade de correção de bugs, o ritmo de novas funcionalidades, e a própria continuidade do projeto dependem da disponibilidade e do interesse de uma única pessoa. Se você acompanhar o repositório no GitHub, vai ver períodos de atividade intensa seguidos de períodos mais silenciosos, o que é perfeitamente normal para um projeto mantido no tempo livre de alguém.

Para um blog pessoal, isso é um risco aceitável. Para um site que uma empresa depende para publicar conteúdo regularmente, é o tipo de fragilidade que merece pelo menos um plano B.

Dependência total da API do GitHub (e seus rate limits)#

O Pages CMS não tem banco de dados próprio para conteúdo. Ele lê e escreve diretamente nos arquivos do seu repositório GitHub usando a API do GitHub. Isso é elegante — seu conteúdo nunca sai do repositório, não existe sincronização para quebrar, e qualquer mudança feita pelo CMS é um commit normal que aparece no histórico do Git. Mas também significa que toda operação no CMS está sujeita aos rate limits da API do GitHub: 5.000 requests por hora para usuários autenticados. Na prática, editar posts e fazer upload de imagens em um blog pessoal não chega perto desse limite. O cenário problemático é o de um time com vários editores trabalhando simultaneamente em um repositório com muitos arquivos, onde a navegação e o cache do CMS podem gerar um volume de chamadas à API que começa a encontrar throttling.

Sem suporte comercial nem SLA#

Se algo quebrar no Pages CMS — e software quebra — não existe um canal de suporte para abrir um ticket e esperar uma resposta com prazo definido. O que existe é a issue queue do GitHub do projeto, onde você pode reportar o problema e torcer para que a comunidade ou o mantenedor responda. Para quem está acostumado com o ecossistema open source, isso é o padrão e funciona razoavelmente bem. Para quem vem do mundo de SaaS com SLA e suporte por chat, a diferença de expectativa pode ser frustrante. Não existe garantia de uptime para a instância hospedada em app.pagescms.org, e não existe ninguém de plantão se ela sair do ar em um domingo à noite.

O que acontece se o projeto for abandonado#

Essa é a pergunta que ninguém gosta de fazer sobre projetos open source que usa, mas que todo adulto responsável deveria considerar. Se o mantenedor do Pages CMS decidir parar de manter o projeto amanhã, seu conteúdo continua exatamente onde sempre esteve: no seu repositório GitHub, em arquivos Markdown com front matter YAML. Você não perde nada. O que você perde é a interface de edição — e aí volta a editar conteúdo direto no GitHub ou no editor de texto local, o que não é o fim do mundo, mas é exatamente o inconveniente que o CMS existia para resolver. A licença MIT garante que qualquer pessoa pode fazer um fork e continuar o desenvolvimento, mas entre o abandono de um projeto e o surgimento de um fork viável costuma existir um período de limbo que pode durar meses.

O fato de o conteúdo ser portável — Markdown puro em um repositório Git — é a melhor proteção que essa arquitetura oferece. Você nunca fica preso a um CMS específico, e migrar para qualquer alternativa é uma questão de reconfigurar a ferramenta de edição, não de exportar dados de um banco de dados proprietário.

Quando esses limites realmente importam#

Listar limites fora de contexto assusta mais do que deveria. Quinhentos builds, vinte mil arquivos, dois mil minutos — são números que parecem restritivos até você colocar um caso de uso real do lado e perceber que a maioria das pessoas nunca vai chegar perto deles. O que importa não é o número absoluto, mas a relação entre o seu uso e o teto disponível.

O blogueiro solo provavelmente nunca vai esbarrar neles#

Um blog pessoal com um autor publicando alguns posts por mês é o cenário para o qual essa stack gratuita foi praticamente desenhada. Faça as contas: se você publica três vezes por semana e faz um push por post, são cerca de 12 builds por mês — 2,4% da cota da Cloudflare. O repositório de um blog com quinhentos posts em Markdown, imagens otimizadas e o tema Hugo inteiro dificilmente passa de 200 MB. As chamadas à API do GitHub pelo Pages CMS para editar um post e subir uma imagem cabem confortavelmente em uma fração mínima do rate limit de 5.000 requests por hora. Nesse cenário, os limites são tão distantes que funcionam como se não existissem.

Múltiplos sites na mesma conta mudam a equação#

O cálculo muda quando você começa a acumular projetos. A cota de 500 builds da Cloudflare Pages é por conta, então cinco sites com 100 builds cada já esgotam o mês. O mesmo vale para os minutos de GitHub Actions em repos privados — os 2.000 minutos são compartilhados entre todos os repositórios da conta. Se você é o tipo de pessoa que gosta de manter um blog pessoal, um site de portfólio, uma landing page para um projeto paralelo e a documentação de uma ferramenta que escreveu, cada projeto sozinho é leve, mas a soma pode começar a pressionar os limites.

A solução mais simples é manter projetos em contas separadas quando faz sentido, ou aceitar que a consolidação tem um custo em termos de cota. Outra abordagem é reduzir builds desnecessários: desabilitar deploy automático de branches que não precisam de preview, acumular mudanças em menos commits, e configurar ignore patterns no Cloudflare Pages para que pushes que não alterem o conteúdo do site não disparem builds.

Times com vários editores e deploys frequentes#

O cenário onde os limites começam a morder de verdade é o de um time — mesmo pequeno — com múltiplas pessoas editando conteúdo e fazendo deploy ao longo do dia. Cada salvamento no Pages CMS é um commit, cada commit em uma branch conectada é um build. Três editores publicando e revisando conteúdo ativamente podem gerar dezenas de builds por dia sem perceber. O build concorrente único do plano gratuito da Cloudflare significa que essas builds entram em fila, e a cota mensal de 500 começa a parecer menos confortável.

No lado do Pages CMS, múltiplos editores navegando e editando simultaneamente multiplicam as chamadas à API do GitHub. O rate limit de 5.000 requests por hora é por token de autenticação, então na prática cada editor tem sua própria cota — mas se o time compartilha uma mesma instalação com um único GitHub App, o limite é compartilhado. Além disso, repositórios com muitos arquivos fazem o CMS trabalhar mais para carregar e cachear a estrutura de diretórios, o que pode resultar em uma experiência mais lenta e em bugs de cache que já foram reportados na issue queue do projeto.

Para times nesse perfil, a stack gratuita ainda funciona, mas exige mais atenção ao workflow. E é exatamente o ponto em que faz sentido avaliar se um plano pago em uma das pontas — Cloudflare Pro para mais builds, ou um CMS com suporte comercial — não se paga em tempo e frustração economizados.

Alternativas em alto nível#

Se você chegou até aqui e concluiu que algum limite da stack gratuita é relevante para o seu caso, a boa notícia é que cada peça pode ser substituída de forma independente. A arquitetura de site estático com repositório Git é modular por natureza — você pode trocar o hosting sem trocar o CMS, trocar o repositório sem trocar o gerador, e assim por diante. O que segue não é uma análise detalhada de cada alternativa, mas um mapa de opções para que você saiba onde procurar.

Para o repositório: GitLab, Codeberg, Gitea self-hosted#

Se os limites do GitHub Free são o problema — tamanho de repositório, minutos de CI, ou simplesmente uma preferência por não depender de uma plataforma específica — existem alternativas maduras. O GitLab oferece repositórios privados ilimitados com 400 minutos de CI/CD por mês no plano gratuito e tem seu próprio sistema de Pages para hosting estático. O Codeberg é uma alternativa sem fins lucrativos, baseado no Forgejo, sem limites artificiais de CI e com uma filosofia explicitamente voltada para software livre. Para quem quer controle total, o Gitea ou o Forgejo podem ser instalados em qualquer servidor próprio — um VPS barato é mais do que suficiente para hospedar repositórios Git com CI integrado.

A principal consideração ao trocar de plataforma Git é o efeito cascata sobre o resto da stack. O Pages CMS depende especificamente da API do GitHub, então trocar o repositório para o GitLab significa trocar também o CMS. A Cloudflare Pages se integra nativamente com GitHub e GitLab, então essa parte da migração é direta.

Para o hosting/deploy: Netlify, Vercel, GitHub Pages, Caddy/Nginx + CI próprio#

A Cloudflare Pages não é a única opção para hospedar sites estáticos com deploy automático a partir de um repositório Git. O Netlify oferece um plano gratuito com 300 minutos de build por mês e 100 GB de bandwidth — menos generoso que a Cloudflare em banda, mas com um ecossistema de plugins e funcionalidades como formulários e identity que podem simplificar certos casos de uso. O Vercel tem um plano gratuito voltado para frameworks JavaScript, mas funciona perfeitamente com Hugo e oferece 100 GB de banda por mês. O próprio GitHub Pages é uma opção sólida para sites Jekyll e Hugo, com bandwidth generoso e deploy direto do repositório — a limitação principal é a ausência de build customizado sem GitHub Actions e o suporte mais limitado a configurações avançadas de roteamento.

Para quem quer sair completamente de plataformas gerenciadas, a combinação de um servidor próprio com Caddy ou Nginx, um CI leve como Drone ou Woodpecker, e um deploy via rsync ou webhook oferece controle absoluto. O custo é um VPS de cinco ou dez dólares por mês e o tempo de configuração e manutenção — que para um sysadmin é trivial, mas para quem montou o blog seguindo um tutorial pode ser um salto de complexidade considerável.

Para o CMS: Decap CMS, Sveltia CMS, TinaCMS, Publii#

O Pages CMS é uma das várias opções de CMS para sites estáticos baseados em Git, e se os riscos de depender de um projeto de um único mantenedor não te agradam, existem alternativas com perfis diferentes de maturidade e suporte.

O Decap CMS, antigo Netlify CMS, é o veterano do espaço. É open source, funciona como uma single-page app que roda no próprio site em uma rota /admin, e commita diretamente no repositório. Tem uma comunidade grande e é o mais testado em produção, mas o desenvolvimento desacelerou nos últimos anos e a experiência de edição não é das mais modernas. O Sveltia CMS se propõe a ser um substituto drop-in para o Decap com uma interface mais rápida e polida, mantendo compatibilidade com a mesma configuração — vale a pena como alternativa direta se o Decap funciona para o seu fluxo mas a interface te incomoda.

O TinaCMS é a opção mais ambiciosa do grupo. Oferece edição visual em tempo real no próprio site, suporta Markdown e MDX, e tem tanto uma versão self-hosted quanto um serviço cloud com plano gratuito. O trade-off é a complexidade de setup, que é significativamente maior do que o Pages CMS, e uma dependência mais forte do ecossistema JavaScript e de frameworks como Next.js — embora funcione com Hugo, a integração não é tão direta.

O Publii segue uma filosofia completamente diferente: é um aplicativo desktop para Windows, Mac e Linux que funciona como um CMS local. Você edita o conteúdo na sua máquina, o Publii gera o site estático e faz o deploy para GitHub Pages, Netlify, S3 ou qualquer servidor via FTP. Não depende de nenhuma API, não precisa de internet para editar, e elimina toda a camada de CMS web. A desvantagem é que o conteúdo vive na máquina onde o Publii está instalado, e o workflow colaborativo com múltiplos editores não é o ponto forte — na verdade é praticamente impossível de conseguir manter um blog com múltiplos autores no Publii.

Em todos os casos, o fato de o conteúdo ser Markdown com front matter em um repositório Git significa que a migração entre essas ferramentas é uma questão de reconfiguração, não de conversão de dados. Você escolheu uma arquitetura onde o conteúdo é independente da ferramenta de edição, e essa é a decisão mais valiosa de toda a stack.

Minha opinião: vale começar com tudo grátis#

Depois de listar limites, riscos e alternativas, seria fácil terminar este post com uma recomendação de cautela — algo como “avalie bem antes de escolher” ou “cada caso é um caso”. Mas a verdade é mais simples do que isso: para quem está começando um blog ou site pessoal, a stack gratuita com Hugo, GitHub, Cloudflare Pages e Pages CMS é a melhor escolha disponível hoje, e não é uma escolha de compromisso.

Os limites existem, mas são desenhados para um volume de uso que a grande maioria dos sites pessoais nunca vai atingir. O bandwidth ilimitado da Cloudflare elimina a preocupação mais comum de quem hospeda conteúdo próprio. Os 500 builds mensais são mais do que suficientes para qualquer ritmo razoável de publicação. O GitHub Free oferece tudo que um repositório de blog precisa sem cobrar nada. E o Pages CMS, apesar dos riscos inerentes a um projeto de um único mantenedor, resolve o problema real de editar conteúdo sem precisar abrir um terminal.

O mais importante é que essa stack não te prende. Seu conteúdo é Markdown em um repositório Git — o formato mais portável que existe para texto na web. Se amanhã o Pages CMS for abandonado, você troca de CMS. Se a Cloudflare mudar os termos do plano gratuito, você move o site para o Netlify em uma tarde. Se o GitHub fizer algo que te desagrade, seus arquivos estão no seu disco local e podem ir para qualquer outro serviço Git com um git remote set-url. Cada decisão nessa arquitetura é reversível, e isso vale mais do que qualquer garantia de SLA.

Comece com tudo grátis. Publique. Escreva. Quando — e se — algum limite se tornar real no seu uso concreto, você vai saber exatamente qual peça trocar e por quê, porque o problema vai ser específico e não hipotético. Otimizar antes de ter um problema é engenharia prematura, e engenharia prematura é o jeito mais eficiente de nunca publicar nada.

Se uma das lacunas que você sentir primeiro for a falta de comentários nativos, já escrevi sobre como resolver isso com uma solução self-hosted leve e sem rastreamento.