# Strapi, Directus ou Payload: CMS headless self-hosted em 2026

**Autor:** Maicon Ramos
**Categoria:** Ferramentas Dev
**Publicado:** 2026-09-14
**Atualizado:** 2026-09-14
**Canonical:** https://runzos.com/strapi-directus-payload-cms-vps-2026

Para uma aplicação em Next.js e TypeScript, Payload tende a encaixar melhor. Directus faz mais sentido quando o banco SQL existente é central. Strapi atende quem prefere um CMS Node separado. Em qualquer escolha, VPS exige cuidar de banco, mídia, segredos, atualizações e restauração; ela não entrega operação gerenciada completa. Se o seu app já usa Next.js e TypeScript, escolha Payload. Se o banco SQL existente é o centro do projeto, escolha Directus. Se você quer um CMS Node separado, escolha Strapi. A ressalva é igual para os três: uma VPS não elimina banco, arquivos, segredos, atualização e recuperação. Ela só torna essas responsabilidades suas. Comparativo rápido: qual CMS encaixa na sua arquitetura? Critério Strapi Directus Payload Melhor ponto de partida Um CMS Node separado da aplicação. Um banco SQL que já existe e precisa de painel e APIs. Um produto em Next.js e TypeScript. Onde fica o centro da arquitetura Projeto Strapi mais banco relacional. Banco SQL existente, com Directus como camada operacional. Repositório Next.js e configuração TypeScript. Deploy e operação Build do admin, segredos e credenciais disponíveis no processo. Container e componentes de infraestrutura definidos pelo operador. App, banco, storage permanente, e-mail e, em muitos projetos, CDN. Banco e mídia MySQL, MariaDB, PostgreSQL ou SQLite; não suporta MongoDB. Trabalha sobre banco SQL; cache e backup seguem sendo decisões de produção. Uploads no servidor ou adaptadores de storage compatível com S3. Licença a conferir Community Edition fora de ee/ sob MIT; componentes ee/ têm licença distinta. Em 14/09/2026, o repositório declara MSCL 1.0 com restrição de uso concorrente. MIT no arquivo de licença do repositório. Quando evitar Quando não há quem mantenha o serviço Node e seu deploy. Quando a licença não foi validada para o seu modelo de redistribuição ou hosting. Quando o produto não quer adotar a fronteira técnica de um projeto Next.js. A tabela não mede desempenho. Não há benchmark controlado, com a mesma VPS e a mesma carga, que permita declarar um vencedor de RAM, latência ou throughput. Ela organiza as diferenças documentadas de arquitetura e operação. A escolha mais útil: onde mora a verdade do seu conteúdo? O erro comum é comparar telas de admin. O painel importa, mas não define sozinho a manutenção. A pergunta mais útil é: onde seu projeto guarda a verdade operacional do conteúdo? Para tornar essa pergunta repetível, vamos usar um conceito: Fronteira da Verdade. É o lugar onde mudanças de conteúdo, esquema, permissões e deploy se encontram. Escolha o CMS cuja fronteira já combina com a forma como sua equipe trabalha. No Payload, essa fronteira tende a ficar no repositório. A documentação descreve uma base TypeScript que gera painel, banco com migrações, APIs REST e GraphQL, autenticação, controle de acesso, file storage e preview. Isso faz sentido quando o CMS é parte do produto Next.js, não uma ferramenta separada para ser administrada à distância. No Directus, a fronteira tende a ser o banco. O próprio repositório o descreve como um backend flexível que transforma um banco em CMS headless, painel admin ou app com interface personalizada, APIs e autenticação. É uma diferença importante para quem já tem PostgreSQL, MySQL ou outro banco SQL como ativo central. No Strapi, a fronteira costuma estar no serviço CMS Node mais seu banco relacional. É a alternativa mais natural quando você quer manter o CMS desacoplado do frontend. A documentação de deploy também deixa claro que segredos da aplicação e credenciais do banco precisam estar disponíveis no build e no servidor. A leitura do Runzos é direta: não escolha pelo painel mais agradável em uma demo. Escolha pelo lugar onde seu time já sabe alterar, versionar e recuperar mudanças. Essa decisão reduz uma migração futura que começa pequena e termina em schema, permissões, integrações e dados editoriais. Para quem o Payload CMS é a melhor escolha Payload é a recomendação principal para o solo builder que já constrói o produto em Next.js e TypeScript. Nesse cenário, manter CMS, schema, migrações, API e preview na mesma base de código reduz a troca de contexto entre dois projetos distintos. A documentação do Payload apresenta painel administrativo, APIs REST e GraphQL, autenticação, controle de acesso, migrações, armazenamento de arquivos e live preview como componentes gerados a partir da configuração. Em produção, ela orienta avaliar banco, storage permanente e Docker. Também avisa que a maioria dos projetos precisa de banco, file storage, provedor de e-mail e CDN. Isso não significa que Payload “só funciona” com Next.js. A formulação segura é outra: ele se posiciona como framework full-stack Next.js. Portanto, ele encaixa melhor quando o projeto aceita essa fronteira técnica. Se você quer apenas plugar um painel em um banco legado, Directus normalmente começa mais alinhado. Para mídia, Payload suporta upload no servidor e oferece adaptadores para storage S3. Serviços compatíveis com a API S3, como Cloudflare R2 segundo sua documentação, entram como opção de storage externo. Arquivo local pode servir no começo, mas ele vira parte do plano de recuperação. Consulte o guia de deploy do Payload antes de decidir o desenho. E, se o banco for um componente do seu produto, vale comparar a camada de dados com este guia sobre banco de dados gerenciado. Para quem o Directus é a melhor escolha Directus é a escolha mais coerente quando seu banco SQL já é a fonte principal dos dados. Em vez de redesenhar o sistema em torno do CMS, você coloca uma camada de admin, API e autenticação sobre uma estrutura que o projeto já conhece. A documentação de self-hosting informa que Directus é distribuído como imagem Docker. Ela também lista compute, database, Redis cache, CDN, load balancers, sistema de backup, monitoramento e tempo de manutenção como considerações de produção. Nem todos esses componentes serão necessários no primeiro deploy. Ainda assim, a lista é um antídoto contra a ideia de que self-hosted é “subir um container e esquecer”. O ganho de Directus é preservar a centralidade do banco. Isso ajuda quando há integrações, dados de negócio ou uma equipe acostumada a trabalhar diretamente no SQL. O custo é operacional: você ainda precisa definir quem cuida de backup, atualização, segredos e observabilidade. Antes de embutir Directus em um produto redistribuído, confira a licença. Em 14 de setembro de 2026, o arquivo de licença do Directus declara Monospace Sustainable Core License 1.0 e define “Competing Use” como disponibilizar software que concorra com a oferta comercial do licenciante. Isso não é parecer jurídico. É um sinal para validar o caso com cuidado, sobretudo em hosting, revenda ou plataforma concorrente. Para quem o Strapi é a melhor escolha Strapi continua uma opção madura para quem quer um CMS Node separado, com projeto, admin e ecossistema próprios. É útil quando o frontend não deve carregar a responsabilidade do CMS no mesmo repositório, ou quando o time quer tratar o serviço editorial como uma aplicação independente. Segundo a documentação de deploy do Strapi, a recomendação de produção é 2 ou mais cores, 4 GB ou mais de memória e 32 GB ou mais de disco. O mínimo listado é 1 core, 2 GB e 8 GB. Trate esses números como orientação do fornecedor, não como benchmark universal ou tamanho garantido para qualquer projeto. A mesma documentação lista MySQL, MariaDB, PostgreSQL e SQLite como bancos suportados. Ela declara que MongoDB, outros bancos NoSQL e bancos “cloud native” como Amazon Aurora e Google Cloud SQL não são suportados. Se seu banco atual foge dessa lista, não parta da suposição de compatibilidade. Há outro detalhe prático: o painel admin é um bundle estático. Quando código ou configuração do admin mudam, ele precisa ser reconstruído. Segredos e credenciais do banco também precisam estar disponíveis no build e no servidor. Para um solo builder, isso não é motivo para descartar Strapi. É motivo para incluir build, variáveis e rollback na rotina de deploy. O custo que fica depois do deploy Uma VPS entrega controle. Ela não entrega uma operação pronta. Directus explicita backup e monitoramento entre os componentes de self-hosting. Payload pede banco, storage permanente, e-mail e CDN em muitos projetos. Strapi exige atenção a build e segredos. O ponto em comum é simples: o estado do CMS está distribuído. O que recuperar Por que entra no plano Ação mínima Banco Guarda conteúdo, estrutura e, conforme a stack, permissões e dados de aplicação. Fazer cópia externa e testar a restauração. Uploads e mídia Arquivo no volume local ou object storage não reaparece ao restaurar apenas o banco. Inventariar onde os arquivos ficam e copiar esse destino. Segredos e configuração Credenciais, chaves e variáveis participam do build e da execução. Manter inventário protegido, separado do backup público. Versão da aplicação Uma atualização pode exigir retorno à versão compatível com dados e configuração. Registrar imagem, commit ou versão que foi implantada. SMTP, CDN e integrações E-mail, entrega de mídia e serviços externos podem falhar mesmo com o CMS de pé. Documentar dependências e validar após o restore. Teste de restore Backup sem restauração comprovada não demonstra recuperação. Restaurar em ambiente isolado antes de depender dele. Esse é o critério que muitos comparativos deixam raso. Uma instalação via Docker pode funcionar hoje e ainda ser difícil de recuperar depois de uma perda de volume, mudança de credencial ou atualização. A síntese estratégica do Runzos é objetiva: a opção certa é a que cabe no processo de recuperação que você realmente conseguirá executar. Para deploy, a mesma lógica vale para aplicações Node e Next.js. Se esse é o seu cenário, veja também o comparativo de deploy de aplicações Node e Next.js. Ele ajuda a separar escolha de CMS de escolha de plataforma de execução. Licença e lock-in não são detalhe de rodapé É incorreto colocar Strapi, Directus e Payload na mesma caixa de “open source MIT”. Payload está sob MIT no arquivo oficial de licença. A Community Edition do Strapi, fora de diretórios ee/ e sem conta cloud, também é fornecida sob MIT Expat, enquanto componentes em ee/ seguem outra licença. Directus exige uma leitura datada e específica. O arquivo atual consultado em 14/09/2026 declara MSCL 1.0. Para usar um CMS internamente, isso pode ter um impacto diferente de redistribuir, revender ou oferecer um serviço concorrente. Não reduza a decisão a uma etiqueta. Leia o arquivo atual e, se o modelo de negócio depender dessa liberdade, busque orientação jurídica. Lock-in também não é só API. Os três expõem APIs HTTP e podem compor com object storage. Isso ajuda o frontend a consumir dados. O atrito de saída mora no modelo de dados, extensões, permissões, migrações e runtime. Para arquitetar essa saída desde cedo, este conteúdo sobre evitar lock-in de plataforma traz uma discussão complementar. Quando não vale auto-hospedar Não vale auto-hospedar quando ninguém tem dono para atualização, cópia externa, teste de restauração e resposta a falhas. Nesse caso, WordPress ou Ghost gerenciado, ou um CMS cloud, pode ter custo mensal mais explícito, mas reduzir o risco operacional. Também não vale começar por VPS só porque a licença do software não cobra mensalidade. Software sem mensalidade de licença continua exigindo compute, banco, armazenamento, e-mail, CDN em alguns cenários e tempo de manutenção. A economia aparente desaparece quando a pessoa responsável não consegue operar a pilha. Isso não diminui os três CMS. Só delimita o caso de uso. Auto-hospedagem faz sentido quando controle de dados, API, integração ou custo recorrente justificam uma rotina operacional que o time aceita possuir. Quando uma VPS do Runzos faz sentido A VPS entra depois da arquitetura, não antes. Se você escolheu Strapi, Directus ou Payload e tem responsabilidade clara por deploy, backup e restore, infraestrutura própria pode ser o próximo passo lógico. O ponto de partida é conferir a VPS e hospedagem recomendada pelo Runzos. A página concentra a rota comercial correta e evita promessas de preço, cupom, SLA ou capacidade que podem mudar. Para o CMS, dimensionamento deve seguir a documentação do produto, sua carga real e os componentes que você decidiu operar. FAQ Qual é melhor: Strapi, Directus ou Payload? Payload é melhor para produto em Next.js e TypeScript. Directus é melhor quando o banco SQL existente é o ativo central. Strapi é melhor para um CMS Node separado. A decisão não é por ranking absoluto, e sim por fronteira arquitetural e capacidade de operação. Payload CMS só funciona com Next.js? A documentação o apresenta como framework full-stack Next.js. Por isso, ele é mais coerente nesse tipo de projeto. Antes de adotar, valide se essa fronteira de stack combina com o seu produto e deploy. Directus pode usar um banco que eu já tenho? O repositório oficial descreve Directus como uma camada que transforma um banco em CMS, painel admin ou app com APIs e autenticação. Essa é justamente a proposta que o diferencia. Ainda assim, avalie permissões, modelo de dados e operação antes de colocar um banco de produção atrás de um novo painel. Strapi suporta MongoDB? Não. A documentação de deploy do Strapi declara que MongoDB, outros bancos NoSQL e bancos “cloud native” como Amazon Aurora e Google Cloud SQL não são suportados. Onde ficam os uploads de um CMS self-hosted? Depende da configuração. No Payload, uploads podem ficar no servidor ou em storage compatível com S3 por meio de adaptadores. Em qualquer CMS, trate arquivos como parte separada do plano de backup e restore. O que preciso fazer backup em um CMS headless? No mínimo, banco, uploads, segredos e configuração, versão da aplicação e dependências externas como SMTP e CDN. O passo que fecha o plano é testar o restore em ambiente isolado. Directus continua open source para qualquer uso? A licença deve ser verificada no momento da decisão. Em 14/09/2026, o arquivo do repositório declara MSCL 1.0 e inclui restrição ligada a “Competing Use”. Para redistribuição, revenda ou produto concorrente, não trate isso como equivalente a MIT. Quando não vale auto-hospedar um CMS? Quando não existe uma pessoa responsável por atualizações, backup externo e restauração testada. Um serviço gerenciado pode ser mais adequado se o objetivo é publicar e vender sem assumir a operação de infraestrutura. Veredito final: escolha a arquitetura que você consegue manter Para Rafael, a resposta não é “os três são bons”. Payload é a melhor recomendação quando Next.js e TypeScript já são a base do produto. Directus vence quando o banco SQL existente precisa continuar sendo o centro. Strapi atende bem a quem quer um CMS Node independente e aceita cuidar do build do admin, segredos e banco. A escolha final deve passar por uma pergunta operacional: se a VPS, o volume ou uma credencial falhar amanhã, você sabe restaurar conteúdo, mídia e configuração? Se a resposta ainda é não, comece pelo processo de recuperação. Depois, veja a VPS e hospedagem recomendada pelo Runzos para colocar a arquitetura escolhida em produção.

## Leia também

- [Como Rodar Claude Code e Hermes Agent na Hostinger em 2026](https://runzos.com/como-rodar-claude-code-hermes-agent-hostinger-2026/)
- [Docker no VPS: Guia Passo a Passo para Iniciantes em 2026](https://runzos.com/docker-no-vps-guia-passos-iniciantes-2026/)
- [n8n vs Make 2026: Qual a Melhor Plataforma de Automação no Brasil?](https://runzos.com/n8n-vs-make-2026/)
- [VPS Barato no Brasil: 5 Opções para n8n, Coolify e WordPress](https://runzos.com/vps-brasil-barato-2026/)