VPS para múltiplos sites: guia de escolha

Resposta direta

Para hospedar múltiplos sites em uma VPS, escolha um servidor com recursos suficientes para o conjunto dos projetos, não apenas para o maior site. Como ponto de partida, 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe atendem bem 5 a 10 sites institucionais leves, desde que exista cache, backups externos e um painel bem configurado. Para WordPress, WooCommerce, áreas logadas ou sites com muitos plugins, 4 vCPUs, 8 GB de RAM e 120 GB ou mais de disco fazem mais sentido. O segredo é combinar dimensionamento, isolamento por usuário, firewall, snapshots, backup fora da VPS e monitoramento. Colocar vários sites no mesmo servidor pode reduzir custo operacional, mas exige disciplina para evitar que um projeto problemático derrube todos os outros.

Resumo rápido

• Uma VPS para múltiplos sites deve ser dimensionada pelo consumo agregado de CPU, RAM, disco, banco de dados, e-mail transacional e picos simultâneos.
• Para 5 a 10 sites leves, use como base 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe, com cache de página e banco bem ajustado.
• Para 15 a 30 sites, especialmente WordPress, considere 4 vCPUs, 8 GB de RAM, 120 a 200 GB de NVMe e backup automatizado fora do servidor.
• Isolamento por usuário Linux, versão de PHP, permissões e banco separado reduz o impacto de falhas e invasões entre clientes.
• Painéis como CloudPanel, CyberPanel, Plesk e cPanel facilitam a rotina, mas aumentam consumo de memória e exigem atualizações frequentes.
• Snapshots ajudam em rollback rápido, enquanto backups externos protegem contra exclusão, corrupção, ransomware e falha do provedor.
• Para sites WordPress, o guia de melhor VPS para WordPress ajuda a refinar requisitos de PHP, cache e banco.

Hospedar vários sites em uma única VPS é comum em agências pequenas, freelancers e negócios com portfólio de marcas. A economia aparece porque um servidor bem configurado pode substituir várias hospedagens compartilhadas. O cuidado é não tratar todos os sites como iguais. Um site institucional de 20 páginas consome pouco. Uma loja WooCommerce com 2.000 produtos, busca interna e área de cliente pode consumir mais que dez sites simples juntos. Por isso, a escolha da VPS precisa começar pelo inventário real dos projetos, incluindo tráfego, plugins, cron jobs, uploads, tamanho do banco e expectativa de crescimento.

O que muda quando uma VPS hospeda vários sites

Quando uma VPS hospeda apenas um site, o diagnóstico costuma ser direto. Se o servidor fica lento, quase sempre o problema está naquele projeto, no banco, no cache ou no tráfego. Em um ambiente multi-site, a análise muda. Um plugin com bug em um WordPress pode ocupar CPU, um backup mal agendado pode disputar I/O com todos os bancos, e um cliente que sobe vídeos de 2 GB pode consumir o disco reservado para outros domínios. O servidor vira uma pequena plataforma compartilhada, mesmo que esteja sob seu controle.

VPS tradicional, Cloud Server e cloud instance

Uma VPS tradicional normalmente roda em um servidor físico virtualizado, com recursos definidos por plano. Um Cloud Server ou uma cloud instance costuma oferecer provisionamento mais flexível, painel com snapshots, upgrade rápido e integrações de rede. Na prática editorial, os termos aparecem misturados no mercado, mas não significam a mesma coisa. Para múltiplos sites, o mais relevante é entender se o provedor permite aumentar CPU, RAM e disco sem migração complexa, se oferece snapshot sob demanda, qual tipo de armazenamento usa e em quais regiões opera.

Também existe diferença entre hospedar vários sites independentes e hospedar variações do mesmo projeto. Uma agência pode ter 20 clientes, cada um com domínio, banco e usuário próprios. Um negócio pode ter site institucional, blog, landing pages, intranet e ambiente de homologação. O primeiro caso pede isolamento administrativo. O segundo pede previsibilidade e controle de deploy. Em ambos, colocar tudo no mesmo usuário do sistema, com as mesmas permissões e sem separação de bancos, é uma economia perigosa.

