VPS para Strapi e headless CMS no Brasil

Resposta direta

Para hospedar Strapi, Directus ou outro headless CMS em uma VPS no Brasil, o ponto de partida seguro costuma ser 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe e PostgreSQL em instância separada ou bem isolada no mesmo servidor. Projetos pequenos podem funcionar com 2 GB de RAM, mas o painel administrativo, builds do Node.js, uploads de mídia e consultas ao banco deixam pouca margem. A localização do servidor deve acompanhar o público principal: Brasil para menor latência local, Miami quando o custo ou a disponibilidade forem mais favoráveis, e regiões nos EUA ou Europa apenas quando a audiência for distribuída. Para produção, backup testado, firewall, TLS, monitoramento e estratégia de deploy são tão importantes quanto CPU e RAM.

Resumo rápido

• Para Strapi em produção básica, pense em 2 vCPUs, 4 GB de RAM e 60 GB de disco SSD como base mais confortável.
• PostgreSQL é uma escolha comum para Strapi e Directus, mas precisa de backup próprio, tuning simples e monitoramento de conexões.
• Docker Compose facilita deploy, rollback e padronização, desde que volumes persistentes e variáveis de ambiente sejam tratados com cuidado.
• Uploads locais funcionam em projetos pequenos, mas object storage costuma ser melhor para sites com muitas imagens, vídeos ou múltiplas réplicas.
• Datacenter no Brasil reduz latência para editores, APIs e usuários locais, embora disponibilidade, custo e suporte variem por provedor.
• NVMe ajuda em banco de dados e builds com muito I/O, mas não compensa aplicação mal configurada, cache ausente ou queries lentas.
• LetsCloud, DigitalOcean, Vultr, Linode, AWS Lightsail, Locaweb e Hostinger podem entrar na avaliação, sempre com recursos, regiões e preços verificados na página oficial antes da publicação.

O que muda ao hospedar Strapi e headless CMS em VPS

Hospedar um headless CMS em VPS é diferente de subir um site estático ou uma instalação simples de WordPress. Strapi, Directus, Payload CMS e plataformas parecidas combinam API, painel administrativo, autenticação, permissões, banco de dados, processamento de uploads e, em muitos casos, integrações com front-ends em Next.js, Nuxt, Astro ou aplicativos móveis. Essa combinação muda a forma de escolher servidor, porque o gargalo pode estar no Node.js, no PostgreSQL, no disco, na rede ou até no fluxo editorial.

Strapi, por exemplo, roda sobre Node.js e costuma usar PostgreSQL, MySQL, MariaDB ou SQLite em desenvolvimento. Em produção, SQLite raramente é a melhor escolha, principalmente quando há equipe editando conteúdo, integrações externas e necessidade de backup confiável. Directus também exige atenção ao banco, já que muitas operações passam por permissões, filtros e relações entre coleções. Se você já está comparando ambientes para aplicações Node, o guia de VPS para Node.js no Brasil ajuda a entender o comportamento de processos, PM2, memória e reverse proxy antes de entrar nos detalhes do CMS.

A distinção entre VPS tradicional, Cloud Server e cloud instance também pesa. Uma VPS tradicional costuma ser uma fatia virtualizada de um servidor físico, com recursos alocados em planos fixos. Um Cloud Server normalmente oferece provisionamento mais flexível, painel com snapshots, rede privada, imagens prontas e upgrade com menos atrito, embora cada provedor use esses termos de forma própria. Já uma cloud instance em provedores globais pode trazer mais regiões, APIs maduras e serviços anexos, mas também aumenta a complexidade de billing, rede e permissões.

Na prática, o melhor servidor para Strapi não é o que tem o maior número no plano, e sim o que combina previsibilidade, armazenamento adequado, latência aceitável e rotina operacional clara. Um CMS usado por três editores e um front-end estático precisa de menos recursos que uma API com milhares de requisições por minuto, webhooks, busca, autenticação e uploads pesados. Antes de escolher provedor, defina o padrão de uso: quantos editores acessam o painel, quantas requisições a API recebe, onde ficam as mídias, como o banco será protegido e qual é o tempo aceitável de indisponibilidade.

