Como escolher VPS para PrestaShop no Brasil

Resposta direta

Uma VPS para PrestaShop no Brasil deve ser escolhida pelo número de produtos, acessos simultâneos, módulos instalados e volume de pedidos, não apenas pelas visitas mensais. Uma loja pequena pode começar com 2 vCPUs, 4 GB de RAM e 60 GB de SSD, enquanto catálogos maiores ou operações com campanhas frequentes costumam exigir 4 vCPUs, 8 GB de RAM e armazenamento NVMe. PHP-FPM, OPcache, MariaDB e Redis ajudam a aproveitar os recursos, mas precisam ser configurados de acordo com a memória disponível. Para compradores brasileiros, um datacenter próximo tende a reduzir a latência. Backup externo, monitoramento e testes de restauração continuam necessários mesmo quando o provedor oferece snapshots.

Resumo rápido

• Uma loja pequena pode começar com 2 vCPUs e 4 GB de RAM, desde que o catálogo e os módulos sejam leves.
• Lojas em crescimento ficam mais confortáveis com 4 vCPUs, 8 GB de RAM e pelo menos 100 GB de disco.
• PHP-FPM e MariaDB disputam memória, por isso a soma dos limites precisa caber na RAM da VPS.
• OPcache reduz recompilações de PHP, enquanto Redis pode armazenar cache e sessões.
• SSD atende operações básicas, mas NVMe ajuda em importações, índices e consultas com muita leitura e escrita.
• Datacenter no Brasil pode melhorar a latência, mas CDN e otimização do front-end continuam relevantes.
• Snapshot não substitui backup externo, versionado e submetido a testes de restauração.

Por que o PrestaShop exige uma VPS bem dimensionada

Catálogo, módulos e acessos simultâneos

O PrestaShop combina PHP, banco de dados, templates, imagens e módulos em quase toda requisição dinâmica. Uma visita à página de produto pode consultar preço, estoque, combinações, promoções, frete e regras de cliente antes de gerar o HTML. Isso torna a carga diferente de um site institucional. Dez pessoas navegando e filtrando produtos podem consumir mais CPU do que centenas de acessos servidos por uma página estática em cache.

O tamanho do catálogo interfere, mas não conta a história inteira. Uma loja com 3 mil produtos simples pode funcionar bem em 2 vCPUs e 4 GB de RAM. Já outra com 800 produtos, cada um com dezenas de variações, módulos de marketplace, busca avançada e cálculo de frete em tempo real, pode precisar de 4 vCPUs e 8 GB. Importações por CSV, reindexação da busca e geração de miniaturas também criam picos que não aparecem na média diária.

Módulos precisam entrar no levantamento. Um conector de ERP que sincroniza estoque a cada cinco minutos, por exemplo, adiciona consultas e processos em segundo plano. Outro caso comum é o módulo de pagamento que consulta uma API externa durante o checkout. Se essa integração demorar três segundos, aumentar a RAM não eliminará a espera. O diagnóstico deve separar consumo local de dependências externas.

Quem ainda está decidindo entre plataformas pode comparar essas características com um projeto de VPS para WooCommerce no Brasil. WooCommerce compartilha desafios de PHP e banco, mas seu comportamento muda conforme plugins e tema. Em operações maiores, a análise de uma VPS para Magento no Brasil também ajuda a entender por que plataformas de comércio eletrônico não devem receber a mesma configuração de um blog.

VPS tradicional e Cloud Server

Uma VPS tradicional normalmente oferece recursos virtuais alocados em um host físico. Um Cloud Server ou cloud instance pode acrescentar provisionamento rápido, API, redes privadas e redimensionamento simplificado, mas esses recursos variam por arquitetura e provedor. O nome comercial não garante alta disponibilidade. Para uma loja que aceita indisponibilidade curta durante manutenção, uma VPS única pode bastar. Para receita dependente de operação contínua, é preciso planejar redundância do banco, balanceamento e recuperação, não apenas trocar o rótulo do servidor.

Como dimensionar CPU, RAM e disco

Configuração inicial por perfil

