Como escolher VPS para Directus no Brasil

Resposta direta

Para hospedar Directus self-hosted no Brasil, uma VPS ou Cloud Server com 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe e banco PostgreSQL já atende muitos projetos pequenos e médios em produção. O ponto principal não é apenas instalar o Directus, mas montar uma stack confiável com Node.js LTS, banco de dados bem configurado, storage persistente para uploads, proxy reverso com SSL, firewall, backups testados e monitoramento básico. Se a API atende usuários brasileiros, um datacenter no Brasil ou próximo da América do Sul reduz latência, principalmente em painéis administrativos com muitos assets e chamadas REST ou GraphQL. Para ambientes mais críticos, separe banco e aplicação, use snapshots antes de upgrades e monitore CPU, memória, I/O e tempo de resposta.

Resumo rápido

Directus é um headless CMS e plataforma de dados em Node.js. Ele conecta uma interface administrativa e APIs REST ou GraphQL a um banco SQL existente, por isso a escolha da VPS precisa considerar aplicação, banco, arquivos enviados, cache, rede e rotina de operação. Um servidor pequeno pode funcionar bem para um catálogo interno, mas começa a sofrer quando muitos usuários acessam o painel, fazem uploads grandes ou executam consultas pesadas no banco.

• Para produção básica, comece com 2 vCPUs, 4 GB de RAM e 60 GB de SSD ou NVMe.
• PostgreSQL costuma ser uma escolha forte para Directus, mas MySQL e MariaDB também são opções suportadas.
• Use Nginx, Caddy ou Traefik como proxy reverso, com HTTPS obrigatório via Let’s Encrypt.
• Separe uploads em volume persistente, bucket S3 compatível ou disco bem monitorado.
• Backups precisam cobrir banco de dados, arquivos enviados, variáveis de ambiente e configuração do proxy.
• Datacenter no Brasil ajuda em latência para equipes e usuários brasileiros, mas deve ser avaliado junto com estabilidade, suporte e rede.
• Antes de comparar preço entre provedores, confirme CPU, RAM, tipo de disco, tráfego, backup e localização na página oficial.

Se você já pesquisou alternativas como Strapi, vale comparar o modelo operacional. O artigo sobre VPS para Strapi e headless CMS no Brasil aprofunda diferenças entre CMS headless em Node.js, enquanto este guia foca no Directus, banco SQL e operação diária.

Por que o Directus muda a escolha da VPS

Directus parece simples quando visto pelo painel, mas por baixo ele combina uma aplicação Node.js, um banco relacional, APIs, autenticação, permissões granulares, processamento de arquivos e tarefas administrativas. Isso muda a escolha da VPS porque o gargalo pode aparecer em lugares diferentes. Em um projeto com poucos editores, a CPU quase não sofre. Em outro, com muitas relações no banco, filtros complexos e uploads frequentes, o disco e o banco viram o centro da operação.

Directus não é só um painel administrativo

Um erro comum é tratar o Directus como um painel estático. Na prática, cada tela do admin faz várias chamadas para a API. Uma coleção com 20 campos relacionais, filtros dinâmicos e permissões por função pode gerar consultas SQL mais custosas do que um CRUD simples. Se a VPS tem 1 GB de RAM e divide recursos com banco, Node.js, proxy e sistema operacional, qualquer pico pode acionar swap. Quando isso acontece, o painel fica lento, uploads falham e jobs podem demorar mais do que o esperado.

Para um projeto editorial pequeno, com 3 a 5 usuários internos e algumas centenas de registros, 2 vCPUs e 4 GB de RAM costumam ser um ponto de partida mais seguro do que planos mínimos de 1 vCPU e 1 GB. Em um e-commerce headless, aplicativo mobile ou portal que consome a API publicamente, o cálculo muda. A VPS passa a atender não só o time de conteúdo, mas também tráfego de usuários finais.

VPS tradicional, Cloud Server e cloud instance

VPS tradicional geralmente significa uma máquina virtual em um servidor físico, com recursos definidos por plano. Cloud Server ou cloud instance costuma trazer provisionamento mais flexível, snapshots, upgrades mais rápidos e integração com rede privada ou volumes, dependendo do provedor. A nomenclatura varia muito, então o rótulo sozinho não basta.

Para Directus, observe quatro pontos concretos: possibilidade de upgrade sem reinstalação, tipo de armazenamento, política de backup e localização do datacenter. Provedores como DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Hostinger, Locaweb, HostGator e LetsCloud podem aparecer na lista de opções, mas cada um tem diferenças de região, painel, tráfego, storage e suporte. Dados de preço, região e recursos mudam com frequência e precisam ser validados nas páginas oficiais antes da publicação de qualquer comparativo.