CPU, RAM e processos: como dimensionar o servidor

CPU e RAM são os dois números mais visíveis em qualquer plano de VPS, mas em Strapi eles precisam ser lidos junto com o modelo de execução do Node.js. Uma aplicação Strapi típica roda como processo persistente, recebe requisições HTTP, conversa com o banco, valida permissões, processa uploads e carrega plugins. Durante builds, atualizações e instalação de dependências, o consumo pode subir bastante. Por isso, um plano que parece suficiente em repouso pode sofrer em deploy ou em pico editorial.

Para desenvolvimento, staging ou MVP com poucos acessos, 1 vCPU e 2 GB de RAM podem funcionar, especialmente se o banco estiver em outro serviço e os uploads forem pequenos. Ainda assim, essa configuração fica apertada quando npm install, build de admin panel, PostgreSQL e Nginx rodam no mesmo servidor. Em produção básica, 2 vCPUs e 4 GB de RAM são uma base mais realista. Isso permite reservar memória para Node.js, banco, cache de sistema, Nginx e processos auxiliares sem depender de swap o tempo todo.

Um exemplo prático: um Strapi com 20 coleções, 5 editores, front-end em Next.js hospedado separadamente e tráfego de 10 mil visitas por dia pode começar em 2 vCPUs, 4 GB de RAM e PostgreSQL no mesmo servidor, desde que exista cache no front-end e consultas bem feitas. Se o banco crescer para milhões de registros ou se a API virar ponto central de um aplicativo, o desenho muda. Nesse ponto, 4 vCPUs, 8 GB de RAM e banco separado passam a fazer mais sentido.

A RAM merece atenção especial. Node.js pode ser limitado por variável como NODE_OPTIONS=--max-old-space-size=1024, mas limitar demais causa falhas em operações pesadas. PostgreSQL também usa memória para buffers, conexões e ordenações. Se cada editor abre o painel, faz busca em coleções grandes e dispara uploads, o servidor precisa absorver picos curtos. Uma configuração com 4 GB de RAM aguenta melhor essas variações que um plano mínimo de 2 GB.

CPU entra forte em três momentos: build do painel admin, serialização de respostas e processamento de uploads ou plugins. Se você usa imagens grandes, webhooks frequentes, integrações com e-commerce ou autenticação por API, considere pelo menos 2 vCPUs dedicadas ao workload principal. Em VPS compartilhada por muitos serviços, isolar Strapi, banco e filas ajuda a descobrir onde está o gargalo antes de simplesmente aumentar o plano.

Banco de dados, disco e armazenamento de mídia

O banco de dados é o coração operacional de um headless CMS. Strapi e Directus podem parecer aplicações de painel, mas quase toda ação relevante passa por consultas, relações, permissões, histórico de conteúdo e metadados. PostgreSQL costuma ser uma opção sólida para projetos em produção por causa de recursos transacionais, índices, tipos de dados, extensões e boa previsibilidade. Se o projeto vai crescer, vale estudar desde cedo o desenho de tabelas, índices e backups. O conteúdo sobre VPS para banco PostgreSQL aprofunda dimensionamento, memória, disco e boas práticas para bancos em servidor próprio.

Rodar aplicação e PostgreSQL na mesma VPS é aceitável em MVPs e projetos pequenos, mas exige disciplina. Um exemplo razoável seria 2 vCPUs, 4 GB de RAM, 80 GB de SSD, shared_buffers moderado, backups diários e retenção externa. Para produção com tráfego e equipe editorial, separar banco e aplicação reduz risco. Se o Node.js consumir memória demais ou se uma atualização quebrar o serviço, o banco continua mais protegido. Em provedores que oferecem rede privada, a comunicação entre app e banco pode ficar isolada da internet pública.

