WordPress multisite no Brasil: qual VPS escolher?

Resposta direta

Para WordPress Multisite no Brasil, a VPS ideal começa em 2 vCPUs, 4 GB de RAM e 60 GB de SSD para redes pequenas, mas agências com muitos sites ativos devem mirar 4 vCPUs, 8 GB de RAM, armazenamento SSD ou NVMe e cache bem configurado. O ponto central não é apenas hospedar vários sites no mesmo servidor. É controlar CPU, PHP-FPM, banco de dados, Redis, backups e isolamento operacional sem deixar um site problemático derrubar toda a rede. Se o público acessa majoritariamente do Brasil, datacenter nacional ou rota de baixa latência pode reduzir tempo de resposta, principalmente no painel administrativo e em páginas sem cache. Para produção, escolha provedor com upgrade simples, snapshots, firewall, monitoramento e documentação clara sobre recursos por plano.

Resumo rápido

• Para uma rede pequena, use pelo menos 2 vCPUs, 4 GB de RAM e 60 GB de SSD.
• Para agência com 20 a 80 sites, 4 vCPUs e 8 GB de RAM costumam ser um ponto de partida mais seguro.
• Redis, OPcache e cache de página reduzem carga no PHP e no banco de dados.
• WordPress Multisite não isola falhas como containers separados ou VPS diferentes.
• Backups precisam prever restauração da rede inteira e, quando possível, recuperação por site.
• Datacenter no Brasil ajuda em latência, mas não substitui boa configuração de cache.
• NVMe melhora operações de I/O, porém disponibilidade e ganho real dependem do plano e do workload.
• Se você ainda está comparando cenários, o guia de melhor VPS para WordPress ajuda a separar requisitos gerais de WordPress dos cuidados específicos do Multisite.

O que muda no WordPress Multisite quando ele sai da hospedagem compartilhada

WordPress Multisite parece simples no começo: uma instalação, vários sites, um painel de rede e um conjunto centralizado de temas e plugins. Para agências, isso reduz trabalho repetitivo. Você atualiza um plugin uma vez, controla permissões em um painel só e consegue criar novos sites em minutos. O problema aparece quando essa facilidade encontra tráfego real, muitos editores trabalhando ao mesmo tempo e plugins pesados rodando em todos os subsites.

Em hospedagem compartilhada, a rede fica limitada por regras que você não controla. Limite de processos PHP, tempo máximo de execução, bloqueio de tarefas cron, falta de Redis e restrições no banco podem transformar uma rede de 10 sites em um ambiente instável. Em uma VPS, você passa a controlar versão do PHP, Nginx ou Apache, MariaDB, Redis, cron, firewall e política de backup. Esse controle é o motivo técnico para migrar, não apenas a promessa vaga de mais desempenho.

Multisite concentra risco e simplifica operação

O Multisite concentra arquivos, banco de dados e autenticação. Isso facilita a operação, mas também aumenta o impacto de erro. Um plugin incompatível ativado em rede pode afetar todos os sites. Uma tabela grande de logs pode inflar o banco inteiro. Um ataque de força bruta no wp-login.php pode consumir CPU mesmo que apenas um site esteja sendo alvo. Por isso, o servidor deve ser tratado como infraestrutura de produção, com monitoramento, firewall e rotina clara de atualização.

Um exemplo comum em agência: 35 sites institucionais, cada um com 10 a 30 páginas, poucos formulários e tráfego baixo durante a maior parte do mês. Nesse caso, uma VPS de 4 vCPUs e 8 GB de RAM com cache de página pode operar bem. Agora troque 5 desses sites por portais com busca interna, muitos posts e painel editorial ativo. O gargalo muda. O banco passa a receber consultas frequentes e o PHP-FPM precisa de mais workers.

Subdiretórios, subdomínios e domínio próprio

