No fim de 2025, eu queria sair do WordPress e procurava um headless CMS que me deixasse separar o painel do site. Eu ainda gostava de ter tudo junto, mas já não queria depender de tema e plugin para controlar cada detalhe. Testei Strapi, Directus e Payload. Gostei do Payload logo na instalação; a dúvida veio depois: quanto daquele CMS eu realmente usaria?
O que me agradou quando testei o Payload
Minha experiência vinha muito mais de PHP do que das stacks modernas de JavaScript. No Payload, instalei o projeto, abri o painel e vi o admin funcionando sem ter de montar cada peça. O código me pareceu limpo e bem organizado. Na minha comparação, foi o headless CMS mais tranquilo de começar a usar.
Uma diferença prática apareceu quando fui estruturar os dados. No Payload que testei, as collections e os campos eram definidos no código; no Strapi e no Directus que usei, eu conseguia montar boa parte da estrutura pelo painel. Nenhum caminho é automaticamente melhor. Se a equipe prefere revisar schema junto com o projeto e versionar cada alteração, escrever isso no código faz sentido. Eu gostava de abrir o banco primeiro e definir a estrutura antes de pedir à IA para montar o site, então esse fluxo exigiu uma adaptação minha.
O Payload já entrega um conjunto maior que um simples editor de conteúdo: painel administrativo, APIs, collections e autenticação. É esse conjunto que economiza trabalho. Antes de instalá-lo, eu anotaria quais dessas peças o projeto realmente vai usar; se a resposta for só “preciso editar algumas páginas”, talvez você esteja levando uma stack inteira para resolver uma tela.
O painel pronto também traz decisões de stack
Quando testei a versão 3, o Payload era integrado ao Next.js. Isso não quer dizer que só rode na Vercel — a documentação permite implantar onde Next.js funciona —, mas significa que o projeto herda esse ecossistema. Eu prefiro não escolher Next.js automaticamente, então essa dependência pesava na minha decisão. O Payload 4 já aparece em versões canary com suporte a TanStack Start; ainda é uma linha de pré-lançamento, por isso eu não planejaria uma produção contando que essa migração esteja estável sem conferir as versões atuais.
Também dá para usar Payload na Cloudflare. Hoje existe um template oficial para Workers, D1 e R2. Eu não tinha examinado essa implantação a fundo quando fiz a comparação e não vou afirmar que ela funcione mal. Minha pergunta era outra: se consigo rodar a aplicação no Worker e usar D1, quanto o CMS acrescenta além do admin pronto? Se quiser comparar, teste o template oficial com as collections que seu site precisa e veja se a integração resolve o projeto sem exigir peças que você não usará.
Com IA, fazer um painel pequeno ficou bem mais rápido para mim. Posso definir as tabelas no D1, construir o site em um Worker e deixar o admin em outro, protegido pelo Cloudflare Access. Mas rapidez para gerar uma tela não é o mesmo que ter um sistema seguro. Se eu criar o painel, ainda preciso cuidar do login, das permissões, das atualizações e de como dados privados são acessados. O Payload oferece autenticação e regras de acesso, mas eu também revisaria e testaria essas configurações antes de publicar.
Quando uma área de membros pede uma base mais pronta
Eu levaria o Payload mais a sério quando há vários editores, muitos autores, permissões diferentes ou membros com dados privados. Nesse cenário, o admin deixa de ser só um formulário: as pessoas precisam ver e alterar apenas o que lhes cabe, e eu prefiro começar com os recursos de autenticação e controle de acesso do CMS em vez de confiar num primeiro painel improvisado pela IA.
Eu já montei uma área de membros com IA e não tive incidente, mas isso não prova que ela era segura; ninguém tentou invadi-la. Por isso, não usaria a minha experiência sem incidentes como argumento para ignorar segurança. Se você não quer manter esse tipo de lógica, uma solução que já tem permissões e usuários integrados pode valer mais do que a liberdade de montar tudo do seu jeito.
Workflows também entravam nessa conta. Na versão que usei, o recurso estava no plano Enterprise e pesava no preço. É possível construir um processo editorial por fora, mas aí a equipe passa a manter notificações, estados e regras. Eu compararia o custo do plano com o custo de criar e sustentar essas funções, em vez de olhar só para a rapidez da instalação.
Como eu escolheria entre Payload e um painel próprio
Para um site pequeno, com uma ou duas pessoas publicando, poucos tipos de conteúdo e sem área de membros, eu começaria por uma estrutura menor. Se o conteúdo pode ficar em Markdown ou o banco tem poucas tabelas, um Worker, D1 e um admin separado podem dar o controle que procuro sem puxar React, Next.js, adapters e toda a estrutura de um CMS. No meu caso, poder definir o banco antes de construir o site foi uma das razões para abandonar o WordPress.
Quando a equipe cresce, as permissões se multiplicam ou o painel pronto economiza uma parte grande do desenvolvimento, o Payload pode entregar esse projeto mais rápido e com uma base melhor organizada. Entre os headless CMS que testei, foi o mais simples e enxuto para mim. Strapi e Directus também servem a outros fluxos; a hospedagem e os limites variam conforme a configuração, então eu não os descartaria sem verificar o que o projeto exige.
A escolha que faço é bem direta: primeiro identifico quem vai editar, quais dados precisam de proteção e quais recursos de publicação são necessários. Se preciso mesmo do admin, da autenticação e das permissões que o Payload já traz, aceito a stack e uso o CMS. Se a equipe é pequena e o conteúdo é simples, prefiro construir só o painel e as tabelas de que preciso. Payload é bom — só não é obrigatório para ter um site organizado, escalável ou com milhares de visitas.