Traduzindo para Português Brasileiro

Tenho enviado sites Next.js desde os dias do Pages Router, e perdi a conta de quantas vezes vi um artigo "melhor CMS" escrito por alguém que claramente instalou a coisa uma vez, seguiu o tutorial de início rápido e chamou de review. Isto não é isso.

Na Social Animal, executamos sites de produção em múltiplas arquiteturas de CMS -- desde Payload CMS alimentando um aplicativo de saúde até Supabase servindo 253.000+ páginas em três plataformas diferentes. Avaliamos Strapi 5, Sanity e Contentful para projetos reais de clientes. E este site que você está lendo? Construído em arquivos MDX confirmados em um repositório Git.

Então quando digo "testamos 6 em produção", quero dizer que lidamos com as dores de cabeça da migração, as surpresas de tempo de compilação, as mensagens do Slack às 3 da manhã sobre conteúdo não publicando. Aqui está tudo o que aprendemos sobre escolher o CMS certo para Next.js App Router em 2026.

Índice

Melhor CMS para Next.js App Router 2026: Testamos 6 em Produção

Por que o App Router Muda a Equação do CMS

Se você ainda está pensando sobre seleção de CMS da maneira como fazia com o Pages Router, está deixando desempenho na mesa. O App Router mudou fundamentalmente como dados fluem através de uma aplicação Next.js, e isso tem implicações diretas para qual CMS se encaixa melhor.

Aqui está o que importa agora:

Componentes do Servidor são o padrão. Sua busca de dados do CMS acontece no servidor sem enviar nenhum JavaScript para o cliente. Isso significa que CMSs com SDKs Node.js nativos ou -- melhor ainda -- APIs locais que pulam a rede inteiramente têm uma vantagem massiva.

React Server Components + cache fetch. O built-in deduplication e caching de fetch do App Router significa que seus padrões de integração de CMS parecem completamente diferentes. Você não está alcançando getStaticProps ou getServerSideProps mais. Você está escrevendo componentes assíncronos que chamam seu CMS diretamente.

Parallel Routes e Intercepting Routes. Estes padrões desbloqueiam layouts conduzidos por CMS que eram dolorosos de construir antes. Um CMS que suporta modelagem de conteúdo flexível (não apenas posts de blog e páginas) brilha aqui.

Partial Prerendering (PPR). A partir do Next.js 15, PPR permite servir um shell estático com buracos dinâmicos. Isso muda o debate ISR vs. SSR inteiramente, e significa que sua estratégia de revalidação de CMS importa mais do que nunca.

Com todo esse contexto, vamos entrar no teste real.

Os 6 CMSs Que Testamos (e Como Testamos)

Nossa avaliação não era teórica. Para cada CMS, enviamos páginas de produção ou fizemos uma avaliação técnica profunda para um projeto real de cliente. Medimos:

  • Experiência de desenvolvedor com App Router especificamente
  • Tempos de compilação em várias contagens de página
  • UX de editor de conteúdo para membros de equipe não-desenvolvedores
  • Preços em escala (não apenas o nível gratuito)
  • Qualidade da integração TypeScript
  • Padrões de revalidação (ISR, on-demand, webhooks)

Vamos passar por cada um.

1. Payload CMS 3 -- Melhor no Geral para Next.js

Nosso veredicto: Melhor experiência de desenvolvedor para Next.js App Router, ponto final.

Payload CMS 3 é aquele que me fez repensar o que um CMS poderia ser. Não é um serviço separado que você chama via HTTP. Ele vive dentro de sua aplicação Next.js. Mesmo repositório, mesma implantação, mesmos tipos TypeScript.

Executamos Payload 3 em produção no SleepDr, uma plataforma de saúde com 228 páginas, controle de acesso multi-nível, e conteúdo que precisa ser preciso (é relacionado à saúde, então conteúdo errado não é apenas uma má aparência -- é uma responsabilidade).

O Que Torna Payload Especial para App Router