A escolha entre subdiretórios, subdomínios e domínios próprios também afeta a operação. Subdiretórios simplificam SSL e roteamento, como exemplo.com/site1. Subdomínios exigem wildcard DNS e certificado adequado, como site1.exemplo.com. Domínios próprios por subsite pedem mapeamento correto, renovação de certificados e atenção a cache por host. Se a agência trabalha com clientes distintos, domínio próprio costuma ser o formato mais realista.

Essa é a diferença entre apenas rodar WordPress e operar uma rede. Se o seu objetivo é hospedar projetos independentes sem compartilhar banco e plugins, talvez faça mais sentido avaliar uma VPS para múltiplos sites com isolamento por vhost, usuário Linux ou container. Multisite é excelente quando existe governança comum. Ele é menos indicado quando cada cliente exige stack, plugins e ciclos de atualização completamente diferentes.

CPU, RAM e disco: como dimensionar a VPS sem chute

Dimensionar uma VPS para WordPress Multisite exige olhar para três cargas ao mesmo tempo: requisições públicas, uso do painel administrativo e rotinas em segundo plano. Página cacheada consome pouco PHP. Já wp-admin, busca interna, importação de posts, geração de thumbnails e plugins de formulário podem consumir CPU e RAM de forma concentrada. Por isso, contar apenas visitas mensais engana. Uma rede com 20 mil visitas mensais e muitos editores pode pesar mais que uma rede com 100 mil visitas mensais bem cacheadas.

Configuração mínima realista

Para produção pequena, pense em 2 vCPUs, 4 GB de RAM e 60 GB de SSD. Esse perfil atende redes com 5 a 15 sites institucionais, tráfego moderado, cache de página ativo e banco no mesmo servidor. Uma divisão prática de memória seria 512 MB a 1 GB para o sistema, 1 GB a 1,5 GB para MariaDB, 512 MB para Redis e o restante para PHP-FPM, Nginx e processos ocasionais. Em PHP-FPM, um ponto inicial conservador pode ser pm = dynamic, pm.max_children = 12, pm.start_servers = 3, pm.min_spare_servers = 2 e pm.max_spare_servers = 5, ajustando após observar consumo real por processo.

Quando a rede passa de 20 sites ativos, o ponto de partida mais confortável costuma ser 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe. Esse perfil suporta mais workers PHP, buffer de banco maior e cache de objeto com margem. Para agências, essa folga evita que uma atualização em massa, um importador de conteúdo ou um pico em campanha deixe todos os sites lentos. CPU também importa. WordPress com construtores visuais, plugins de SEO, WooCommerce em alguns subsites e compressão de imagens pode gerar picos curtos, mas intensos.

Quando subir para 8 GB ou mais

Suba para 8 GB de RAM quando o servidor começar a usar swap com frequência, quando o tempo de resposta do wp-admin passar de 800 ms a 1,5 s em horários normais, ou quando o banco estiver pressionado por consultas repetidas. Com 8 GB, dá para reservar 2 GB a 3 GB para MariaDB em redes médias, manter Redis com 256 MB a 1 GB e ampliar PHP-FPM sem sufocar o sistema. Em redes maiores, 16 GB permite separar melhor buffers, filas, backups locais temporários e processos de manutenção.

Disco deve ser avaliado por volume e por I/O. Uma rede com muitos uploads, backups locais e thumbnails pode ocupar 100 GB rapidamente. Use regra simples: some o tamanho atual de wp-content/uploads, multiplique por 2 para crescimento e thumbnails, depois adicione espaço para banco, logs e pelo menos uma janela curta de backup temporário. Se hoje a rede tem 35 GB de uploads, uma VPS com 80 GB já nasce apertada. Melhor mirar 120 GB ou mais, ou enviar backups diretamente para storage externo.

Cache, banco de dados e PHP-FPM em uma rede de sites