Arquitetura recomendada para Directus em produção

Uma arquitetura de produção para Directus não precisa começar complexa. O ideal é começar simples, mas com separação lógica clara. Mesmo em uma única VPS, pense em camadas: proxy reverso na frente, Directus rodando como serviço Node.js ou container, banco de dados com volume persistente, diretório de uploads protegido e rotina de backup fora da máquina principal. Essa organização evita improviso quando o projeto cresce.

Componentes mínimos

A stack mínima para Directus em produção inclui Node.js LTS, Directus, PostgreSQL ou MySQL/MariaDB, proxy reverso com HTTPS, firewall e backups. Se usar Docker Compose, um arquivo enxuto pode conter serviços para Directus e banco, além de volumes nomeados para persistência. Em instalação sem Docker, o Directus pode rodar com systemd ou PM2, desde que reinicie automaticamente após falhas e boot do servidor.

Um exemplo prático de organização em VPS única seria: Ubuntu LTS, Nginx na porta 80 e 443, Directus escutando localmente na porta 8055, PostgreSQL aceitando conexões apenas locais, UFW liberando somente SSH, HTTP e HTTPS, e backups diários enviados para armazenamento externo. As variáveis KEY, SECRET, DB_CLIENT, DB_HOST, DB_DATABASE, DB_USER, DB_PASSWORD e PUBLIC_URL ficam em arquivo .env com permissão restrita. Nunca coloque chaves reais em repositório Git.

Exemplo de stack enxuta

Em projetos pequenos, Docker Compose facilita padronização. Um arquivo com Directus, PostgreSQL e volumes persistentes já resolve boa parte do ciclo de vida. Para produção, evite depender apenas de docker restart manual. Configure política de restart, logs rotacionados e health checks quando possível. Também é prudente limitar quem acessa o banco, deixar o PostgreSQL fora da internet pública e publicar somente o proxy reverso.

Quem já opera aplicações Node.js vai reconhecer padrões semelhantes. O guia de VPS para Node.js no Brasil complementa este tema com PM2, systemd, variáveis de ambiente, deploy e proxy reverso. No Directus, a diferença é que o banco e o storage têm peso maior, já que o CMS depende diretamente da consistência desses dados. Não adianta um Node.js rápido se o volume de uploads está sem backup ou se o banco usa configurações padrão inadequadas para a memória disponível.

CPU, RAM, disco e rede: como dimensionar

Dimensionar VPS para Directus exige olhar para três cargas diferentes: uso do painel administrativo, consumo da API e trabalho do banco de dados. Um time pequeno editando conteúdo durante o expediente gera um padrão previsível. Uma API pública consumida por site, app ou integração externa cria picos em horários variados. Já o banco sofre quando existem muitas relações, filtros, ordenações e permissões aplicadas em coleções grandes.

Configuração mínima realista

Para produção leve, considere 2 vCPUs, 4 GB de RAM e 60 GB de SSD como configuração mínima realista. O sistema operacional, proxy, Directus e banco podem ocupar perto de 1 GB a 1,5 GB em repouso, dependendo da distribuição e dos serviços. O restante da memória fica para cache do banco, processo Node.js, conexões simultâneas e buffers. Com 2 GB de RAM, até funciona em laboratório, mas a margem fica curta quando há uploads, importações CSV ou consultas mais pesadas.

Um cenário típico: agência com 2 editores, 15 coleções, 5 mil registros e uploads de imagens otimizadas. Nessa escala, 2 vCPUs e 4 GB de RAM tendem a funcionar bem se o banco estiver indexado e os uploads não forem enormes. Agora imagine um app mobile fazendo 50 mil requisições por dia à API do Directus, com autenticação e filtros por usuário. A CPU passa a importar mais, principalmente se a aplicação usa GraphQL com consultas flexíveis.

Quando subir para 4 vCPUs ou mais

Suba para 4 vCPUs e 8 GB de RAM quando houver múltiplos editores simultâneos, API pública com tráfego constante, coleções grandes ou banco rodando na mesma VPS. Essa configuração também dá mais folga para backups compactados, importações e tarefas administrativas sem derrubar a experiência do painel. Em produção crítica, separar banco e aplicação é mais previsível do que apenas aumentar a máquina. Directus em uma instância e PostgreSQL em outra permite ajustar recursos de cada camada.