O ponto de partida mais seguro é relacionar recursos ao trabalho executado. CPU atende PHP, compactação, tarefas agendadas e consultas que não cabem em cache. RAM acomoda sistema operacional, PHP-FPM, banco, Redis e cache de arquivos. Disco guarda aplicação, imagens, logs, banco e espaço temporário usado em importações e backups locais.

Perfil da loja	Catálogo e operação de referência	CPU e RAM iniciais	Disco sugerido	Observação operacional
Pequena	Até 5 mil produtos, poucos módulos e até 10 usuários simultâneos	2 vCPUs e 4 GB	60 a 80 GB SSD	Separar ao menos 15 GB para crescimento, logs e atualizações
Em crescimento	5 mil a 30 mil produtos, ERP e picos de 20 a 50 usuários simultâneos	4 vCPUs e 8 GB	100 a 160 GB SSD ou NVMe	Redis e monitoramento de consultas passam a ser recomendados
Catálogo grande	Mais de 30 mil produtos, muitas combinações e integrações	8 vCPUs e 16 GB	200 GB NVMe ou mais	Testar importações, busca e checkout com carga representativa
Operação crítica	Campanhas intensas, múltiplos workers e alto volume de pedidos	8 ou mais vCPUs e 16 a 32 GB	NVMe dimensionado pelos dados e retenção	Considerar banco separado, balanceador e redundância

Esses números são referências de planejamento, não garantias de tráfego. Uma instalação limpa pode responder bem com recursos menores, enquanto um módulo mal escrito satura 8 vCPUs. Em um servidor de 4 GB, uma divisão inicial razoável seria reservar aproximadamente 1,5 GB para MariaDB, até 1,5 GB para processos PHP, 256 MB para Redis e o restante para sistema, servidor web e cache de arquivos. Configurar cada serviço como se tivesse toda a memória provoca swap e lentidão.

Quando aumentar os recursos

O upgrade deve responder a métricas. CPU acima de 80% por vários minutos durante horários normais sugere investigar PHP, consultas e tarefas agendadas. RAM disponível constantemente abaixo de 10%, crescimento de swap ou processos encerrados pelo OOM Killer indicam falta de memória ou limites ruins. Disco acima de 80% exige ação antes de atualizações, pois uma implantação pode precisar manter arquivos antigos e novos temporariamente.

Considere uma promoção que eleva os acessos simultâneos de 15 para 60. Se o tempo de resposta cresce apenas nas páginas dinâmicas e todos os workers do PHP-FPM ficam ocupados, aumentar o limite de processos pode ajudar, desde que haja RAM. Se a CPU já está saturada, criar mais workers piora a fila. Em outro cenário, uma importação de 20 mil produtos pode exigir mais IOPS e espaço temporário, mas não justificar uma máquina maior durante o mês inteiro. Executar esse trabalho fora do horário de pico pode ser uma solução mais econômica.

PHP e servidor web para PrestaShop

PHP-FPM, OPcache e limites de execução

A versão do PHP deve ser compatível com a edição exata do PrestaShop e com os módulos usados. Não é seguro instalar automaticamente a versão mais nova sem validar a matriz oficial. Extensões como cURL, DOM, Fileinfo, GD ou Imagick, Intl, JSON, Mbstring, OpenSSL, PDO MySQL e ZIP aparecem com frequência nos requisitos de lojas PHP. A lista final precisa ser conferida na documentação correspondente à versão implantada.

O PHP-FPM controla quantas requisições PHP podem ser processadas ao mesmo tempo. Em uma VPS de 4 GB, começar com pm = ondemand, pm.max_children = 8, pm.process_idle_timeout = 10s e pm.max_requests = 500 reduz processos ociosos e recicla workers. Esses valores não são universais. Se cada processo consumir 120 MB, oito workers podem usar perto de 960 MB. Medir o RSS dos processos reais é melhor do que copiar configurações de outro servidor.

O OPcache evita recompilar os arquivos PHP em toda requisição. Uma configuração inicial pode usar 128 ou 256 MB de memória, opcache.max_accelerated_files = 20000 e validação de timestamps compatível com o processo de deploy. Em produção com implantação automatizada, a equipe pode reiniciar o PHP-FPM após cada versão. Em uma loja administrada manualmente, desativar completamente a validação sem um procedimento de limpeza pode manter código antigo em memória.

Nginx ou Apache