A performance de WordPress Multisite depende menos de uma única tecnologia milagrosa e mais da combinação entre cache de página, cache de objeto, OPcache, banco ajustado e PHP-FPM dimensionado. Se uma página pública é entregue pelo cache, o servidor evita carregar WordPress, consultar banco e executar plugins. Isso muda completamente o consumo. Em uma rede de sites institucionais, cache de página pode reduzir centenas de requisições PHP por minuto para poucas chamadas dinâmicas.

Cache de página, objeto e opcode

Use cache de página para visitantes anônimos, cache de objeto com Redis para consultas repetidas e OPcache para reduzir recompilação de scripts PHP. Um desenho comum é Nginx como proxy ou servidor principal, PHP 8.2 ou 8.3 via PHP-FPM, MariaDB 10.11 ou MySQL 8, Redis 7 e plugin de cache compatível com Multisite. Em Nginx, regras de bypass devem respeitar cookies de login, carrinho e comentários. Mesmo que a rede não use loja virtual, formulários e áreas restritas precisam evitar cache indevido.

Um exemplo prático: rede com 25 sites, 60 mil visitas mensais, maioria anônima. Sem cache de página, cada visita aciona PHP e banco. Com cache ativo por 10 minutos para páginas públicas, Nginx entrega HTML estático para grande parte das visitas. Redis ajuda no painel, em menus, opções de tema e consultas repetidas. OPcache deve ter memória suficiente, muitas instalações começam bem com opcache.memory_consumption=192 e opcache.max_accelerated_files=20000, mas redes grandes podem exigir 256 MB ou mais.

Ajustes práticos de banco

No banco, o cuidado principal é não deixar o Multisite virar depósito infinito de transients, logs e revisões. Tabelas como wp_options, tabelas de posts por site e tabelas criadas por plugins podem crescer de forma desigual. Um único subsite com plugin de estatísticas pode gerar milhões de linhas. Agende limpeza de transients expirados, limite revisões com WP_POST_REVISIONS, desative logs desnecessários e monitore queries lentas com slow query log.

Para MariaDB ou MySQL no mesmo servidor, uma configuração inicial em VPS de 8 GB pode usar innodb_buffer_pool_size entre 2 GB e 3 GB, desde que a memória total comporte PHP e Redis. Em VPS de 4 GB, algo entre 1 GB e 1,5 GB costuma ser mais prudente. Não copie configuração de servidor dedicado com 64 GB para uma VPS pequena. O resultado pode ser falta de memória, OOM killer e instabilidade.

Também pense no tipo de site dentro da rede. Um subsite com WooCommerce muda o perfil de cache, pois carrinho, checkout e conta do cliente são dinâmicos. Se a sua rede mistura sites institucionais e lojas, leia também o guia de VPS para WooCommerce no Brasil, porque pedidos, sessões e consultas de produto exigem escolhas diferentes das páginas estáticas de uma rede institucional.

Isolamento, segurança e governança entre sites da rede

WordPress Multisite entrega isolamento administrativo parcial, não isolamento forte de infraestrutura. Cada site pode ter seus usuários, temas permitidos e configurações próprias, mas todos compartilham o mesmo core, o mesmo banco lógico e o mesmo processo de aplicação. Se um plugin ativado em rede quebra compatibilidade com PHP, todos sentem. Se uma credencial de super admin vaza, a rede inteira fica em risco. Esse ponto precisa estar claro antes de vender Multisite como solução para qualquer carteira de clientes.

O que o Multisite isola e o que ele não isola

O Multisite separa conteúdo por tabelas e identificadores de site, mas não impede que um plugin mal desenvolvido consuma CPU em excesso. Também não protege um cliente do impacto de outro se ambos dependem da mesma instalação. Em uma agência, isso funciona bem quando os sites seguem um padrão comum: mesmos temas base, plugins aprovados, rotina de atualização centralizada e política de acesso restrita. Funciona pior quando cada cliente exige liberdade total para instalar plugins, editar tema e rodar scripts próprios.