Disco rápido ajuda, mas não corrige consulta ruim. SSD ou NVMe reduz latência de I/O, acelera leitura de índices e melhora operações com arquivos, porém índices adequados continuam necessários. Em relação à rede, procure planos com tráfego compatível com uploads e entrega de mídia. Se o Directus servir imagens diretamente para um site público, 1 TB mensal pode acabar mais rápido do que parece. Uma imagem de 500 KB carregada 2 milhões de vezes consome perto de 1 TB. Nesses casos, CDN ou object storage pode ser mais eficiente do que expandir somente a VPS.

Banco de dados e storage: onde estão os gargalos

O Directus brilha porque trabalha sobre bancos SQL existentes, mas isso também significa que o banco é parte crítica da arquitetura. PostgreSQL é muito usado por sua robustez, suporte a tipos avançados e bom comportamento em aplicações com relações complexas. MySQL e MariaDB também podem atender bem, especialmente quando o time já domina esse ecossistema. A escolha deve considerar conhecimento da equipe, ferramentas de backup, replicação, extensões e integração com aplicações existentes.

PostgreSQL ou MySQL

Para PostgreSQL em uma VPS de 4 GB, uma configuração inicial conservadora pode reservar algo como 1 GB para shared_buffers, ajustar work_mem com cuidado e manter max_connections em número realista. Não faz sentido permitir 500 conexões em uma máquina pequena. Em muitos projetos, 50 a 100 conexões já são mais do que suficiente, desde que a aplicação não abra conexões sem controle. Para MySQL ou MariaDB, ajuste innodb_buffer_pool_size de acordo com a memória livre, muitas vezes entre 1 GB e 2 GB em uma VPS de 4 GB a 8 GB.

Se o projeto usa MariaDB por padrão ou integra com aplicações PHP, o artigo sobre VPS para MySQL e MariaDB no Brasil ajuda a aprofundar cache, disco, conexões e backup. No Directus, o ponto decisivo é testar consultas reais. Crie índices nas colunas usadas para filtros frequentes, ordenações e relações. Um painel que lista pedidos por status, cliente e data precisa de índices coerentes. Sem isso, o banco faz varreduras maiores e a VPS parece fraca, mesmo quando o problema é modelagem.

Uploads, volumes e disco persistente

Storage merece atenção própria. Directus pode armazenar arquivos localmente, em disco persistente, ou integrar com serviços compatíveis com S3, dependendo da configuração. Armazenamento local é simples e barato para começar, mas exige backup rigoroso. Se a VPS for recriada sem preservar o volume, os metadados continuam no banco, mas os arquivos desaparecem. Isso quebra imagens, documentos e anexos.

Um arranjo seguro para VPS única usa um diretório dedicado, como /var/lib/directus/uploads, montado em volume persistente e incluído no backup diário. Para projetos com muitos assets, bucket S3 compatível ou storage externo reduz pressão sobre disco local e facilita escalabilidade. Nesse caso, teste permissões, URLs públicas, tamanho máximo de upload e política de cache. Também monitore espaço livre. Deixar o disco chegar a 100% pode travar banco, impedir logs e corromper operações em andamento.

Proxy reverso, SSL e segurança operacional

Colocar o Directus exposto diretamente na porta 8055 é aceitável em teste local, mas não é uma boa prática em produção. O caminho mais seguro é publicar Nginx, Caddy ou Traefik nas portas 80 e 443, terminar TLS no proxy e encaminhar o tráfego para o Directus em localhost ou em uma rede Docker privada. Isso simplifica certificados, headers, compressão, limites de upload e futuras rotas para outros serviços.

Nginx, Caddy ou Traefik

Nginx é uma escolha comum por estabilidade e ampla documentação. Uma configuração básica usa proxy_pass http://127.0.0.1:8055, headers X-Forwarded-Proto, X-Forwarded-For e Host, além de limite de upload adequado ao projeto, como client_max_body_size 50M. Caddy simplifica certificados automáticos e pode ser excelente para times menores. Traefik combina bem com Docker, labels e múltiplos serviços, mas adiciona uma camada de abstração que precisa ser entendida.

O SSL deve ser obrigatório. Let’s Encrypt resolve a maioria dos casos sem custo de licença, desde que DNS e portas estejam corretos. Também configure redirecionamento de HTTP para HTTPS, HSTS se o domínio estiver maduro e cookies seguros. No Directus, revise PUBLIC_URL para evitar links errados em convites, uploads e callbacks. Em ambientes atrás de proxy, essa variável precisa refletir a URL pública real, por exemplo https://admin.exemplo.com.