Nginx e Apache conseguem hospedar PrestaShop, mas a escolha muda a operação. Apache facilita ambientes baseados em .htaccess e pode ser mais familiar para equipes vindas de hospedagem compartilhada. Nginx costuma servir arquivos estáticos com baixo consumo e encaminha PHP ao PHP-FPM, porém regras de reescrita precisam ser configuradas no virtual host.

Um exemplo prático é definir client_max_body_size 64m no Nginx quando a equipe importa catálogos ou módulos grandes. No PHP, upload_max_filesize e post_max_size precisam ser iguais ou superiores. Para tarefas administrativas extensas, memory_limit = 512M pode ser necessário, mas isso não significa que cada worker deva consumir 512 MB. O limite é um teto. Se a equipe prefere administrar versões, SSL e bancos por interface, um servidor com painel de controle para VPS pode reduzir trabalho manual, desde que o painel não esconda logs nem aplique configurações incompatíveis.

Banco de dados, Redis e desempenho do catálogo

MariaDB e uso eficiente da memória

Grande parte da percepção de velocidade do PrestaShop depende do banco. Filtros, combinações, carrinho, regras de preço e consultas administrativas acessam tabelas que crescem com o catálogo e os pedidos. MariaDB ou MySQL devem usar versões compatíveis com o PrestaShop instalado. A configuração precisa considerar memória disponível, volume de dados e proporção entre leituras e escritas.

Em uma VPS com 8 GB dedicada à loja, um ponto inicial conservador pode reservar de 2 a 3 GB para o innodb_buffer_pool_size. Se o banco ativo tiver 1,8 GB, isso permite manter boa parte dos índices e páginas consultadas em memória. Reservar 6 GB apenas para o buffer deixaria pouco espaço para PHP, Redis e sistema. Em um servidor separado exclusivamente para banco, a proporção pode ser maior após medição.

Consultas lentas devem ser registradas por um período controlado. Ativar o slow query log com limite de um segundo durante uma janela de análise ajuda a encontrar módulos problemáticos, mas o arquivo precisa de rotação. Uma consulta executada 20 mil vezes com duração de 80 milissegundos também pode ser mais relevante do que uma consulta isolada de dois segundos. Ferramentas como EXPLAIN permitem verificar índices e quantidade estimada de linhas sem adivinhar a causa.

Cache de objetos e sessões

Redis pode reduzir leituras repetidas e armazenar sessões, desde que a integração seja compatível com a versão da aplicação. Em uma loja média, começar com 256 ou 512 MB e uma política de expulsão coerente é mais prudente do que permitir crescimento ilimitado. Redis não deve ficar exposto à internet. O serviço pode escutar apenas em 127.0.0.1 ou em uma rede privada protegida quando estiver em outro nó.

Há três exemplos úteis. Primeiro, páginas de categoria consultadas repetidamente podem se beneficiar de dados já armazenados em cache. Segundo, sessões em Redis facilitam múltiplos servidores web, pois o carrinho não fica preso ao disco de uma única instância. Terceiro, limpar todo o cache durante uma campanha pode criar uma avalanche de consultas no banco. A equipe deve aquecer rotas críticas ou fazer invalidação gradual.

Cache também pode esconder problemas. Se a primeira abertura de uma página leva quatro segundos e as seguintes levam 300 milissegundos, a experiência de novos produtos e URLs ainda está ruim. O objetivo não é apenas melhorar o melhor caso. É preciso medir páginas sem cache, carrinho, login, busca e checkout, que possuem menor possibilidade de cache integral.

Latência, rede e armazenamento no Brasil

Localização do datacenter

Para uma loja cujo público está majoritariamente no Brasil, hospedar em uma região próxima pode reduzir o tempo de ida e volta entre navegador e servidor. O ganho exato depende da operadora, rota, cidade do usuário e rede do provedor. Não existe uma redução fixa aplicável a todo acesso. Testes devem incluir diferentes conexões brasileiras, não apenas a fibra do escritório.