Uma política prática é criar três níveis de permissão. Super admin fica com poucas pessoas, idealmente duas contas protegidas por autenticação em dois fatores. Administradores de site gerenciam conteúdo e usuários locais, mas não instalam plugins. Editores publicam páginas e posts, sem tocar em configurações críticas. No servidor, desative edição de arquivos pelo painel com DISALLOW_FILE_EDIT, use chaves SSH individuais, bloqueie login por senha quando possível e mantenha firewall liberando apenas portas necessárias, como 22, 80 e 443.

Backups e restauração por site

Backup em Multisite merece atenção extra. Fazer snapshot da VPS é útil para desastre completo, mas não resolve todos os casos. Se um cliente apaga páginas de um subsite na segunda-feira e a agência percebe na quinta, restaurar a VPS inteira pode sobrescrever alterações de todos os outros clientes. O ideal é combinar snapshot do servidor, backup do banco, cópia de uploads e uma estratégia de restauração granular quando a ferramenta permitir.

Na prática, use pelo menos três camadas: snapshot antes de atualizações grandes, backup diário externo do banco e arquivos, e retenção semanal ou mensal para recuperação histórica. Teste restauração em ambiente separado. Não basta ter arquivos .sql.gz em algum bucket. Você precisa saber quanto tempo leva para restaurar 80 GB de uploads e 12 GB de banco, e se o processo preserva domínios mapeados, certificados e regras de cache.

Segurança também inclui atualização disciplinada. Em Multisite, atualizar plugin em rede sem staging é arriscado. Crie uma VPS menor para homologação ou clone temporário antes de mudanças críticas. Em redes com receita relevante, a economia de não ter staging costuma sair cara quando um plugin de formulário, SEO ou construtor visual quebra dezenas de páginas ao mesmo tempo.

Brasil, latência e escolha entre VPS tradicional e Cloud Server

A busca por VPS para WordPress Multisite no Brasil normalmente mistura três preocupações: latência para visitantes brasileiros, suporte operacional e previsibilidade de crescimento. Datacenter no Brasil pode reduzir o tempo de ida e volta da conexão quando comparado a servidores nos Estados Unidos ou Europa, principalmente para usuários fora de redes com boa rota internacional. Isso aparece no wp-admin, em requisições dinâmicas e em sites sem cache. Em páginas totalmente cacheadas por CDN, a diferença pode ser menor, mas ainda existe no origin quando o cache expira.

Quando datacenter no Brasil muda a experiência

Para redes com editores no Brasil, painel administrativo responsivo faz diferença no dia a dia. Salvar post, subir imagem, abrir biblioteca de mídia e consultar pedidos são ações que dependem do servidor de origem. Uma latência de 10 ms a 30 ms em boa rota nacional costuma parecer mais fluida que 130 ms a 180 ms para regiões comuns nos EUA, embora esses números variem por operadora, cidade e provedor. Não trate isso como garantia universal. Meça com ping, traceroute e testes reais a partir das redes usadas pelo time.

Se o público é nacional e o servidor fica fora do país, uma CDN ajuda bastante para arquivos estáticos e páginas cacheadas. Mesmo assim, o servidor precisa responder bem quando há cache miss, login, formulário, busca e painel. Para agências com clientes locais, também pesa a operação financeira e contratual: pagamento em reais, nota fiscal, suporte em horário comercial brasileiro e documentação em português podem reduzir atrito, mas cada item precisa ser confirmado no site oficial do provedor antes da contratação.

Cloud Server não é sinônimo automático de performance

VPS tradicional e Cloud Server não são exatamente a mesma coisa. Uma VPS tradicional geralmente roda em um servidor físico com virtualização e recursos definidos. Um Cloud Server costuma oferecer provisionamento mais flexível, upgrades rápidos e integração com recursos como volumes, snapshots e redes privadas, dependendo do provedor. Isso não significa que todo Cloud Server será mais rápido. Performance depende de CPU disponível, overselling, disco, rede, kernel, configuração da stack e vizinhança no host.