Hardening básico para produção

Segurança operacional começa pelo acesso ao servidor. Desabilite login SSH por senha, use chaves, crie usuário sem root para administração, mantenha firewall ativo e restrinja portas. Uma VPS típica para Directus deve expor apenas 22, 80 e 443, e mesmo a porta 22 pode ser limitada por IP quando a equipe tem rede fixa ou VPN. O banco não deve ficar aberto para a internet, salvo arquitetura específica com regras restritas e TLS.

No Directus, cuide de KEY e SECRET, rotação de senhas, permissões por função e autenticação do painel. Não dê acesso administrativo amplo para usuários que só precisam editar uma coleção. Revise CORS com cuidado. Liberar * em API pública pode facilitar testes, mas cria risco em produção. Também acompanhe atualizações do Directus e do Node.js LTS. Antes de atualizar uma versão principal, gere snapshot ou backup completo, leia notas de release e teste em ambiente de homologação.

Backups, snapshots, deploy e monitoramento

Backup de Directus não é apenas uma cópia do diretório da aplicação. Um backup útil precisa permitir restauração completa: banco de dados, uploads, arquivo .env, configuração do proxy, versão do Directus e, se houver Docker, docker-compose.yml. Sem esse conjunto, a recuperação vira tentativa e erro. O teste de restauração é o que separa backup real de arquivo acumulado.

Rotina de backup que dá para restaurar

Uma rotina prática para VPS única pode combinar dump diário do PostgreSQL ou MySQL, compactação dos uploads e envio para storage externo. Para PostgreSQL, pg_dump atende muitos projetos pequenos e médios. Para MySQL/MariaDB, mysqldump ainda é comum, embora bases maiores possam exigir ferramentas próprias e janelas de backup planejadas. Guarde pelo menos 7 cópias diárias, 4 semanais e 3 mensais quando o projeto tiver valor operacional relevante.

Snapshots do provedor são úteis antes de upgrades e mudanças de infraestrutura, mas não substituem backup externo. Snapshot fica na mesma conta e, em alguns casos, na mesma região ou plataforma. Se houver problema na conta, erro humano ou incidente no provedor, uma cópia externa reduz o risco. Recursos como snapshots, backup automático e retenção variam por provedor e plano. Confirme nas páginas oficiais de DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Hostinger, Locaweb, HostGator, LetsCloud e demais opções antes de assumir disponibilidade.

Atualizações sem susto

Deploy pode ser simples. Em uma instalação com Docker Compose, mantenha o arquivo versionado, atualize a imagem do Directus em homologação, rode migrações quando necessárias e só depois replique em produção. Em instalação com Node.js direto, use PM2 ou systemd, mantenha versão LTS e registre comandos de atualização. Um procedimento escrito evita que cada deploy dependa da memória de uma pessoa.

Monitoramento básico deve acompanhar CPU, RAM, disco, I/O, uso de swap, status do serviço, tempo de resposta HTTP e validade do certificado SSL. Ferramentas como Uptime Kuma, Netdata, Grafana Agent, Prometheus ou monitoramento nativo do provedor podem resolver diferentes níveis de maturidade. Configure alertas para disco acima de 80%, swap em uso constante, erro 5xx recorrente e certificado perto do vencimento. Se a equipe só descobre falha quando o cliente manda mensagem, a operação ainda está frágil.

Tabela comparativa de perfis de VPS para Directus

A tabela abaixo não compara preços nem promete desempenho absoluto. Ela organiza perfis de infraestrutura para ajudar no planejamento inicial. Antes de contratar, valide na página oficial do provedor a região disponível, o tipo de disco, tráfego incluso, política de backup, snapshots, IPv4, suporte e condições de renovação. Esses dados mudam com frequência e precisam de revisão humana quando usados em ranking ou comparativo comercial.

Perfil de uso	Recursos sugeridos	Banco e storage	Tráfego esperado	Observações de operação
Projeto interno pequeno	2 vCPUs, 4 GB RAM, 60 GB SSD	PostgreSQL ou MySQL na mesma VPS, uploads locais com backup diário	Até alguns milhares de chamadas por dia	Bom para painel administrativo, MVP e catálogo interno com poucos editores
Agência com vários clientes	4 vCPUs, 8 GB RAM, 100 GB SSD ou NVMe	Banco na mesma VPS ou instância separada, uploads em volume persistente ou S3 compatível	Dezenas de milhares de chamadas por dia	Exige isolamento por projeto, rotina de atualização e monitoramento de disco
API pública em produção	4 a 8 vCPUs, 8 a 16 GB RAM, disco rápido	Banco separado, cache opcional, storage externo para assets	Tráfego variável, picos por campanha ou app	Melhor separar camadas, usar CDN e testar consultas reais antes de escalar
Ambiente crítico com SLA interno	Instâncias separadas para app, banco e backup	PostgreSQL gerenciado ou servidor dedicado ao banco, backups externos	Tráfego constante e dependência do negócio	Precisa de plano de restauração, observabilidade, alertas e janela de manutenção