Uma página pode exigir dezenas de requisições. Mesmo com HTTP/2 ou HTTP/3, latência alta afeta HTML dinâmico, chamadas de API e etapas do checkout. Uma CDN aproxima imagens, CSS e JavaScript dos visitantes, mas normalmente não elimina a viagem até a origem para carrinho, estoque e pagamento. Hospedar fora do país pode continuar adequado quando a aplicação atende vários mercados ou depende de serviços localizados na mesma região. A decisão deve considerar o sistema completo.

Em um teste de aceitação, a equipe pode medir a página inicial, uma categoria, um produto e o checkout usando conexões de São Paulo, Recife e Porto Alegre. O p95, que representa um acesso mais lento que a maioria, costuma ser mais informativo do que a média. Também é útil separar tempo até o primeiro byte do tempo gasto com imagens e scripts.

NVMe, SSD e capacidade de transferência

SSD SATA atende lojas pequenas quando banco e cache cabem em memória. NVMe oferece menor latência de armazenamento e mais operações por segundo em cenários compatíveis, como importação de 50 mil produtos, reconstrução de índices e geração de miniaturas. Ele não corrige consultas sem índice, código lento ou API externa demorada. Qualquer afirmação de superioridade deve considerar benchmark com a mesma carga, CPU e configuração.

O espaço precisa incluir margem operacional. Uma loja com 35 GB de imagens, 8 GB de banco e 5 GB de aplicação não deveria usar um disco de 50 GB. Logs, cache, arquivos temporários e atualizações podem ocupar o restante rapidamente. Um volume de 100 GB seria mais seguro, com alertas em 70% e 85%. A franquia de transferência, a velocidade da porta e possíveis limites de uso justo também devem ser confirmados no plano antes da contratação.

Segurança, backup e operação da loja

Hardening básico do servidor

Uma VPS entrega controle administrativo, mas também transfere responsabilidades. O acesso SSH deve usar chaves, conta administrativa sem login direto de root e autenticação por senha desativada depois que o acesso por chave for testado. A porta SSH não precisa ficar aberta para toda a internet. Firewall, VPN ou lista de IPs reduzem a superfície de ataque, embora equipes com endereços dinâmicos precisem planejar um acesso de emergência.

No firewall, uma configuração simples libera 80 e 443 para visitantes, restringe 22 e bloqueia serviços internos. MariaDB e Redis não devem responder publicamente. Fail2ban pode limitar tentativas repetidas, enquanto atualizações de segurança do sistema precisam seguir uma janela definida. Atualizar sem teste no meio do horário comercial cria risco; ignorar correções por meses cria outro. Um ambiente de homologação reduz essa tensão.

O painel administrativo do PrestaShop deve usar HTTPS, senha exclusiva e autenticação adicional quando suportada. Módulos abandonados merecem atenção especial, pois executam código dentro da loja. Antes de instalar um módulo de frete, marketplace ou analytics, a equipe deve verificar manutenção recente, compatibilidade e permissões. Remover um módulo pela interface nem sempre apaga tabelas, tarefas agendadas ou arquivos residuais.

Backup testado e recuperação

Uma estratégia funcional protege banco, imagens, arquivos de configuração e código customizado. Para uma loja com pedidos diários, um backup completo por semana e incrementais diários talvez sejam insuficientes. O banco pode exigir cópias a cada hora ou recuperação ponto no tempo, conforme o volume de transações e o quanto a empresa aceita perder.

A regra 3-2-1 continua prática: três cópias dos dados, em dois tipos ou sistemas de armazenamento, com uma cópia fora do servidor principal. Snapshot ajuda antes de uma atualização, mas não substitui backup externo. Se a conta do provedor for comprometida ou o volume inteiro for removido, snapshots no mesmo ambiente podem ficar indisponíveis.

Um teste trimestral pode restaurar a loja em uma VPS isolada, trocar URLs de integração por endpoints de homologação e validar login, imagens, carrinho e pedidos. Registre o RPO, que define quanto dado pode ser perdido, e o RTO, que define quanto tempo a recuperação pode levar. Uma operação pequena pode aceitar RPO de 24 horas e RTO de 8 horas. Uma loja movimentada talvez precise de RPO de 15 minutos e RTO de 1 hora, o que muda arquitetura, ferramentas e custo.

Escalabilidade, monitoramento e troubleshooting

Métricas que justificam um upgrade