Provedores globais como DigitalOcean, Vultr, Akamai Cloud, AWS Lightsail e Hetzner têm documentação clara e ecossistemas maduros, mas regiões, latência, suporte e cobrança variam bastante. Provedores brasileiros ou com presença voltada ao Brasil, como LetsCloud e Locaweb, podem fazer sentido quando a prioridade é público nacional, contratação local ou proximidade operacional. No caso da LetsCloud, recursos como localidade, tipo de armazenamento, snapshots e backups devem ser confirmados por plano e região antes de publicar qualquer promessa específica. Dados de concorrentes e recursos variáveis precisam de revisão humana na data da contratação.

Tabela comparativa de perfis e recursos

A tabela abaixo não é um ranking de preço. Ela organiza perfis técnicos para ajudar na decisão inicial. Antes de contratar, confirme CPU, RAM, disco, tráfego, snapshots, backup, localidade e política de uso no site oficial do provedor escolhido. Preço, promoções e limites de banda mudam com frequência e não devem ser publicados sem revisão humana.

Perfil de rede	Configuração inicial sugerida	Stack recomendada	Cuidados principais	Quando escalar
Rede pequena, 5 a 15 sites institucionais	2 vCPUs, 4 GB RAM, 60 GB SSD	Nginx, PHP 8.2 ou 8.3, MariaDB, OPcache, cache de página	Backup externo diário, Redis opcional, limitar plugins por site	Swap frequente, wp-admin lento, disco acima de 70%
Agência média, 20 a 80 sites	4 vCPUs, 8 GB RAM, 100 a 160 GB SSD ou NVMe	Nginx, PHP-FPM ajustado, MariaDB com buffer dedicado, Redis, CDN	Staging, monitoramento, firewall, limpeza de transients	Picos de CPU, slow queries, muitos editores simultâneos
Rede crítica ou com lojas dentro do Multisite	8 vCPUs, 16 GB RAM, 200 GB ou mais, backup externo	Banco otimizado, Redis obrigatório, CDN, filas, observabilidade	Separar staging, testar restauração, avaliar banco dedicado	Checkout lento, banco acima de 70% de uso, crescimento acelerado
Multisite com clientes muito diferentes	Avaliar VPS separadas ou containers	Isolamento por projeto, backups independentes, deploy controlado	Evitar plugin livre por cliente, separar ambientes sensíveis	Quando um cliente não pode afetar outro

Na prática, a decisão mais difícil aparece no último perfil. Se todos os sites pertencem à mesma empresa ou seguem um padrão técnico comum, Multisite é eficiente. Se a agência hospeda clientes com necessidades muito diferentes, uma rede única pode virar um ponto central de falha. Nesse caso, talvez seja melhor separar projetos premium em VPS próprias e manter o Multisite para sites padronizados.

Também existe um meio-termo. Algumas agências mantêm uma rede Multisite para landing pages, hotsites e sites institucionais leves, enquanto lojas WooCommerce, portais e aplicações com integrações críticas ficam em servidores separados. Esse desenho reduz risco sem perder produtividade. O importante é não confundir conveniência operacional com isolamento real. Uma única instalação facilita manutenção, mas também concentra impacto.

Recomendações por perfil

Dev solo ou freelancer

Para dev solo que mantém poucos sites próprios ou de clientes próximos, a prioridade deve ser simplicidade operacional. Uma VPS com 2 vCPUs, 4 GB de RAM e 60 GB de SSD é um começo sensato, desde que a rede use cache de página e poucos plugins pesados. Instale uma stack previsível, documente comandos básicos e automatize backups externos desde o primeiro dia. Não espere o primeiro incidente para pensar em restauração. Se você ainda faz tudo manualmente, prefira menos peças: Nginx, PHP-FPM, MariaDB, OPcache e um plugin de cache confiável. Redis pode entrar quando o painel começar a ficar lento ou quando houver muitas consultas repetidas.