A API Local é a característica mais importante. Em vez de fazer requisições HTTP para seu CMS, você importa uma função e a chama diretamente:

// app/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })
  
  const posts = await payload.find({
    collection: 'posts',
    where: {
      slug: { equals: params.slug },
      status: { equals: 'published' },
    },
  })
  
  const post = posts.docs[0]
  if (!post) notFound()
  
  return <Article post={post} />
}

Sem salto de rede. Sem sobrecarga REST ou GraphQL. Sem SDK para instalar. A chamada de função é totalmente tipada porque Payload gera interfaces TypeScript de suas configs de coleção. Quando você refatora um nome de campo, seu IDE detecta cada referência quebrada instantaneamente.

Preview ao Vivo com App Router

A preview ao vivo do Payload 3 funciona com Server Components. Seus editores de conteúdo veem mudanças em tempo real no layout real do site -- não uma aproximação no painel de administração. Configuramos isso para SleepDr e a equipe editorial passou de "preciso de um desenvolvedor para verificar isto" para publicação autossuficiente em uma semana.

Controle de Acesso Que Realmente Funciona

O controle de acesso em nível de campo e coleção do Payload é definido em código:

const Posts: CollectionConfig = {
  slug: 'posts',
  access: {
    read: () => true,
    create: ({ req: { user } }) => user?.role === 'editor' || user?.role === 'admin',
    update: ({ req: { user } }) => user?.role === 'admin',
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    // ...
  ],
}

Para um aplicativo de saúde, essa granularidade não é opcional. É um requisito.

As Desvantagens

Payload roda em sua infraestrutura. Se você quer uma experiência SaaS totalmente gerenciada, Payload Cloud existe (começando em torno de $35/mês para produção), mas você ainda é responsável por compreender a implantação. É também uma dependência de runtime Node.js, o que significa que sua hospedagem precisa suportá-lo (Vercel funciona, mas custos sobem com conexões persistentes ao seu banco de dados).

Para nosso trabalho de desenvolvimento Next.js, Payload 3 é agora nossa recomendação padrão para sites ricos em conteúdo sob 5.000 páginas.

Melhor CMS para Next.js App Router 2026: Testamos 6 em Produção - arquitetura

2. Supabase-as-CMS -- Melhor para Escala (10K+ Páginas)

Nosso veredicto: Não é tecnicamente um CMS, mas nada mais se aproxima para enormes conjuntos de dados estruturados.

Esta é a escolha não convencional, e é aquela que estou mais entusiasmado. Supabase não é comercializado como um CMS. É uma plataforma PostgreSQL com autenticação, armazenamento e Edge Functions. Mas quando seu "conteúdo" é realmente dados estruturados -- perfis de celebridades, listagens de negócios, bancos de dados de produtos -- CMSs tradicionais desabam em escala, e Supabase nem mesmo sente o esforço.

Executamos três sites de produção no Supabase-as-CMS:

  • DA -- 91.000+ páginas de dados de celebridades em 30 idiomas
  • NAS -- 137.000+ listagens de negócios
  • HostList -- 25.000+ listagens de provedores de hospedagem

Isso é 253.000+ páginas. Deixe-me contar o que acontece quando você tenta colocar 91.000 entradas em um CMS headless tradicional: o painel de administração se torna inutilizável, tempos de compilação vão para o infinito, e sua conta vai para as alturas.

A Arquitetura

Não usamos generateStaticParams para 253K páginas. Usamos renderização totalmente dinâmica com caching agressivo:

// app/[locale]/celebrity/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'

export default async function CelebrityPage({ params }: Props) {
  const supabase = await createClient()
  
  const { data: celebrity } = await supabase
    .from('celebrities')
    .select('*, social_profiles(*), net_worth_history(*)')
    .eq('slug', params.slug)
    .eq('locale', params.locale)
    .single()
  
  if (!celebrity) notFound()
  
  return <CelebrityProfile data={celebrity} />
}