O disco também merece uma leitura menos superficial. SSD e NVMe melhoram latência de leitura e escrita, mas o impacto real depende de IOPS, concorrência, cache do sistema e volume de dados. Um Strapi com uploads locais, miniaturas e banco no mesmo volume pode crescer rápido. Cem imagens de 5 MB parecem pouco, mas 20 mil arquivos, versões otimizadas e backups locais podem ocupar dezenas ou centenas de gigabytes. Para esse cenário, 60 GB é ponto de partida, 100 GB traz folga e object storage reduz pressão sobre o servidor.

Uploads locais são simples: o arquivo entra pelo painel, fica em uma pasta persistente e é servido por Nginx ou pela própria aplicação. Essa abordagem funciona para blogs internos, catálogos pequenos e intranets. O problema aparece em backups, migrações e escalabilidade. Se você precisar rodar duas instâncias do CMS, o armazenamento local vira ponto único. Object storage compatível com S3, quando disponível, facilita CDN, réplicas, migração e políticas de retenção. Mesmo assim, ele não elimina a necessidade de backup do banco, porque os metadados das mídias continuam no PostgreSQL.

Para escolher disco, pense em três números: tamanho atual do banco, crescimento mensal de mídia e janela de retenção dos backups. Um projeto com banco de 5 GB, uploads crescendo 10 GB por mês e retenção de 14 dias pode estourar uma VPS pequena se os dumps ficarem no mesmo volume. O desenho mais seguro usa backup externo, compressão, teste de restauração e monitoramento de uso de disco antes de atingir 80 por cento de ocupação.

Docker, deploy e operação em produção

Docker é uma escolha frequente para Strapi e Directus porque simplifica versão de Node.js, dependências, variáveis de ambiente e reprodução entre desenvolvimento, staging e produção. Com Docker Compose, dá para declarar serviços como app, postgres, nginx e redis, conectar tudo por rede interna e manter volumes persistentes para banco e uploads. Isso reduz aquela situação comum em que o servidor de produção tem uma versão diferente de Node, uma extensão ausente ou um pacote instalado manualmente que ninguém documentou.

Um desenho simples de produção pode ter Nginx no host, Strapi em container e PostgreSQL em outro container com volume dedicado. Outra opção é colocar Nginx também em container, usando labels ou configuração estática. Para uma equipe pequena, o mais importante é não tratar container como backup. Se o volume do PostgreSQL for apagado, a imagem Docker não salva os dados. O guia de VPS para Docker cobre justamente esse cuidado com volumes, rede, portas, logs e atualização de imagens.

Variáveis de ambiente precisam ser tratadas como parte crítica do deploy. Chaves de admin, tokens de API, senha do banco, segredo de JWT e configurações de upload não devem aparecer em repositório público. Use .env no servidor, secret manager quando disponível ou mecanismo seguro do seu pipeline. Nunca exponha chaves em exemplos públicos. Em produção, também configure NODE_ENV=production, URL pública correta, proxy reverso e cabeçalhos de segurança. Um erro comum é subir o Strapi na porta 1337 aberta para a internet, sem Nginx, TLS e firewall. Funciona no começo, mas aumenta a superfície de ataque.

Deploy manual com git pull, docker compose up -d --build e migrações controladas pode ser suficiente no início. Quando o time cresce, pipeline com GitHub Actions ou GitLab CI reduz erro humano. Ainda assim, cada deploy deve ter plano de rollback. Antes de atualizar uma versão maior do Strapi, faça snapshot ou backup do banco, teste em staging e leia as notas de migração. Plugins, permissões e estrutura de conteúdo podem mudar entre versões.

Logs também entram na operação diária. Configure rotação para não encher disco, acompanhe erros 500, falhas de conexão com banco e tempo de resposta de rotas críticas. Em Docker, docker logs ajuda no diagnóstico rápido, mas produção pede algo mais persistente, nem que seja journald, Loki, Grafana, Uptime Kuma ou serviço externo. Um CMS fora do ar pode paralisar publicação, landing pages, app mobile e integrações comerciais. Deploy bonito sem monitoramento ainda é um ponto cego.

Localização do servidor, latência e provedores