Agência com time pequeno

Agência com 20 a 80 sites precisa de mais disciplina. Aqui, 4 vCPUs, 8 GB de RAM e 100 GB ou mais de SSD deixam a operação menos apertada. Crie uma lista de plugins aprovados, defina janelas de atualização e mantenha ambiente de staging. O time deve saber quem pode ativar plugins em rede, quem aprova mudanças de tema e quem responde por incidentes. Monitoramento básico já ajuda muito: uso de CPU, RAM, disco, status do PHP-FPM, disponibilidade HTTP e tamanho do banco. Para esse perfil, uma solução cloud com upgrade simples pode evitar migrações emergenciais em períodos de campanha.

Rede em produção com receita relevante

Quando a rede gera receita direta, atende clientes com SLA contratual ou inclui lojas e portais, trate a VPS como parte de uma arquitetura, não como uma hospedagem isolada. Comece em 8 vCPUs, 16 GB de RAM e 200 GB de armazenamento, ou separe banco e aplicação quando o volume justificar. Use CDN, Redis, backup externo, snapshots antes de mudanças, staging obrigatório e teste de restauração periódico. Também vale avaliar separar subsites críticos fora do Multisite. Se um checkout, portal de assinantes ou área de alunos não pode cair junto com sites institucionais, ele merece isolamento maior.

Checklist antes de contratar e colocar em produção

Antes de contratar a VPS, monte um inventário da rede. Quantos sites existem hoje? Quantos devem entrar nos próximos 12 meses? Qual é o tamanho atual de uploads? Quantos usuários acessam o painel por dia? Existem lojas, áreas restritas, LMS, fóruns ou integrações com CRM? Essas respostas valem mais que uma estimativa genérica de visitas. Uma rede de 12 sites com WooCommerce e importação diária pode exigir mais servidor que uma rede de 50 sites institucionais bem cacheados.

Teste de carga simples

Faça um teste de carga controlado antes de migrar produção. Não precisa começar com ferramenta complexa. Use um ambiente clone, gere tráfego com k6, ab ou loader.io, teste páginas cacheadas e não cacheadas, e acompanhe CPU, RAM, tempo de resposta e slow queries. Um cenário útil é simular 50 usuários virtuais em páginas públicas e, separadamente, 5 usuários autenticados navegando no painel. O objetivo não é provar um número absoluto, mas encontrar gargalos antes dos clientes encontrarem.

Também teste tarefas administrativas. Suba 100 imagens, publique 50 posts, rode uma atualização de plugin em staging e execute backup completo. Observe se o servidor usa swap, se PHP-FPM atinge limite de children, se MariaDB registra queries lentas e se o disco fica pressionado. Em muitos casos, o gargalo aparece em manutenção, não no tráfego público.

Plano de crescimento

A contratação deve prever crescimento sem drama. Confirme se o provedor permite upgrade de CPU e RAM sem reinstalar, se o disco pode crescer, se snapshots são cobrados à parte, se há região adequada para o público brasileiro e se o limite de tráfego atende seu uso. Registre a data de verificação desses dados, porque planos mudam. Para concorrentes e provedores citados neste artigo, dados voláteis como preço, bandwidth, localidade exata, storage e backups precisam ser revisados manualmente antes de virar comparação comercial.

Por fim, defina critérios de separação. Se um subsite passar de 30% do tráfego total, tiver banco muito maior que os demais ou exigir plugins incompatíveis com a política da rede, considere movê-lo para uma instalação própria. Multisite é uma ótima ferramenta de governança, mas não precisa carregar tudo para sempre. A melhor VPS para WordPress Multisite no Brasil é aquela que combina recursos suficientes, operação previsível e margem de crescimento, sem esconder os limites naturais de uma instalação compartilhada.