O risco real não é só tráfego

Tráfego pesa, mas nem sempre é o vilão. Em muitos servidores, o gargalo vem de tarefas recorrentes. Exemplos comuns: wp-cron rodando a cada visita, plugins de backup compactando arquivos em horário comercial, importação de produtos via CSV, filas de e-mail e geração de miniaturas de imagem. Um site com 500 visitas por dia pode causar mais carga que outro com 5.000 visitas se estiver mal configurado. Antes de escolher o plano, liste quais sites usam WordPress, WooCommerce, Laravel, Moodle, fóruns ou ferramentas internas. Essa leitura evita comprar RAM demais e esquecer I/O, ou contratar CPU suficiente e deixar o backup sem estratégia.

Como dimensionar CPU, RAM, NVMe e rede

Dimensionar uma VPS para múltiplos sites exige uma conta simples, mas honesta. Some o consumo médio esperado, depois reserve margem para picos. Um site institucional em WordPress com cache de página pode rodar com 256 a 512 MB de RAM em uso real, considerando PHP-FPM, consultas ao banco e processos auxiliares. Já um WooCommerce, um portal com busca frequente ou uma área logada pode precisar de 1 a 2 GB em momentos de pico. A CPU segue a mesma lógica. Sites estáticos e páginas cacheadas usam pouco processador. Login, carrinho, checkout, painel administrativo e importações geram requisições dinâmicas.

Configuração de partida para 5, 15 e 30 sites

Para 5 a 10 sites leves, uma configuração de 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe é um ponto de partida razoável. Use PHP-FPM com pools separados, MariaDB ou MySQL com buffer ajustado, Nginx ou OpenLiteSpeed e cache de página. Para 15 a 30 sites, especialmente com WordPress, pense em 4 vCPUs, 8 GB de RAM e 120 a 200 GB de NVMe. Se houver lojas, LMS, portais ou muitos uploads, o salto para 8 vCPUs e 16 GB de RAM pode ser mais barato que horas perdidas em incidentes.

O disco merece atenção. Não conte apenas os arquivos atuais. Some uploads, bancos, logs, caches, e-mails se forem hospedados no mesmo servidor, backups locais temporários e espaço para atualização. Um servidor com 100 GB de disco pode parecer amplo até você ter 25 sites, cada um com 2 GB de uploads, mais dumps de banco e logs esquecidos. Para aprender a pesar CPU, RAM e armazenamento sem cair em regra genérica, o guia sobre como escolher CPU, RAM e NVMe aprofunda os trade-offs.

Quando subir de plano