export const revalidate = 86400 // Revalidar diariamente

Tempo de compilação? Cerca de 10 segundos. As páginas são renderizadas sob demanda e cacheadas na borda. Quando alguém procura por uma celebridade que não servimos recentemente, a primeira requisição atinge Supabase (tipicamente 20-50ms da borda), renderiza a página, a cachea, e cada visitante subsequente obtém a versão cacheada.

Row-Level Security como Controle de Acesso

As políticas RLS do Supabase substituem o que você normalmente construiria em um painel de administração CMS:

CREATE POLICY "Acesso público de leitura" ON celebrities
  FOR SELECT USING (status = 'published' AND locale = current_setting('app.locale'));

CREATE POLICY "Acesso de atualização de editor" ON celebrities
  FOR UPDATE USING (auth.role() = 'editor');

O Problema da Edição de Conteúdo

Aqui está a desvantagem honesta: O Table Editor do Supabase é legal para desenvolvedores, mas não é uma experiência de edição de conteúdo. Construímos interfaces de administração personalizadas para nossas equipes editoriais usando as bibliotecas de cliente do Supabase. Se você não quer construir sua própria UI de administração, esta abordagem não é para você.

Supabase Pro roda $25/mês, e mesmo em 253K páginas, estamos longe dos limites de computação ou armazenamento. Compare isso com preços de Contentful ou Sanity em escala similar.

Para nossas soluções de desenvolvimento de CMS headless, recomendamos esta abordagem para qualquer projeto acima de 10.000 páginas de conteúdo estruturado.

3. Strapi 5 -- Melhor para Equipes Não-Técnicas

Nosso veredicto: A melhor experiência de modelagem de conteúdo visual, ideal quando seus editores não são desenvolvedores.

Avaliamos Strapi 5 em profundidade para um projeto de cliente e escrevemos uma extensa comparação Payload vs Strapi (que classifica na página 1, então claramente outros estão fazendo as mesmas perguntas). Embora tenhamos acabado escolhendo Payload para esse projeto, Strapi tem um caso de uso claro.

O Content-Type Builder do Strapi 5 permite que membros de equipe não-técnicos criem e modifiquem estruturas de conteúdo através de uma GUI de arrastar e soltar. Sem código. Sem arquivos de config. Sem implantações. Seu gerente de marketing pode adicionar um tipo de conteúdo "testemunhal" com campos para citação, autor, empresa e classificação sem arquivar um ticket Jira.

Integração com App Router

Strapi 5 expõe APIs REST e GraphQL. A integração com App Router é direta, mas requer requisições de rede:

