Um cliente me ligou em outubro passado em leve pânico. Ele tinha construído toda a sua plataforma de marketing em um CMS hospedado e o fornecedor tinha acabado de anunciar uma reestruturação de preços. Da noite para o dia, a conta dele ia de £180/mês para algo acima de £900. O conteúdo não era complexo. Um blog, um catálogo de produtos, talvez quarenta campos personalizados em três coleções. Nada que justificasse esse número. Aquela ligação é o motivo pelo qual passei os próximos três meses migrando dois projetos da Seahawk para Payload CMS e construindo um modelo de custo adequado em torno disso.
Então deixa eu te contar o que realmente encontrei.
O Que Payload CMS Realmente É (e Não É)
Payload é um CMS headless orientado por TypeScript e código. Você define suas coleções, globals e fields inteiramente em arquivos de config. Sem GUI para clicar ao redor no design de schema. O painel admin é gerado a partir do seu código, não o contrário. Essa inversão é o ponto todo, e também é a coisa que vai te derrubar se você vem do WordPress ou Contentful.
Não é um SaaS. Não há um tier hospedado Payload que você paga mensalmente. Você possui o deployment inteiramente. Isso é um recurso e uma restrição dependendo da sua situação.
Payload 2.0 foi lançado com suporte completo para PostgreSQL junto com MongoDB, que foi o desbloqueio que o tornou genuinamente viável para clientes que querem dados relacionais sem a ginástica NoSQL. No início de 2026, o ecossistema em torno dele amadureceu o suficiente para que eu esteja confortável recomendando para produção sem as ressalvas que eu costumava anexar.
No Que Está Realmente Construído
Por baixo: Next.js 15 para a interface admin, TypeScript em todo lugar, e sua escolha de Drizzle ORM (para Postgres) ou Mongoose (para MongoDB). As APIs REST e GraphQL são auto-geradas a partir do seu schema. Você também ganha uma API local para queries do lado do servidor que é rápida de um jeito que ainda me surpreende toda vez.
Onde Se Encaixa em 2026
Honestamente, Payload se senta em um sweet spot específico. Nem todo projeto pertence lá. Depois de rodar em uma dúzia de builds em toda Seahawk, aqui está o padrão que notei.
É um encaixe forte quando:
- O projeto é liderado por desenvolvedores desde o início. Significando um engenheiro real está o configurando, não um cliente que foi dito que pode "gerenciar tudo sozinho".
- Você precisa de lógica de field customizada, fields condicionais ou cadeias de relacionamento complexas que custariam caro em cobranças por recurso em algo como Contentful.
- O cliente é sensível a custos em um horizonte de 2-3 anos. A matemática quase sempre favorece Payload após o mês 14.
- Você já está rodando uma aplicação Next.js ou Node e quer o CMS co-localizado ou pelo menos compartilhando infraestrutura.
É um encaixe ruim quando:
- O cliente precisa que uma pessoa não-técnica configure novos tipos de conteúdo sem suporte de engenharia.
- Você está construindo algo que precisa ser entregue completamente e o destinatário não tem um desenvolvedor no quadro.
- Faltam menos de duas semanas para o lançamento e você não tem um projeto Payload pronto para clonar.
Aprendi esse segundo ponto da forma difícil. Em 2022 fiz o escopo de um pequeno site de caridade com Payload (v1 na época). O plano era passar para o coordenador voluntário deles gerenciar. Três meses depois eu ainda recebia mensagens no WhatsApp perguntando por que o campo não estava aparecendo. O CMS não estava tecnicamente errado para o projeto. Estava errado para o modelo de entrega.
O Custo Real de Rodar Payload em 2026
Esta é a seção que a maioria dos posts ignoram ou disfarçam com faixas vagas. Deixa eu te dar números reais do que rodei.
Infraestrutura
Você precisa de um lugar para hospedar o servidor Node e um lugar para armazenar seu banco de dados. Esses são seus dois custos fixos.
Opção A: Railway Uso Railway para a maioria dos projetos Payload com tráfego médio. Uma app Payload típica (serviço Node + instância Postgres) roda entre $12 e $35/mês dependendo do uso. Para um site de marketing com conteúdo editorial, você quase certamente fica na faixa de $15-20. Deploys são simples a partir de um repositório GitHub, e os backups do Postgres são automáticos.
Opção B: Render Preço similar ao Railway. Free tier existe mas não use para produção (cold starts vão te envergonhar na frente dos clientes). Planos pagos começam em $7/mês para o web service mais $7/mês para o Postgres gerenciado. Então ~$14/mês no mínimo, escalando com CPU e memória conforme o tráfego cresce.
Opção C: VPS auto-gerenciado Se você está rodando múltiplos projetos Payload, um VPS DigitalOcean ou Hetzner começa a ficar atrativo. Um Hetzner CX32 (4 vCPU, 8GB RAM) custa €8,29/mês e consegue rodar três ou quatro instâncias Payload confortavelmente atrás de um proxy Nginx. Rodo uma instância Postgres compartilhada na mesma máquina para clientes menores. Não é para os fracos de coração, mas perfeitamente estável.
Armazenamento de Mídia
Payload não gerencia suas imagens a menos que você configure um adaptador de armazenamento. Os dois que usei em produção:
- AWS S3 + CloudFront para qualquer coisa em larga escala. Orce aproximadamente $5-15/mês para um site de marketing típico.
- Cloudflare R2 como armazenamento compatível com S3 com zero taxas de egresso. Esse é meu padrão agora. Para um site com ~50GB de assets de mídia, estou pagando essencialmente nada em egresso e cerca de $1,50/mês em armazenamento. Use o plugin payload-cloud-storage e aponte para R2.
Tempo do Desenvolvedor (o custo que as pessoas esquecem)
Setup inicial de um projeto Payload, adequadamente estruturado com autenticação, mídia, as collections que seu cliente precisa, e um modelo sensato de controle de acesso: orce 12-20 horas para um desenvolvedor experiente. Isso não é complexidade opcional, é só a natureza de uma CMS code-first. A uma taxa diária de £400-600 (freelancer mid-market de Londres), isso é £4.800-12.000 antes de você ter escrito uma linha de código frontend.
Compare com criar um espaço Contentful e configurar content types via sua UI em 3 horas. O custo inicial é real. O custo contínuo é onde Payload ganha.
Custo Total de Propriedade, Ano 1 vs Ano 3
Aqui está um modelo aproximado para um site de marketing de médio porte, comparando Payload em Railway vs plano Growth do Contentful:
- Payload em Railway, Ano 1: £18/mês infraestrutura + ~£5.000 tempo de setup = ~£5.216 total
- Payload em Railway, Ano 3: £18/mês infraestrutura + manutenção mínima = ~£648 infraestrutura no ano 3
- Contentful Growth plan, Ano 1: £320/mês = £3.840, sem custo de setup customizado
- Contentful Growth plan, Ano 3: £320/mês = £3.840 novamente
O ponto de equilíbrio acontece em torno do mês 20-22 dependendo da sua taxa diária. Depois disso, Payload é substancialmente mais barato. Para um cliente que vai estar rodando o mesmo site em 2028, isso importa.
A Experiência do Desenvolvedor em Termos Honestos
Eu genuinamente gosto de trabalhar com Payload. A abordagem config-as-code significa que seu schema é versionado, revisável em pull requests e deployável como qualquer outra mudança de código. Só isso já coloca à frente de ferramentas CMS onde um content modeller fica clicando em uma GUI e ninguém realmente sabe o que mudou ou quando.
A inferência de TypeScript é excelente. Seus tipos de collection fluem através de suas queries de API local sem nenhuma etapa manual de geração de tipos. A Seahawk tinha um projeto de conteúdo fintech no ano passado onde estávamos consultando dados de relacionamentos profundamente aninhados, e a segurança de tipos capturou dois bugs de formato de dados antes de chegarem ao staging. Isso não é pouca coisa.
A UI do admin é limpa e rápida. Não é chamativa, apenas funcional. Editores não-técnicos geralmente ficam confortáveis com ela em uma ou duas sessões uma vez que os campos estão bem rotulados. Hooks são a outra coisa que quero destacar: before-change, after-read e lifecycle hooks similares deixam você fazer coisas na camada de dados que você teria que construir middleware de API customizado caso contrário.
As Arestas Ásperas
Migrations. Se você estiver no Postgres e mudar seu schema, precisa rodar migrations do Drizzle. Isso é tranquilo se você sabe o que está fazendo e ligeiramente aterrorizante se não sabe. Vi um dev júnior em um subcontrato da Seahawk derrubar uma coluna por não ler o diff da migration com cuidado. Sempre revise, sempre faça backup primeiro.
O ecossistema de plugins é menor que o WordPress, obviamente. Mas o diretório de plugins do Payload cresceu de forma significativa. Form builder, nested docs, campos de SEO, redirects. As bases importantes estão cobertas. Você ainda escreverá mais código customizado do que faria em uma plataforma mais estabelecida.
Como Se Compara com as Outras Opções Headless
Deixe-me ser direto sobre onde eu escolheria algo diferente.
Sanity.io se seu time de conteúdo é grande e editores não-técnicos estão criando suas próprias estruturas de conteúdo. O Studio do Sanity é mais amigável para esse público, o backend hospedado é confiável, e a linguagem de query GROQ é genuinamente agradável de escrever. Você pagará $99+/mês em um plano real, mas para alguns clientes vale a pena.
Strapi foi a alternativa Payload por anos. Ainda é viável e o modelo self-hosted é similar, mas acho a experiência com TypeScript mais complicada e o caminho de upgrade entre versões maiores historicamente foi doloroso. A base de código do Payload parece mais intencional para mim.
WordPress com ACF ou um setup baseado em blocks para qualquer coisa que precisa ser entregue a um mantenedor não-técnico que já está confortável com WordPress. Ainda é a resposta certa para grandes porções do que agências constroem. Não deixe ninguém te convencer do contrário.
Directus como um dark horse que vale a pena olhar, especialmente se você está trabalhando com um schema de banco de dados existente que você precisa envolver com um CMS. Filosofia diferente do Payload mas genuinamente bom nesse trabalho específico.
FAQ
Payload CMS é gratuito para usar?
Sim. Payload é open-source sob a licença MIT. Não há taxa de licença. Você paga pela infraestrutura de hosting própria, que é o tradeoff versus um CMS SaaS hospedado.
Clientes não-técnicos conseguem usar o painel admin do Payload?
Com campos bem rotulados, padrões sensatos e algum treinamento básico, sim. A UI do admin é limpa o suficiente para que editores a aprendam razoavelmente rápido. O que eles não conseguem fazer é criar novas collections ou mudar o schema sem um desenvolvedor. Essa é uma restrição difícil por design.
Payload funciona com Next.js?
Sim, e particularmente bem. Payload 2.x foi reconstruído no Next.js, então você pode rodar o CMS e seu frontend no mesmo app Next.js. Esse setup "monorepo em um único repo" funciona bem para projetos pequenos a médios e reduz sua sobrecarga de infraestrutura.
Qual banco de dados devo usar com Payload?
Para novos projetos em 2026 padrão em PostgreSQL via Drizzle ORM. É bem testado, você obtém restrições relacionais adequadas, e as ferramentas de migration são sólidas quando usadas com cuidado. MongoDB continua sendo uma opção e ainda é um bom ajuste se seus dados são de formato de documento por natureza, mas Postgres é minha primeira recomendação.
Como Payload lida com uploads de mídia?
Por padrão, Payload armazena uploads localmente no filesystem do servidor, o que é okay para desenvolvimento mas não para produção. Para produção você vai querer configurar um storage adapter apontando para S3, Cloudflare R2, ou similar. O pacote oficial @payloadcms/plugin-cloud-storage lida com isso e leva cerca de uma hora para configurar adequadamente na primeira vez.
Payload está pronto para sites de produção em larga escala?
Está rodando tráfego de produção sério em várias empresas. Dito isso, não é o CMS que eu escolheria para um site com 10 milhões de visitantes mensais e um time editorial de 20 pessoas. Nessa escala você estaria procurando por opções de nível empresarial com contratos de suporte dedicado. Para os projetos mid-market construídos por agência que compõem a maior parte do nosso trabalho na Seahawk, Payload é estável e capaz.
O Parecer Honesto
Payload CMS em 2026 é uma ferramenta madura e bem construída para projetos liderados por desenvolvedores onde o custo de longo prazo importa e você tem a capacidade de engenharia para possuir a stack. O investimento inicial em tempo de setup é real. O custo de infraestrutura contínuo é baixo. A experiência do desenvolvedor é boa.
Não é um substituto do WordPress. Não está tentando ser. Mas para o projeto certo, com o time certo, é a opção de headless CMS mais econômica com a qual trabalhei em mais de 12.000 builds. A pergunta não é se é bom. É se é bom para sua situação.