A localização do servidor afeta tanto a experiência dos editores quanto o tempo de resposta da API para o front-end. Se a equipe editorial está no Brasil e o público principal também, uma VPS ou Cloud Server em São Paulo, Fortaleza ou outra região nacional tende a reduzir latência. Em acessos locais, a diferença entre um servidor no Brasil e um servidor nos EUA pode aparecer em cada chamada da API, login no painel, upload de imagem e consulta administrativa. Para sites estáticos com cache agressivo, isso pesa menos. Para painel dinâmico e APIs privadas, pesa mais.

Miami costuma ser um meio-termo usado por muitos projetos brasileiros. A latência é maior que em datacenter nacional, mas menor que em regiões mais distantes dos EUA ou Europa. Além disso, alguns provedores oferecem mais opções de planos, estoque e rede em Miami. O ponto é não decidir só por mapa. Meça com ping, mtr, testes HTTP reais e, se possível, tráfego vindo da sua audiência. Uma API que responde em 80 ms no servidor pode virar 250 ms no navegador quando há DNS, TLS, rede móvel e múltiplas chamadas sequenciais.

Na seleção de provedores, evite comparar apenas preço. Preço, região, bandwidth, storage e promoções mudam com frequência e precisam de revisão humana antes de publicação. Para Strapi, Directus e headless CMS, compare painel, snapshot, rede privada, tipo de disco, API, facilidade de upgrade, documentação e suporte. LetsCloud pode entrar na lista quando o projeto valoriza presença no Brasil, faturamento local ou latência para público brasileiro, mas recursos como NVMe, snapshots, backup automático, suporte e localidades específicas devem ser confirmados por plano e região. DigitalOcean, Vultr, Linode, AWS Lightsail, Hostinger, Locaweb e HostGator também podem atender perfis diferentes, cada um com suas limitações e vantagens operacionais.

Perfil de provedor	Quando faz sentido	Pontos técnicos a verificar	Atenção antes de contratar
Cloud Server com região no Brasil	CMS com editores e público no Brasil, painel usado diariamente e API dinâmica	Latência nacional, tipo de disco por plano, snapshots, firewall, rede privada e upgrade	Confirmar disponibilidade de região, storage, backup e bandwidth no site oficial
Provedor global com região próxima, como Miami ou EUA leste	Projeto com orçamento controlado, equipe técnica experiente e front-end com cache	Documentação, API, imagens Docker, rede, limites de transferência e snapshots	Billing em moeda estrangeira, impostos, suporte e variação cambial
VPS gerenciada ou hospedagem com painel	Agência que quer reduzir operação Linux e entregar CMS para clientes menores	Versão de Node.js, acesso SSH, banco, cron, backup e limites de processo	Pode haver menos controle para Docker, tuning de banco e deploy avançado
Cloud pública com serviços anexos	Produção com compliance, banco gerenciado, observabilidade e múltiplos ambientes	IAM, VPC, banco gerenciado, logs, balanceador e object storage	Custo pode crescer com tráfego, snapshots, saída de dados e serviços adicionais

A melhor escolha costuma aparecer depois de mapear o caminho da requisição. Se o front-end está em uma CDN global, mas o painel editorial e a API privada ficam no Brasil, faz sentido aproximar o CMS da equipe e do banco. Se o público é global e a API é muito acessada por usuários finais, talvez seja melhor separar regiões, cache e serviços. O provedor certo é aquele que encaixa no desenho operacional, não apenas na tabela de planos.

Segurança, backup e rotina de manutenção

Strapi e Directus expõem painéis administrativos e APIs que mexem diretamente com conteúdo, usuários, tokens e permissões. Isso exige uma rotina mínima de segurança desde o primeiro deploy. O básico inclui SSH com chave, login root desativado quando possível, firewall liberando apenas portas necessárias, Nginx com TLS, atualizações de sistema e senhas fortes no banco. Também é prudente restringir o painel administrativo por VPN, allowlist de IP ou autenticação adicional quando o projeto tem dados sensíveis.