// lib/strapi.ts
export async function getArticles() {
  const res = await fetch(
    `${process.env.STRAPI_URL}/api/articles?populate=*`,
    {
      headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` },
      next: { revalidate: 60 },
    }
  )
  return res.json()
}

Funciona. Mas comparado à API Local do Payload, você sente a incompatibilidade de impedância. Você está serializando e desserializando dados que poderiam ter permanecido no processo. Os tipos TypeScript precisam ser gerados separadamente (Strapi tem um CLI para isto, e melhorou na v5).

Preços do Strapi 5 (2026)

Plano Preço Assentos Ativos
Community Grátis (auto-hospedado) Ilimitados Ilimitados
Team $29/mês/assento 5-20 100GB
Business $99/mês/assento Customizado 500GB
Enterprise Customizado Customizado Customizado

Auto-hospedagem de Strapi é genuinamente grátis e funciona bem. Os planos Cloud adicionam hospedagem gerenciada e suporte premium.

4. Sanity -- Melhor para Colaboração em Tempo Real

Nosso veredicto: Melhor experiência de edição em tempo real, mas GROQ é um compromisso amor-ou-ódio.

Avaliamos Sanity seriamente para o projeto DA (91K páginas de celebridades) antes de ir com Supabase. Sanity Studio é genuinamente impressionante -- é uma aplicação React que você pode customizar até o nível do campo. Colaboração em tempo real funciona impecavelmente. Dois editores podem trabalhar no mesmo documento simultaneamente, estilo Google Docs.

GROQ: Poderoso mas Polarizador

Sanity usa GROQ, sua própria linguagem de consulta:

*[_type == "article" && slug.current == $slug][0] {
  title,
  body,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  publishedAt
}

GROQ é realmente elegante uma vez que você aprende. A sintaxe de projeção (->) para resolver referências é mais legal que GraphQL para muitos casos de uso. Mas é outra linguagem de consulta que sua equipe precisa aprender e manter. E quando você bate em casos extremos, a documentação pode parecer fina.

Por Que Não Escolhemos Sanity para DA

Com 91.000 documentos, o preço do Sanity se torna significativo. O plano Growth ($15/usuário/mês) inclui 1M requisições CDN de API. Parece um monte até você perceber que um site com 91K páginas gerando tráfego decente consome isso rapidamente. Estimamos que nossa conta mensal do Sanity seria $300-500/mês apenas para DA. Supabase Pro em $25/mês foi uma escolha óbvia.

Sanity é excelente para sites com 50-5.000 itens de conteúdo onde vários editores precisam colaborar. Equipes editoriais em empresas de mídia a adoram.

5. Contentful -- Melhor para Empresa (Com Orçamento)

Nosso veredicto: O CMS headless mais maduro, mas você pagará pela maturidade.

Contentful existe desde 2013. É o CMS headless ao qual equipes enterprise usam como padrão, e há uma razão: a modelagem de conteúdo é excelente, a API é sólida como uma rocha (SLA 99.99% no Premium), e o ecossistema de integrações é inigualável.

Avaliamos Contentful para múltiplos projetos de cliente enterprise. O construtor de modelo de conteúdo é polido, o explorador de API no app web é genuinamente útil para debug, e o sistema de webhooks se integra limpo com revalidação on-demand do Next.js.

A Etiqueta de Preço

Plano Preço (2026) Tipos de Conteúdo Locales Chamadas de API
Free $0 48 2 1M/mês
Basic $300/mês 48 6 2M/mês
Premium Customizado (tipicamente $3.000+/mês) Ilimitados Ilimitados Customizado

O salto de Free para Basic é acentuado. O salto de Basic para Premium é um precipício. Se você for uma empresa com orçamento SaaS de $50K+/ano, Contentful é uma aposta segura. Se você for uma startup tentando manter a taxa de queima baixa, veja outro lugar.

Integração com App Router

O JavaScript SDK do Contentful funciona bem com Server Components:

import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!,
})

export async function getPage(slug: string) {
  const entries = await client.getEntries({
    content_type: 'page',
    'fields.slug': slug,
    include: 3,
  })
  return entries.items[0]
}

O SDK é bem mantido e totalmente tipado com contentful-typescript-codegen. Sem reclamações na frente da DX.

6. Markdown/MDX -- Melhor para Blogs de Desenvolvedores

Nosso veredicto: Zero overhead, controle máximo, fluxos de trabalho nativos do Git.

Este site -- socialanimal.dev -- roda em MDX. Cada artigo é um arquivo no repositório com metadados de frontmatter:

---
title: "Melhor CMS para Next.js App Router 2026"
slug: "best-cms-nextjs-app-router-2026"
category: "Resources"
tags: ["nextjs", "cms", "payload", "supabase"]
publishedAt: "2026-01-15"
---

Tenho enviado sites Next.js desde os dias do Pages Router...

Com @next/mdx ou contentlayer2 (o fork da comunidade), MDX se integra nativamente com o App Router. Seu conteúdo É seu codebase. Controle de versão, branching, revisões de pull request -- todos os fluxos de trabalho que você já conhece.

Quando MDX Falha

Não-desenvolvedores não podem usá-lo. Período. Se sua equipe de marketing precisa publicar posts de blog, MDX significa que eles estão aprendendo Git ou você está construindo uma interface de edição para eles (ponto em que, apenas use Payload).

MDX também não escala para milhares de páginas bem. Em torno de 500+ arquivos MDX, tempos de compilação começam a arrastar e seu IDE fica lento. Para um blog da empresa ou site de documentação, é perfeito. Para uma plataforma de conteúdo, não é.

Para nosso trabalho de desenvolvimento Astro, usamos MDX ainda mais extensivamente já que as coleções de conteúdo do Astro fornecem excelente segurança de tipo para conteúdo Markdown/MDX.

Comparação de Métricas de Produção

Aqui estão os dados de nossas implantações reais de produção e avaliações:

CMS Páginas em Produção Idiomas Tempo de Compilação Custo Mensal Nosso Veredicto
Payload 3 228 (SleepDr) 1 ~45s $35 (Payload Cloud) Melhor DX para Next.js
Supabase 253K (DA+NAS+HostList) 30 ~10s $25 (plano Pro) Melhor para escala
Strapi 5 0 (avaliado) N/A N/A Grátis (auto-hospedado) Melhor para editores GUI
Sanity 0 (avaliado) N/A N/A ~$300-500 est. Melhor para colaboração
Contentful 0 (avaliado) N/A N/A $300+ (Basic) Melhor para empresa
MDX ~60 (este site) 1 ~30s $0 Melhor para blogs dev

A coluna de tempo de compilação merece explicação. Payload em 45 segundos inclui gerar 228 páginas estáticas. Supabase em 10 segundos é porque não geramos estaticamente 253K páginas -- usamos renderização dinâmica com ISR. MDX em 30 segundos é para ~60 artigos com destaque de sintaxe e otimização de imagem.

Framework de Decisão: Como Escolher Seu CMS

Esqueça listas de recursos. Responda estas quatro perguntas:

1. Quem está editando conteúdo?

  • Apenas desenvolvedores → MDX ou Payload
  • Desenvolvedores + editores técnicos → Payload ou Sanity
  • Equipe de marketing não-técnica → Strapi ou Contentful

2. Quantas páginas?

  • Sob 500 → Qualquer CMS funciona. Escolha com base na UX do editor.
  • 500-5.000 → Payload ou Sanity. Ambos lidam bem com este intervalo.
  • 5.000-50.000 → Supabase ou Contentful (com orçamento).
  • 50.000+ → Supabase. Nada mais faz sentido economicamente.

3. Qual é seu orçamento mensal de CMS?

  • $0 → Payload auto-hospedado, Strapi auto-hospedado, ou MDX
  • $25-50 → Supabase Pro ou Payload Cloud
  • $100-500 → Sanity Growth ou Strapi Cloud
  • $500+ → Contentful ou Sanity Enterprise

4. Você precisa de colaboração em tempo real?

  • Sim, crítico → Sanity (melhor da classe)
  • Bom ter → Payload (live preview é próximo)
  • Não me importo → Qualquer outra coisa

O Que Faríamos Diferente

Previsão é valiosa. Aqui está o que mudássemos:

Começássemos com Payload mais cedo. Construímos alguns projetos iniciais com painéis de administração customizados em cima de Supabase antes do Payload 3 amadurecer. Para sites sob 5K páginas, Payload teria economizado tempo significativo de desenvolvimento de UI de administração.

Padronizássemos nossos padrões Supabase-as-CMS mais cedo. Cada um de nossos três projetos Supabase tem convenções ligeiramente diferentes para modelagem de conteúdo, caching e revalidação. Desde então criamos um template interno que usamos para todos os novos projetos de alto volume.

Pulássemos a avaliação Contentful para clientes não-enterprise. O precipício de preço é real, e duas vezes passamos por avaliações de várias semanas apenas para perceber que o orçamento do cliente não correspondia ao preço do Contentful. Deveríamos ter perguntado sobre orçamento primeiro.

Se você está enfrentando uma decisão de CMS similar para um projeto Next.js, estamos felizes em compartilhar mais detalhes sobre nossa experiência. Confira nossa página de preços ou entre em contato direto -- fazemos isso todos os dias.

FAQ

Qual é o melhor CMS headless para Next.js em 2026?

Baseado em nossa experiência de produção em 253K+ páginas, Payload CMS 3 é a melhor escolha geral para Next.js App Router. Sua API Local elimina sobrecarga de rede, tipos TypeScript são gerados automaticamente, e o painel de administração vive dentro de seu aplicativo Next.js. Para sites excedendo 10.000 páginas, recomendamos Supabase como uma camada de CMS com uma interface de administração customizada.

Payload CMS é realmente grátis?

Payload CMS é open-source e grátis para auto-hospedagem sem restrições de recurso. Você precisará fornecer sua própria hospedagem e banco de dados (MongoDB ou PostgreSQL). Payload Cloud, seu serviço de hospedagem gerenciada, começa em aproximadamente $35/mês para cargas de trabalho de produção em 2026. Não há cobranças por assento na versão auto-hospedada.

Posso usar Supabase como CMS para Next.js?

Sim, e fazemos em escala. Executamos três sites de produção totalizando 253.000+ páginas no Supabase. Funciona excepcionalmente bem quando seu conteúdo são dados estruturados (perfis, listagens, catálogos de produtos) em vez de conteúdo editorial de longa forma. O principal tradeoff é que você precisará construir sua própria interface de edição de conteúdo -- o Table Editor do Supabase não é projetado para fluxos de trabalho editoriais.

Como Strapi 5 se compara a Payload CMS 3 para Next.js?

Strapi 5 se destaca em edição de conteúdo não-técnica com seu Content-Type Builder visual. Payload 3 se destaca em experiência de desenvolvedor com sua API Local e abordagem nativa de TypeScript. Se seus editores forem desenvolvedores, escolha Payload. Se seus editores forem marketers, escolha Strapi. Escrevemos uma comparação detalhada Payload vs Strapi cobrindo este tópico em profundidade.

Qual é o CMS headless mais barato para Next.js?

Payload CMS auto-hospedado e Strapi auto-hospedado são ambos genuinamente grátis. Arquivos MDX em um repositório Git custam nada além de sua hospedagem. Para serviços gerenciados, Supabase Pro em $25/mês oferece o melhor valor em escala -- servimos 253K páginas em um único plano Pro. O nível gratuito do Sanity também é generoso para pequenos projetos (até 3 usuários, 500K requisições de API/mês).

Contentful vale a pena o preço para projetos Next.js?

Contentful vale a pena se você for uma equipe enterprise que precisa de SLA 99.99%, integrações estabelecidas com ferramentas como Commercetools ou Salesforce, e você tem o orçamento ($300+/mês para Basic, $3.000+/mês para Premium). Para startups e empresas de médio porte, Payload ou Sanity entregam funcionalidade comparável por uma fração do custo.

Devo usar ISR ou SSR com um CMS headless em Next.js App Router?

Depende de sua contagem de páginas e frequência de atualização de conteúdo. Para sites sob 5.000 páginas, geração estática com revalidação on-demand via webhooks é ideal. Para 5.000+ páginas, renderização dinâmica com ISR (revalidate = 3600 ou similar) é mais prático -- você não pode construir 50K páginas em cada implantação. Com a API Local do Payload, a distinção importa menos porque não há sobrecarga de rede de qualquer forma.

Posso migrar de WordPress para um CMS headless para Next.js?

Absolutamente. Fizemos múltiplas migrações WordPress. O caminho típico é: exportar conteúdo WordPress via API REST ou WP-CLI, transformar e importar para seu CMS alvo, depois reconstruir o frontend em Next.js. Payload CMS torna isso especialmente suave porque você pode modelar suas coleções para corresponder aos seus tipos de post existentes no WordPress. Para mais detalhes sobre este processo, veja nossas soluções de desenvolvimento de CMS headless.