Você não precisa do Payload CMS. Se a ideia é abandonar o WordPress e ir para um site em TypeScript ou JavaScript na borda — Cloudflare Workers ou outro serverless —, o Payload é um headless excelente. Não é automaticamente a peça certa. Eu começo falando bem dele. Depois eu mostro onde ele vira overkill.
Entre os headless que eu testei, Payload ganha de Strapi e Directus: instala, sobe o admin, API e auth já vêm, e roda em serverless. Na era da IA, porém, dá para montar site, banco e um admin enxuto no próprio Worker, com D1 e Cloudflare Access. Payload continua fazendo sentido com muitos editores, permissão complexa e área de membros. Para projeto simples, collection no código de um CMS pronto é mais dependência do que atalho.
- O que o Payload acerta
- Admin, API, auth, código limpo, serverless
- O custo escondido
- React, Next.js, adapter e lib que o site pequeno não usa
- Alternativa que eu uso
- Worker + D1 + admin próprio, às vezes em Worker separado
Saindo do WordPress e o que um headless CMS realmente é
No final de 2025 eu queria abandonar de vez o WordPress e comecei a pesquisar headless CMS. CMS sem cabeça: um admin onde você administra postagem e collection do banco, e o front nasce separado. Tem gente que faz isso até com WordPress, deixando o front na Cloudflare. Eu procurava uma coisa um pouco monolítica, porque eu gostava do WordPress justamente por ter front e back juntos. Ainda gosto. Na era da IA, menos.
Headless, no papel, resolve o trauma do WordPress: você não fica refém de plugin, tema e daquele banco único. O admin fala por API. O front pode ser o que você quiser. Payload entrou nessa busca porque parecia o meio-termo: admin pronto, código no repositório, possibilidade de colar front e back ou separar em subdomínio, subdiretório, domínio diferente.
Por que o Payload se saiu melhor que Strapi e Directus
Eu testei Strapi e Directus. Na época eu não tinha muita experiência com as stacks modernas de JavaScript. Meu músculo era PHP, coisa antiga. Payload foi o mais de boa: instalei num clique, vi o admin funcionar, fiquei feliz. Comentário de quem já usava batia com o que eu vi: código estruturado, limpo, bonito, fácil de editar.
A diferença prática, pelo menos até a data em que eu testei, é o lugar onde o schema mora. No Strapi e no Directus você monta banco e estrutura pelo painel. No Payload as collections iam no código. Ele foi feito para ser leve e rodar em serverless, então faz sentido. Eu quebrei um pouco a cabeça nisso. Hoje, quando eu faço site com IA, peço para ela criar o banco ou eu mesmo abro o D1 antes, para a IA já nascer em cima da estrutura.
Nada é perfeito. Todo CMS traz problema. A pergunta que a era da IA coloca em cima da mesa é outra: eu realmente preciso desse CMS?
Admin pronto, API, auth — e a pergunta que o Next.js levanta
Payload entrega admin pronto, API automática, auth pronto. É open source. Dá para hospedar em servidor. Funciona na Cloudflare, mas foi feito primariamente para a Vercel, porque nasceu em Next.js. Essas coisas estão mudando, e isso é ponto a favor: na versão 4 eles pretendem abandonar o Next.js como único caminho e rodar com adapter, com TanStack no primeiro alvo. Para mim isso é interessante. Eu já gravei que não gosto de Next.js e não recomendo. Ele te deixa um pouco dependente da Vercel. Você pode rodar em outro serverless, mas funciona melhor onde a Vercel administra o Next, porque é a Vercel que cria o Next.
Na época desta gravação a v4 ainda era rumo, não o padrão de produção. Se a sua decisão depende de sair do Next, olhe o estado atual do adapter TanStack no repositório do Payload antes de apostar a casa nisso.
CMS pronto versus stack sob medida na era da IA
Apesar de o Payload vir com dashboard e tudo, hoje você cria com IA em pouco tempo e protege na Cloudflare com Access. Gerencia banco, post, o que for. Não precisa criar do zero no sentido artesanal de 2018. Também não precisa usar algo pronto. São duas opções.
Quando você escolhe CMS pronto, você fica dependente da estrutura daquele CMS. Headless fala por API, por rota, então não é o cativeiro do WordPress. Ainda assim você estrutura do jeito do produto. Dependendo do projeto, isso é overkill: peso desnecessário. Payload te amarra em React, Next.js e adapter. Tem lib, tem dependência. Tem site que não precisa disso.
Eu gostava do Payload porque parecia monolítico: dava para instalar front perto do back. Também dá para separar. Flexibilidade existe. O que eu acho desnecessário é herdar a stack inteira para um site que a IA monta do tamanho do problema.
Cloudflare Workers e quando o headless era necessário
Payload foi adaptado para Cloudflare. Eu ainda não reparei a fundo como ele se comporta dentro da Cloudflare, então não vou vender esse deploy. O que eu sei é o outro lado: na Cloudflare é fácil conectar as peças. Headless fazia sentido quando você precisava de serviço terceiro como Supabase, ou de um servidor só para o CMS, e deixava o serverless só no front.
No Cloudflare Workers de hoje você roda tudo dentro de um Worker. Não precisa de servidor ou serviço só para back e banco. Payload veio com o intuito de ser exatamente o que o Worker faz agora, só que trazendo a stack e o CMS prontos. Se o Worker já é o runtime, o CMS pronto vira uma camada a mais, não a base.
Quando o Payload ainda vale a pena
Área de membros, muitos editores, muitos autores: aí Payload é boa opção, porque a segurança do admin já veio pronta. Se você for criar com IA um site do zero, com admin no mesmo domínio, subdomínio ou subdiretório, dentro de um Worker só, o auth que o CMS já oferece pode ser mais seguro do que o login que a IA inventa.
Eu recomendo fazer sites do zero com IA, mas separar o back administrativo e evitar login desnecessário. Eu também já criei área de membros do zero com IA e até hoje não tive problema. Claro: nenhum hacker foi lá tentar invadir. Não trate o meu azar zero como auditoria.
Workflows, pelo menos na época em que eu usei o Payload, eram da versão enterprise — e isso incha o bolso. Dá para criar o fluxo do zero. Não tem essa prisão. Quem gosta de coisa versionada, com atualização e empresa responsável pelo changelog, encontra no Payload um produto, não um script solto.
- Muitos editores e autores logando para publicar
- Permissão de escrita mais complexa do que “eu e o rascunho”
- Área de membros em que o auth pronto pesa mais do que o admin da IA
- Vontade de stack versionada, com empresa cuidando de release
Payload + IA versus CMS próprio do zero
Se a comparação é Payload mais IA versus site criado com a sua IA do zero, o Payload entrega o projeto mais rápido. Hoje, com IA, você também faz o site num dia, então a comparação não é tão justa. Às vezes você tem mais trabalho tentando esquematizar tudo dentro do Payload do que mandando a IA nascer o mínimo.
CMS próprio é mais enxuto. Você cria o que é necessário. Não precisa carregar coisa que o projeto não vai usar. Payload pode ser mais completo porque já traz essas bibliotecas. CMS próprio te dá mais controle — e controle foi um dos motivos de eu abandonar o WordPress. Eu queria estruturar o banco do jeito que eu quisesse. Payload, por ser headless, também deixa criar collection e moldar o banco. A diferença é onde isso mora e quanta lib vem junto.
No fluxo que eu uso agora: ou a IA cria o banco, ou eu crio no D1 antes e só então peço o site. A IA já trabalha em cima da tabela certa. No Payload da época, a collection no código era limpa, era o desenho do produto, mas eu quebrei a cabeça para um gesto que hoje é uma tela no D1.
Como escolher: Payload ou site com IA no Worker
Escolha Payload se você tem muitos editores, permissão complexa, área de membros pesada, ou se você quer versionamento e empresa atrás da atualização. Workflows oficiais, se ainda forem enterprise, pesam no preço; o fluxo em si você pode construir fora.
Escolha o site com IA se você quer o banco do seu jeito, se não tem tanta tabela, se o projeto é mais simples ou estático com Markdown, se a infra é enxuta e se controle total importa mais do que dashboard pronto. Você pode colocar front e back no mesmo Worker, ou criar o dashboard admin num Worker separado — que é o que eu costumo fazer.
O ponto do vídeo é este: Payload é excelente. Entre os headless que eu testei, é o mais simples, o mais rápido, o mais enxuto, e roda em serverless. Strapi e Directus pedem servidor e ainda vendem nuvem cara, com limite de requisição, o que para mim não tem sentido. Payload ganha de lavada de qualquer outro headless nessa prateleira. Mesmo assim, nem sempre você precisa dele para ter site estruturado, organizado e capaz de aguentar visita. Overkill não é xingamento. É tamanho errado.
- Liste quem edita o site: só você, um time pequeno ou dezenas de autores com permissão diferente.
- Marque se existe área de membros, login e dado por usuário. Se existir, o auth pronto do Payload pesa mais.
- Decida o runtime: se já é Cloudflare Workers + D1, pergunte que problema o Payload resolve que o Worker ainda não resolve.
- Se a resposta for só “admin bonito”, teste um admin mínimo com IA e Access antes de herdar Next, React e adapter.
- Se a resposta for permissão, versão e vários editores, instale o Payload e aceite a stack — inclusive o rumo da v4 com TanStack, se isso for requisito.
Na sequência
- Confirme se o projeto precisa de vários editores de verdade, não de um admin só para você.
- Se for Cloudflare Workers, desenhe D1 e rotas antes de assumir que falta um CMS headless.
- Separe o admin do site público quando houver login; Cloudflare Access cobre um pedaço disso sem CMS.
- Se escolher Payload, trate collection no código como schema versionado, não como formulário de painel.
- Se escolher CMS próprio, não invente área de membros “porque a IA consegue” sem alguém responsável por segurança.
- Releia o estado da v4 / TanStack se a sua recusa ao Next.js for o único motivo de esperar.
Onde isso quebra
Tratar Payload como único caminho para sair do WordPress. Sair do PHP não exige aquele admin.
Comparar Strapi e Directus só pelo painel e ignorar que eles pedem servidor e nuvem cara.
Colocar login, membro e permissão num Worker único feito pela IA e chamar isso de equivalente ao auth do Payload.
Herdar React, Next.js e dezenas de pacotes para um site estático em Markdown.
Apostar a migração inteira na v4 com TanStack antes de ela ser o caminho estável de produção.
Perguntas frequentes
Payload é melhor que Strapi e Directus?
Para o que eu testei, sim. Instala mais fácil, o código é mais limpo, e roda em serverless. Strapi e Directus, na minha experiência, pedem servidor e ainda vendem hospedagem nuvem cara com limite de requisição. Payload ganha nessa prateleira. Ganhar dos headless não significa que você precisa de um headless.
Eu preciso do Payload se vou hospedar na Cloudflare?
Não por padrão. Worker + D1 + um admin enxuto, protegido com Access, cobre site, post e banco sem o CMS. Payload tem caminho para Cloudflare, mas eu não aferi esse deploy a fundo. O Worker já faz o papel que o headless fazia quando o back vivia em outro servidor.
A versão 4 sai do Next.js?
O plano público do Payload é um adapter de framework, com TanStack como prova. Isso me interessa porque eu não recomendo Next.js. Até esta gravação isso era rumo da v4, não o padrão que eu estava usando no dia a dia. Confira o repositório e o blog oficiais antes de migrar por causa disso.
CMS próprio com IA é menos seguro?
Pode ser, principalmente em login e área de membros. O auth pronto do Payload existe para esse caso. Eu já fiz membro do zero com IA e não tive incidente, mas ninguém tentou invadir. Para vários editores, eu fico com o CMS. Para um admin só meu, atrás de Access, eu fico com o Worker.
Collection no código é vantagem ou dor?
As duas. Schema no repositório é limpo e combina com serverless. Para quem vinha do painel do Strapi, é um choque. No fluxo com IA, eu prefiro criar a tabela no D1 primeiro e deixar o site nascer em cima. No Payload da época, a collection no código era o jeito — e eu quebrei a cabeça até aceitar isso.