Escalar antes de medir costuma transferir o problema para uma máquina mais cara. O painel de monitoramento deve acompanhar CPU, load average, memória, swap, uso e latência de disco, espaço livre, tráfego de rede, processos PHP ativos, conexões do banco e tempo de resposta HTTP. Alertas precisam indicar uma tendência acionável, não disparar a cada pico de poucos segundos.

Em uma VPS com 4 vCPUs, CPU acima de 85% por dez minutos durante uma campanha pode justificar análise imediata. Se o PHP-FPM atingiu pm.max_children, há fila de requisições. Se ainda existe RAM e a CPU está abaixo de 60%, aumentar gradualmente os workers pode resolver. Se CPU e workers já estão no limite, otimização ou mais vCPUs fazem sentido. Quando o iowait sobe durante importações, o gargalo pode estar no disco.

Como localizar o gargalo

O troubleshooting deve seguir a requisição. Comece pelo tempo total no proxy ou servidor web. Depois verifique duração do PHP, consultas do banco, chamadas externas e entrega de arquivos. Uma página lenta apenas quando calcula frete aponta para integração ou rede. Lentidão em busca e categorias sugere consultas, índices ou cache. Falhas durante upload podem estar relacionadas a limites de PHP, Nginx ou espaço temporário.

Testes de carga devem usar rotas representativas e dados anonimizados. Um cenário pode simular 30 usuários navegando, cinco adicionando produtos ao carrinho e dois concluindo checkout. Testar apenas a página inicial superestima a capacidade. Durante o teste, registre p50, p95, taxa de erro e consumo por serviço. Claims de quantidade de usuários suportados só são publicáveis com metodologia, versão da aplicação, módulos, catálogo e infraestrutura documentados.

O crescimento também pode ser vertical ou horizontal. Subir de 4 para 8 vCPUs é simples, mas tem limite. Separar banco, Redis e workers ajuda a isolar cargas. Múltiplos servidores web exigem sessões compartilhadas, arquivos centralizados ou sincronizados e balanceador. Para muitas lojas, um servidor maior e bem monitorado é menos complexo do que um cluster prematuro.

Recomendações por perfil

Desenvolvedor solo e loja pequena

Para uma loja nova, com até 5 mil produtos e tráfego moderado, 2 vCPUs, 4 GB de RAM e 60 a 80 GB de SSD formam uma base razoável. Use uma versão Linux com suporte, PHP compatível, OPcache e MariaDB ajustado sem consumir toda a memória. Redis pode esperar até que as métricas mostrem benefício ou pode começar limitado a 256 MB. O desenvolvedor deve priorizar backup externo diário, monitoramento de disponibilidade e alertas de disco. Um painel pode facilitar certificados e bancos, mas consome recursos e precisa receber atualizações. Antes do lançamento, teste importação, checkout, e-mails e restauração em ambiente separado.

Equipe de e-commerce em crescimento

Uma operação com ERP, campanhas e catálogo entre 5 mil e 30 mil produtos deve considerar 4 vCPUs, 8 GB de RAM e 100 a 160 GB de SSD rápido ou NVMe. Separe filas e tarefas agendadas dos horários de pico. Redis com 512 MB, slow query log temporário e monitoramento de PHP-FPM ajudam a identificar gargalos. A equipe deve manter homologação semelhante à produção, controlar módulos por versão e documentar rollback. Backups de banco mais frequentes são adequados quando dezenas de pedidos entram por hora. Datacenter próximo do público e CDN podem trabalhar juntos, após testes de rota e cache.

Operação crítica ou loja de alto tráfego

Lojas que dependem de campanhas intensas, muitos acessos simultâneos ou integrações constantes podem começar a avaliação em 8 vCPUs, 16 GB de RAM e 200 GB de NVMe, mas o desenho final deve vir de teste de carga. Banco e Redis separados reduzem interferência entre serviços. Dois nós web atrás de balanceador aumentam a tolerância a falhas, desde que sessões, imagens e deploy sejam coordenados. Defina RPO e RTO com a área de negócio, monitore APIs de pagamento e frete e mantenha procedimento de contingência. A contratação deve considerar SLA, rede, suporte, snapshots e disponibilidade regional confirmados em fonte oficial, sem assumir que todo Cloud Server oferece redundância automática.