Suba de plano quando houver sinais consistentes, não apenas um pico isolado. Indicadores práticos: load average acima do número de vCPUs por longos períodos, swap usada com frequência, MySQL consumindo disco em operações temporárias, tempo de resposta do PHP subindo em horários previsíveis e fila de requisições no PHP-FPM. Comandos simples ajudam no diagnóstico: htop mostra CPU e memória, df -h mostra disco, du -sh /var/www/* identifica sites que cresceram demais, e systemctl status nginx ajuda a verificar falhas de serviço. Se a VPS permite upgrade vertical rápido, você ganha tempo. Se o disco não expande facilmente, planeje migração antes de chegar a 90 por cento de uso.

Isolamento, painel e organização dos sites

O maior erro em uma VPS multi-site é colocar todos os domínios dentro do mesmo usuário, com permissões amplas e arquivos misturados. Funciona no começo, mas cria um problema operacional. Se um WordPress for invadido, o atacante pode alcançar outros diretórios. Se um desenvolvedor precisar acesso SFTP para um cliente, você acaba entregando mais permissões do que deveria. O mínimo saudável é separar cada site por usuário do sistema, diretório, banco de dados e credenciais. Para PHP, pools separados no PHP-FPM ajudam a limitar consumo e facilitam logs por projeto.

Separação por usuário, domínio e versão de PHP

Um modelo simples é criar estrutura parecida com /home/cliente1/site.com.br/public, /home/cliente2/outrodominio.com/public e assim por diante. Cada domínio deve ter seu próprio usuário, senha de banco e certificado TLS. Quando possível, mantenha versões de PHP por site. Isso ajuda em migrações. Um cliente pode depender de PHP 8.1 por causa de um plugin antigo, enquanto outro já roda PHP 8.3. Misturar tudo obriga decisões ruins, como travar o servidor inteiro em uma versão antiga por causa de um único projeto.

Painéis facilitam essa organização. cPanel e Plesk são conhecidos por agências e clientes finais, mas costumam ter licenciamento e consumo adicional. CloudPanel é leve e popular para Nginx, PHP e bancos em cloud. CyberPanel usa OpenLiteSpeed e pode ser interessante para WordPress com cache. HestiaCP atende cenários simples, mas exige cuidado com atualizações e hardening. A escolha do painel deve considerar quem vai operar o servidor. Se o cliente final precisa criar e-mails e subdomínios, um painel mais completo ajuda. Se só o time técnico mexe, uma stack manual com Ansible, Nginx, PHP-FPM e MariaDB pode ser mais limpa.

Painel ajuda, mas não substitui operação

Painel não resolve arquitetura ruim. Ele simplifica tarefas como criar domínio, emitir SSL, configurar banco e abrir conta SFTP, mas não decide limites de memória, estratégia de backup ou política de atualização. Também consome recursos. Em uma VPS de 2 GB de RAM, um painel pesado pode disputar memória com os próprios sites. Em ambientes com múltiplos WordPress, isso aparece como lentidão no wp-admin, falhas em uploads ou erro 502 durante atualizações. A boa prática é definir padrões antes de criar o primeiro cliente: nome de usuários, localização de logs, versão padrão de PHP, política de cache, limites de upload, retenção de backup e responsável por atualizações. Parece burocracia, mas poupa horas quando existem 20 sites e um incidente às 8h30 de uma segunda-feira.

Backups, snapshots e restauração em ambiente multi-site

Em VPS com múltiplos sites, backup não é opcional. Também não basta deixar uma cópia dentro do próprio servidor. Se o disco corromper, se uma exclusão acidental apagar /var/www ou se uma invasão criptografar arquivos, o backup local pode sumir junto. A estratégia correta combina snapshots do provedor, backups externos e testes de restauração. Snapshot é ótimo para voltar o servidor inteiro a um ponto anterior, por exemplo antes de uma atualização grande. Backup externo é melhor para recuperar um site específico, um banco isolado ou arquivos de upload sem reverter todos os outros clientes.

A regra 3-2-1 aplicada a sites pequenos

A regra 3-2-1 recomenda três cópias dos dados, em dois tipos de armazenamento, com uma cópia fora do ambiente principal. Para uma agência pequena, isso pode ser simples: dados ativos na VPS, snapshot diário no provedor e backup externo em armazenamento compatível com S3, outro servidor ou serviço de backup gerenciado. A retenção pode seguir um padrão prático: diário por 7 dias, semanal por 4 semanas e mensal por 3 meses. Nem todo site precisa da mesma política. Uma landing page muda pouco. Uma loja recebe pedidos todos os dias e precisa de backup de banco mais frequente.

Se você hospeda muitos WordPress, separe backup de arquivos e banco. Arquivos podem ser copiados uma ou duas vezes por dia, dependendo do volume de uploads. Banco de dados de loja ou área logada pode exigir dumps a cada poucas horas, sempre avaliando impacto de I/O. Plugins de backup ajudam, mas em VPS multi-site eles podem rodar todos ao mesmo tempo e derrubar o servidor. Prefira agendar janelas diferentes ou usar backup no nível do servidor. O guia sobre VPS com backup automático detalha diferenças entre snapshot, backup incremental e cópia externa.

Teste de restauração é parte do backup

Backup que nunca foi restaurado é uma promessa. Crie um procedimento de teste. Uma vez por mês, restaure um site pequeno em subdomínio de homologação, importe o banco, ajuste o arquivo de configuração e valide login, imagens e formulários. Esse teste revela erros comuns: dump incompleto, charset quebrado, arquivos de upload ausentes, permissões erradas e certificados esquecidos. Em ambientes com clientes, documente o tempo estimado de recuperação. Um site institucional pode aceitar algumas horas. Uma loja em produção talvez precise de RPO menor, com perda máxima de dados medida em minutos ou poucas horas. Essa conversa precisa acontecer antes do incidente, não durante.

Segurança e manutenção para vários projetos no mesmo servidor

A segurança de uma VPS multi-site depende de camadas. A primeira é acesso. Desative login SSH por senha, use chaves, limite usuários com sudo e altere a porta apenas se isso fizer parte de uma política maior, não como única proteção. Configure firewall com portas mínimas: 22 ou a porta SSH definida, 80, 443 e portas específicas de painel quando necessário. Bancos de dados não devem ficar expostos publicamente. Redis, Memcached e painéis administrativos também precisam escutar apenas em localhost ou rede privada, salvo arquitetura planejada.

Firewall, SSH e atualizações

Em distribuições Ubuntu ou Debian, ufw já resolve muitos cenários simples. Regras como ufw allow 22/tcp, ufw allow 80/tcp e ufw allow 443/tcp cobrem o básico, mas o ideal é restringir SSH por IP quando a equipe tem endereços fixos ou VPN. Fail2ban ajuda a bloquear tentativas repetidas. Atualizações devem entrar em rotina semanal, com janela definida. Kernel, OpenSSL, PHP, MariaDB, Nginx, OpenLiteSpeed e painel precisam de atenção. Em sites WordPress, plugins e temas são parte da superfície de ataque. Um plugin abandonado em um site pequeno pode comprometer todo o servidor se o isolamento for fraco.

Certificados TLS devem ser automáticos. Let’s Encrypt resolve a maioria dos domínios, desde que DNS e webserver estejam corretos. Para múltiplos sites, monitore renovações. Um certificado expirado em site de cliente parece falha simples, mas desgasta confiança. Logs também precisam de rotação. Sem logrotate ajustado, arquivos em /var/log podem crescer até encher o disco. Quando isso acontece, banco para de gravar, uploads falham e o painel pode ficar inacessível.

Monitoramento simples que evita sustos

Você não precisa começar com uma suíte complexa. Um conjunto mínimo já ajuda: alerta de disco acima de 80 por cento, RAM com swap recorrente, CPU alta por mais de 10 minutos, HTTP 5xx em sites principais e expiração de certificado. Ferramentas como Uptime Kuma, Netdata, Grafana Agent, Zabbix ou monitoramento do próprio provedor cumprem papéis diferentes. Para agências, um painel interno com status dos sites mais críticos ajuda no atendimento. Também registre quem tem acesso, quais chaves SSH estão ativas e quais clientes possuem SFTP. Segurança em multi-site é menos sobre uma configuração perfeita e mais sobre reduzir caminhos de falha repetidos.

Tabela comparativa de perfis e recursos

A tabela abaixo não é um comparativo de preço. Ela organiza perfis comuns de uso e recursos técnicos recomendados. Valores de planos, regiões, bandwidth e promoções mudam com frequência em provedores como DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Hostinger, Locaweb, HostGator e LetsCloud, por isso qualquer decisão comercial precisa ser conferida no site oficial antes da contratação. Os dados de referência de documentação e páginas de produto foram revisados em 11/06/2026, mas não substituem revisão humana de preço ou disponibilidade.

Perfil de uso	Quantidade típica	Recursos iniciais	Disco e backup	Painel sugerido	Observações técnicas
Freelancer com sites institucionais	5 a 10 sites leves	2 vCPUs, 4 GB RAM	80 GB SSD ou NVMe, snapshot diário e backup externo semanal	CloudPanel, HestiaCP ou stack manual	Cache de página obrigatório, PHP-FPM separado por site e logs com rotação
Agência pequena com WordPress	10 a 25 sites, alguns com blog ativo	4 vCPUs, 8 GB RAM	120 a 200 GB NVMe, backup diário externo e retenção semanal	Plesk, CloudPanel, CyberPanel ou cPanel	Separar usuários, bancos e versões de PHP. Monitorar wp-cron, plugins e uso de banco
Produção com lojas e áreas logadas	5 a 15 sites críticos	8 vCPUs, 16 GB RAM	200 GB ou mais, snapshots antes de deploy e backup de banco mais frequente	Plesk, cPanel ou stack gerenciada pela equipe	Avaliar banco separado, Redis, CDN e ambiente de homologação para deploys
Portfólio com muitos sites estáticos	30 ou mais páginas simples	2 a 4 vCPUs, 4 a 8 GB RAM	80 a 160 GB, backup externo de repositórios e assets	Nginx manual, CloudPanel ou deploy via Git	Sites estáticos escalam bem, mas DNS, SSL e automação de deploy precisam padrão

Alguns provedores se encaixam melhor em perfis específicos. DigitalOcean, Vultr e Linode/Akamai são conhecidos por painel simples, documentação ampla e instâncias flexíveis. AWS Lightsail é uma opção de entrada no ecossistema AWS, com pacotes mais previsíveis que EC2 tradicional. Hostinger, HostGator e Locaweb costumam conversar com usuários que querem suporte e painel mais familiar, embora os detalhes de VPS, suporte e renovação precisem ser checados caso a caso. LetsCloud pode fazer sentido quando a prioridade é operação no Brasil, cobrança local e latência para público brasileiro, mas isso depende do plano disponível, da região e da necessidade de suporte. Não existe melhor provedor universal. Existe servidor adequado ao seu conjunto de sites, ao seu orçamento e à sua capacidade de operar a infraestrutura.

Recomendações por perfil

Freelancer ou dev solo

Se você é freelancer e hospeda sites de clientes pequenos, comece simples, mas não improvisado. Uma VPS com 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe costuma atender bem 5 a 10 sites institucionais com WordPress, cache ativo e poucos plugins pesados. Use CloudPanel, HestiaCP ou uma stack manual se você domina Nginx, PHP-FPM e MariaDB. Separe cada cliente por usuário, crie bancos individuais e mantenha backups fora do servidor. Evite hospedar e-mail na mesma VPS se você não quer lidar com reputação de IP, SPF, DKIM, DMARC e filas. Para e-mail corporativo, serviços dedicados costumam reduzir dor de cabeça.

Agência pequena com clientes recorrentes

Uma agência com 10 a 25 sites precisa pensar como operação, não como coleção de projetos. O ponto de partida mais seguro é 4 vCPUs, 8 GB de RAM e 120 a 200 GB de NVMe, com monitoramento e backup diário externo. Painel faz diferença porque reduz tempo de tarefas repetidas, como criar domínio, SSL, banco, usuário SFTP e subdomínio de homologação. Plesk, cPanel, CloudPanel e CyberPanel podem funcionar, desde que a equipe entenda consumo, atualizações e limites. Documente padrão de plugins, política de cache, horário de backup e processo de restauração. Quando um cliente pede urgência, a agência precisa responder com procedimento, não com tentativa e erro.

Operação em produção com receita crítica

Se os sites geram receita direta, como WooCommerce, portais de assinatura, cursos ou sistemas internos, trate a VPS única com cautela. Uma configuração de 8 vCPUs, 16 GB de RAM e 200 GB ou mais de NVMe pode ser adequada para vários projetos, mas talvez não seja a melhor arquitetura para todos. Banco separado, Redis, CDN, storage externo para uploads e ambiente de homologação reduzem risco. Sites críticos não devem disputar recursos com projetos experimentais. Também faz sentido separar clientes por servidor quando contratos, LGPD, SLA ou impacto financeiro justificam. A VPS multi-site ainda pode existir, mas com critérios claros de entrada, monitoramento mais sério e rotina de testes de restauração.

Se o servidor usa swap com frequência ou disco passa de 80 por cento, é hora de rever o plano.