No servidor, portas como 22, 80 e 443 costumam ser suficientes para a maioria dos cenários. PostgreSQL não deve ficar aberto para a internet sem necessidade. Se app e banco estão na mesma VPS, conecte via localhost ou rede Docker interna. Se estão em servidores diferentes, prefira rede privada, firewall por IP e TLS quando suportado. Tokens de API devem ter escopo mínimo. Um token usado pelo front-end público não deve ter permissão de escrita ou acesso administrativo. Essa separação evita que uma falha no cliente vire comprometimento total do CMS.

Backup precisa cobrir três camadas: banco, uploads e configuração. Um dump diário do PostgreSQL com pg_dump, enviado para armazenamento externo, resolve parte do problema. Os uploads precisam ser copiados também, a menos que estejam em object storage com versionamento e política própria. A configuração inclui .env, arquivos de compose, Nginx e scripts de deploy. Sem esses itens, restaurar em outro servidor vira trabalho manual em momento de pressão.

Snapshots ajudam, mas não substituem backup lógico. Snapshot da VPS é ótimo para voltar rápido depois de atualização ruim, porém pode carregar corrupção, arquivos temporários e estado inconsistente do banco se não houver cuidado. Dump lógico permite restaurar tabelas, migrar entre servidores e testar integridade. Uma rotina saudável combina snapshot antes de mudanças grandes, dump diário, retenção externa e teste mensal de restauração. Teste é a parte que muita equipe pula. Descobrir que o backup não restaura durante uma indisponibilidade real custa caro.

Monitoramento não precisa começar complexo. Uptime HTTP, uso de disco, memória, CPU, certificados TLS e status do banco já cobrem muitos incidentes. Alertas simples por e-mail, Telegram ou Slack ajudam a agir antes que o cliente perceba. Para projetos com SLA interno, registre RPO e RTO: quanto dado você aceita perder e em quanto tempo precisa voltar. Esses dois números orientam frequência de backup, replicação, escolha de provedor e investimento em automação.

Recomendações por perfil

Dev solo e MVP

Para um desenvolvedor solo validando produto, site institucional com painel ou MVP de SaaS, a configuração inicial pode ser 2 vCPUs, 2 a 4 GB de RAM e 40 a 60 GB de SSD. Se o banco ficar no mesmo servidor, prefira 4 GB de RAM para evitar sufoco durante build, instalação de dependências e importação de dados. Docker Compose é uma boa escolha, desde que volumes sejam persistentes e exista backup externo. Upload local funciona no começo, mas já vale deixar a aplicação preparada para migrar mídia para object storage. O foco desse perfil é simplicidade com possibilidade de crescimento, não arquitetura perfeita no primeiro dia.

Agência ou time pequeno

Agências e times pequenos costumam hospedar vários projetos, lidar com editores não técnicos e fazer manutenção recorrente. Para esse perfil, evite colocar muitos CMS críticos na mesma VPS sem isolamento. Um bom ponto de partida por projeto é 2 vCPUs, 4 GB de RAM, 80 GB de SSD ou NVMe e backups diários. Se houver vários clientes, considere uma VPS por cliente relevante ou um cluster simples com banco separado. Painel, documentação do provedor, snapshots e facilidade de restauração pesam bastante. A equipe ganha mais com processos claros, staging e deploy previsível do que com economias pequenas em servidor.

Produção com clientes e SLA interno

Projetos em produção com tráfego, integrações comerciais, app mobile ou SLA interno pedem desenho mais cuidadoso. Comece avaliando 4 vCPUs, 8 GB de RAM, banco PostgreSQL separado, object storage para mídia e monitoramento ativo. A VPS da aplicação pode escalar de forma independente do banco, e o banco pode receber tuning, backup e retenção próprios. Para equipes com compliance ou maior criticidade, banco gerenciado, rede privada, logs centralizados e deploy com rollback reduzem risco operacional. A escolha entre Brasil, Miami ou cloud pública deve considerar latência, suporte, custo total, governança e tempo de recuperação, sempre com dados revisados nas fontes oficiais.