Na prática, a escolha entre DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Hetzner, Contabo, Hostinger, Locaweb, HostGator ou LetsCloud depende mais do encaixe operacional do que de um único número de CPU. Para público brasileiro, latência, idioma do painel, forma de pagamento, região disponível e qualidade da rede pesam bastante. A LetsCloud pode entrar na análise quando o projeto valoriza presença ou operação próxima do Brasil, mas recursos como NVMe, localidades específicas, backups e snapshots devem ser confirmados por plano e região antes de qualquer recomendação fechada.

Também vale separar ambiente de homologação. Mesmo uma VPS menor, com 1 vCPU e 2 GB de RAM, pode servir para testar atualização do Directus, migração de banco e configuração de proxy antes de mexer na produção. O custo operacional de quebrar o painel em horário comercial costuma ser maior do que manter uma instância simples para testes.

Recomendações por perfil

Dev solo e projeto pequeno

Para um dev solo criando MVP, painel interno ou catálogo de conteúdo, a melhor escolha costuma ser uma VPS simples, mas não mínima demais. Use 2 vCPUs, 4 GB de RAM e 60 GB de SSD, com Directus e PostgreSQL na mesma máquina. Instale via Docker Compose se quiser reproduzir o ambiente com facilidade. Configure Nginx ou Caddy com SSL, UFW liberando apenas SSH, HTTP e HTTPS, e backups diários do banco e dos uploads para fora da VPS. Evite otimização prematura. Primeiro garanta que o projeto restaura em outro servidor usando um backup recente.

Agência ou time com múltiplos clientes

Para agência, a preocupação muda. O problema não é apenas rodar Directus, mas manter vários projetos sem misturar dados, permissões e janelas de atualização. Uma VPS de 4 vCPUs, 8 GB de RAM e 100 GB de disco rápido pode hospedar alguns ambientes pequenos, desde que cada projeto tenha banco, diretório de uploads, domínio e variáveis separados. Mesmo assim, não concentre clientes críticos no mesmo servidor sem plano de contingência. Documente versões, mantenha backups por cliente e monitore disco com folga. Se dois clientes fizerem upload pesado no mesmo dia, a disputa por I/O pode aparecer.

Produção crítica com API pública

Quando o Directus serve uma API pública para site, app mobile ou integração de negócio, trate a arquitetura como aplicação de produção. Separe Directus e banco sempre que o orçamento permitir. Use 4 a 8 vCPUs para a aplicação quando houver tráfego constante, 8 a 16 GB de RAM no conjunto da stack e storage externo para assets. Coloque CDN na frente de arquivos públicos e monitore latência da API a partir do Brasil. Antes de aumentar plano, revise índices, consultas, permissões e cache HTTP. Muitos gargalos de Directus nascem no banco e não desaparecem apenas com mais CPU.

Times com exigência de governança

Em empresas com governança, auditoria e dados sensíveis, a VPS precisa entrar em uma rotina maior de segurança. Use acesso por chave SSH, controle de usuários, logs centralizados, política de senha forte, backups criptografados e revisão de permissões no Directus. Se houver dados pessoais, alinhe retenção, acesso e restauração com a política interna de privacidade. Também documente quem pode criar coleções, alterar papéis, exportar dados e instalar extensões. Directus dá bastante poder ao administrador, então a gestão de acesso não pode ser tratada como detalhe.

Quando considerar migração para arquitetura maior

Alguns sinais indicam hora de sair da VPS única: swap frequente, banco consumindo todo o I/O, uploads enchendo disco rapidamente, deploys com indisponibilidade longa, consultas lentas em coleções principais e picos de API que afetam o painel administrativo. Nessa fase, a evolução natural é separar banco, mover arquivos para storage externo, colocar CDN e criar ambiente de homologação obrigatório. Não precisa redesenhar tudo de uma vez. Comece pelo gargalo medido. Se o disco está no limite por causa de mídia, storage externo resolve melhor do que dobrar CPU. Se o banco responde devagar, índices e separação de instância costumam ter impacto maior.