VPS para Magento no Brasil: guia técnico

Resposta direta

Para rodar Magento no Brasil com estabilidade, a VPS precisa ser dimensionada como infraestrutura de e-commerce, não como hospedagem comum. Uma loja pequena pode começar com 4 vCPUs, 8 GB de RAM, 80 GB de SSD ou NVMe, Redis, OPcache e backup externo. Lojas com catálogo grande, busca intensa, integrações de ERP, gateway de pagamento e campanhas de mídia normalmente exigem 8 vCPUs, 16 GB de RAM ou mais, banco de dados bem ajustado e cache em camadas. Datacenter no Brasil ajuda na latência para clientes nacionais, mas não substitui otimização de tema, imagens, PHP-FPM, MySQL ou MariaDB. Antes de contratar, confirme tipo de disco, política de backup, snapshots, bandwidth, localidade e suporte no site oficial do provedor.

Resumo rápido

• Magento costuma precisar de mais CPU e RAM que WordPress, WooCommerce ou lojas simples em PHP.
• Para produção básica, use como referência 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe.
• NVMe ajuda em operações de I/O, mas cache, banco de dados e tema continuam decisivos.
• Redis, OPcache e, em cenários maiores, Varnish reduzem carga no PHP e no banco.
• Backup externo, teste de restauração e snapshot antes de deploy são práticas essenciais.
• Datacenter no Brasil reduz latência para compradores nacionais, especialmente no checkout.
• Preço, regiões, storage e bandwidth mudam com frequência e devem ser revisados antes da publicação.

Por que Magento exige uma VPS mais robusta

Magento, hoje Adobe Commerce na edição empresarial e Magento Open Source na comunidade, é uma plataforma pensada para catálogos complexos, regras de preço, múltiplas lojas, cupons, integrações e fluxos de checkout mais elaborados. Isso traz flexibilidade, mas também aumenta o consumo de recursos. Uma página de produto pode acionar cache, sessão, banco de dados, Elasticsearch ou OpenSearch, extensões de pagamento, cálculo de frete e regras promocionais. Em uma hospedagem compartilhada, esse tipo de carga costuma esbarrar em limites de CPU, memória, processos PHP e I/O de disco.

Na prática, uma VPS para Magento precisa dar controle sobre versões de PHP, extensões, limite de memória, workers, cron jobs e serviços auxiliares. O Magento depende de tarefas agendadas para reindexação, envio de e-mails, atualização de estoque, geração de sitemap e processamento de filas. Se o cron roda atrasado ou disputa recurso com o checkout, o lojista pode ver produto sem atualização, pedido travado ou painel administrativo lento. O problema não é apenas tráfego. Uma loja com 300 visitas por dia, mas 25 mil SKUs e ERP sincronizando estoque a cada 15 minutos, pode exigir mais do servidor que uma loja com tráfego maior e catálogo enxuto.

Magento não se comporta como um CMS simples

Comparar Magento com um site institucional em WordPress quase sempre leva a erro de dimensionamento. Mesmo quando a loja tem poucos acessos, o painel administrativo, os índices, as extensões e o cache exigem margem. Se você já avaliou uma infraestrutura para WooCommerce, o guia de VPS para WooCommerce no Brasil ajuda como referência, mas Magento normalmente começa em um degrau acima. O WooCommerce pode funcionar bem em 2 vCPUs e 4 GB de RAM em lojas pequenas. Magento, para produção, fica mais confortável com 4 vCPUs e 8 GB.

VPS tradicional, Cloud Server e cloud instance

VPS tradicional costuma ser uma máquina virtual em um servidor físico, com recursos isolados por virtualização. Cloud Server ou cloud instance geralmente adiciona provisionamento mais flexível, painel com redimensionamento, imagens, snapshots e rede cloud, mas cada provedor implementa isso de um jeito. Para Magento, a diferença prática está em três pontos: facilidade de upgrade, previsibilidade de disco e qualidade da rede. Se a loja cresce em campanhas, datas sazonais ou live commerce, conseguir subir CPU e RAM com pouco atrito pode evitar uma migração emergencial.

CPU, RAM e NVMe: como dimensionar sem chute

O dimensionamento de Magento deve começar pela pergunta certa: o que consome recurso na sua loja? Tráfego importa, mas não é o único fator. Número de SKUs, quantidade de atributos filtráveis, extensões instaladas, tema, integrações, método de busca, volume de pedidos e frequência de reindexação mudam bastante o perfil de consumo. Uma loja B2B com 5 mil clientes logados, listas de preço e regras por grupo pode ter carga mais pesada no banco. Uma loja de moda com muitas imagens e variações pode pressionar disco, CDN e cache. Uma operação com marketplace ou ERP em tempo real pode sofrer mais em CPU e conexões simultâneas.

Como ponto de partida editorial, considere 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe para produção básica. Essa configuração costuma dar margem para PHP-FPM, Redis, banco de dados local e processos de cron em uma loja pequena ou média, desde que o tema esteja bem feito e o cache esteja ativo. Em homologação, 2 vCPUs e 4 GB de RAM podem bastar, mas não é uma referência segura para produção com checkout real. Em lojas maiores, 8 vCPUs, 16 GB de RAM e 160 GB de NVMe são mais adequados, principalmente quando o banco ainda roda na mesma VPS.

Configuração mínima realista

Uma configuração mínima realista para começar seria Ubuntu LTS, Nginx, PHP-FPM compatível com a versão do Magento, MariaDB ou MySQL, Redis para cache e sessões, OPcache ativo e limite de memória PHP entre 756 MB e 2 GB, conforme o caso. Em php.ini, valores como memory_limit=2G, realpath_cache_size=10M e opcache.enable=1 aparecem com frequência em ambientes Magento, mas precisam ser validados com a versão usada. Para PHP-FPM, um pool mal configurado pode derrubar a loja por falta de memória. Se cada worker consumir 250 MB e você abrir 30 processos, só o PHP pode tentar usar 7,5 GB.

O disco também merece cuidado. SSD SATA já é melhor que disco mecânico, mas NVMe costuma entregar menor latência e mais IOPS. Isso ajuda em cache, logs, sessão em disco, importação de produtos e banco local. Ainda assim, NVMe não salva tema pesado, query ruim ou extensão mal escrita. Para aprofundar o equilíbrio entre processador, memória e disco, o guia sobre como escolher CPU, RAM e NVMe explica como cada recurso afeta aplicações web na prática.

Quando subir para 8 GB, 16 GB ou mais

Suba para 16 GB de RAM quando o painel fica lento durante importações, o banco usa swap, o cache não segura picos ou o PHP-FPM precisa de mais workers para atender checkout e páginas de produto. Suba CPU quando há fila de requisições, tempo de resposta alto com cache aquecido ou cron concorrendo com visitas. Se o gargalo é banco, aumentar vCPU pode ajudar, mas índices, buffer pool, queries e separação do banco em outra instância podem trazer ganho mais consistente. O ideal é medir com htop, iostat, slow query log e métricas de aplicação antes de trocar de plano.

Cache, PHP-FPM e banco de dados no Magento

Magento sem cache bem configurado vira um teste de paciência. A plataforma foi desenhada para usar camadas de cache e, em produção, elas precisam estar ativas. Redis costuma ser usado para cache padrão, page cache e sessões, dependendo da arquitetura. OPcache reduz o custo de interpretar arquivos PHP a cada requisição. Varnish pode ser usado como full page cache na frente do Magento, especialmente em lojas com tráfego relevante e muitas páginas públicas. O ganho não deve ser prometido em porcentagem sem benchmark, mas a lógica é simples: quanto menos requisições chegam ao PHP e ao banco, mais previsível fica o servidor.

Um erro comum é contratar uma VPS forte e deixar PHP-FPM com valores padrão. Em uma loja com 8 GB de RAM, Nginx, Redis e banco na mesma máquina, você não deve liberar todos os recursos para PHP. Se MariaDB precisa de 3 GB para buffer e Redis usa 512 MB a 1 GB, talvez sobrem 3 GB ou 4 GB para PHP-FPM e sistema. Nesse cenário, configurar pm.max_children sem cálculo pode criar falta de memória. Um exemplo conservador: se cada processo PHP usa 220 MB em média e você reservou 3,5 GB para PHP, pm.max_children=15 é mais seguro que 40. Depois, ajuste com métricas reais.

Redis, Varnish e OPcache

Redis pode rodar na mesma VPS em lojas menores, mas deve ter limite de memória e política de eviction configurados. Usar maxmemory 512mb ou 1gb, conforme o plano, evita que o Redis cresça sem controle. Em ambientes maiores, Redis separado reduz contenção de recurso. OPcache deve ficar habilitado, com memória suficiente para o volume de código e extensões. Valores como opcache.memory_consumption=256 e opcache.max_accelerated_files=60000 aparecem em muitas instalações, mas a configuração final depende do projeto.

Varnish faz sentido quando a loja tem muito tráfego anônimo em categorias e produtos. Ele não resolve checkout lento, área logada pesada ou busca mal configurada, mas reduz bastante o número de requisições dinâmicas em páginas cacheáveis. Em campanhas de mídia, isso pode ser a diferença entre manter vitrine responsiva e sobrecarregar PHP-FPM. O ponto técnico é testar regras de cache com cuidado para não servir conteúdo personalizado a usuários errados.

MySQL ou MariaDB em produção

O banco de dados é uma das partes mais sensíveis do Magento. Se MySQL ou MariaDB roda na mesma VPS, reserve memória para buffer pool, conexões e logs. Uma loja pequena pode começar com innodb_buffer_pool_size entre 2 GB e 4 GB em uma VPS de 8 GB, mas isso depende do tamanho real do banco. Em 16 GB de RAM, reservar 6 GB a 8 GB para InnoDB pode fazer sentido quando o banco é local. Também ative slow query log em períodos de diagnóstico. Consultas lentas podem vir de extensões, relatórios, filtros de catálogo ou índices desatualizados.

Backups, snapshots e segurança operacional

Em Magento, backup não é um acessório. É parte do funcionamento seguro da loja. O servidor guarda código, mídia, configurações, logs e banco de dados, mas nem tudo tem o mesmo método de proteção. O diretório de mídia pode ter muitos gigabytes de imagens. O banco muda a cada pedido. O código deve estar versionado em Git. Misturar tudo em um único arquivo de backup diário sem teste de restauração cria uma falsa sensação de segurança. O lojista só descobre o problema quando precisa voltar um pedido, recuperar imagens ou restaurar depois de um deploy ruim.

Uma política simples e funcional pode combinar dump lógico do banco, cópia incremental de mídia, snapshot antes de mudanças grandes e retenção externa. Por exemplo: dump do banco a cada 6 horas em loja movimentada, backup diário de mídia, retenção de 7 dias para cópias recentes e 4 cópias semanais. O destino não deve ser apenas a própria VPS. Se o disco falhar, se a conta for comprometida ou se alguém apagar volumes por engano, o backup local pode sumir junto. Armazenamento objeto, outro servidor ou serviço gerenciado de backup reduzem esse risco.

Backup não é a mesma coisa que snapshot

Snapshot captura o estado do disco em um momento específico. Ele é útil antes de upgrade de Magento, atualização de extensão, mudança de PHP ou ajuste grande no banco. Só que snapshot não substitui backup versionado e externo. Se o provedor tiver indisponibilidade na região, se a conta for bloqueada ou se o snapshot estiver corrompido, você precisa de outra cópia. Também existe o ponto de consistência: snapshot de uma máquina com banco em escrita pode exigir flush, lock ou mecanismo apropriado para evitar restauração inconsistente.

Ao comparar provedores, confirme se backup automático existe, se é cobrado à parte, qual a retenção, se permite restauração granular e onde os dados ficam. O guia sobre VPS com backup automático detalha perguntas que ajudam a separar recurso de marketing de rotina operacional real. Para Magento, teste de restauração deve entrar no calendário. Um backup nunca testado é apenas uma hipótese.

Checklist de segurança para produção

A base de segurança começa no acesso SSH com chave, usuário sem login direto de root, firewall liberando apenas portas necessárias, atualizações do sistema e permissões corretas nos diretórios do Magento. Use TLS válido, proteja o painel administrativo com URL não óbvia e, quando possível, restrição por IP ou VPN. No banco, evite usuário com permissão ampla para tarefas que não precisam disso. Logs devem ser monitorados, especialmente erros 500, tentativas de login e picos de consumo. Para deploy, prefira pipeline repetível a alterações manuais em produção. Isso reduz erro humano e facilita rollback.

Brasil, latência e escolha do provedor

Para lojas que vendem principalmente no Brasil, a localização do datacenter influencia a experiência do usuário, sobretudo em páginas dinâmicas. Um servidor em São Paulo ou outra região brasileira pode entregar latência bem menor para compradores nacionais do que uma instância nos Estados Unidos ou na Europa. Essa diferença aparece no tempo de conexão, no checkout, em chamadas de API e no painel administrativo usado pela equipe. Porém, latência não é o único número. Uma loja mal cacheada em datacenter local pode ser mais lenta que uma loja bem otimizada fora do país com CDN, banco ajustado e páginas estáticas servidas no edge.

O ideal é separar tipos de tráfego. Imagens, CSS e JavaScript podem ir para CDN. Páginas públicas podem ser atendidas por Varnish ou full page cache. Checkout, carrinho, área do cliente e painel administrativo continuam dependendo mais do servidor de origem. Por isso, datacenter no Brasil costuma fazer mais diferença em operações com muitos usuários logados, B2B, integrações nacionais, antifraude, frete e pagamento. Se a loja vende para vários países, pode fazer sentido usar origem em uma região intermediária e CDN global, mas a decisão precisa olhar dados de analytics e logs.

Quando usar datacenter no Brasil

Use datacenter no Brasil quando mais de 70 por cento da receita vem de compradores nacionais, quando a equipe administrativa está no país ou quando integrações críticas também operam aqui. A redução de latência pode deixar o painel mais confortável e diminuir o tempo de resposta no checkout. Provedores com presença no Brasil, ou com regiões próximas e boa conectividade, devem ser avaliados por estabilidade, rede, tipo de armazenamento, suporte, backups e facilidade de upgrade. LetsCloud pode entrar na análise quando a prioridade for cloud com foco no mercado brasileiro, mas disponibilidade de NVMe, localidades como São Paulo, Fortaleza ou Miami, snapshots e políticas de backup precisam ser confirmadas por plano antes de qualquer afirmação editorial.

Como avaliar provedores sem cair em marketing

Evite escolher apenas pelo maior número de vCPUs no anúncio. vCPU compartilhada, geração do processador, limite de I/O, política de uso justo e qualidade do storage mudam muito o resultado. DigitalOcean, Vultr, Linode Akamai, AWS Lightsail, Hostinger, Locaweb, HostGator, Contabo e Hetzner atendem perfis diferentes, com regiões, painéis e modelos de suporte variados. Não publique comparação de preço sem revisão humana, porque valores, promoções e recursos mudam. Para Magento, a pergunta mais útil é: consigo fazer upgrade sem migração traumática, configurar firewall, restaurar backup, monitorar métricas e manter banco com baixa latência? Se a resposta for sim, o provedor entra na lista curta.

Tabela comparativa de configurações para Magento

A tabela abaixo não é uma promessa de desempenho. Ela serve como referência inicial para conversar com desenvolvedor, agência ou provedor. Magento varia demais conforme tema, extensões, cache, catálogo e integrações. Ainda assim, perfis ajudam a evitar dois erros comuns: contratar uma VPS pequena para produção real ou pagar por uma máquina grande sem corrigir gargalos básicos. Use os números como ponto de partida, depois valide com teste de carga, monitoramento e análise de logs.

Perfil de loja Magento	Recursos sugeridos	Serviços no ambiente	Quando faz sentido	Pontos de atenção
Homologação ou loja nova	2 a 4 vCPUs, 4 a 8 GB RAM, 60 GB SSD	Nginx, PHP-FPM, MariaDB local, Redis opcional	Testes, catálogo pequeno, baixo tráfego	Não usar como referência final de produção sem teste
Produção básica	4 vCPUs, 8 GB RAM, 80 a 120 GB SSD ou NVMe	Nginx, PHP-FPM, Redis, OPcache, banco local	Loja pequena ou média com cache ativo	Monitorar swap, cron, slow queries e uso de disco
Produção em crescimento	8 vCPUs, 16 GB RAM, 160 GB NVMe	Redis dedicado ou local, Varnish, banco ajustado	Catálogo maior, campanhas, integrações frequentes	Pode exigir banco separado se queries forem gargalo
Operação crítica	8 a 16 vCPUs, 32 GB RAM ou mais, NVMe, banco separado	App, Redis, Varnish, banco dedicado, backup externo	Alto faturamento, B2B, picos sazonais	Precisa de observabilidade, plano de rollback e teste de restauração

Em uma loja de produção básica, um desenho comum é manter tudo na mesma VPS, mas com limites claros: Redis com memória máxima, PHP-FPM calculado por consumo médio de worker, banco com buffer pool ajustado e logs rotacionados. Em uma loja em crescimento, separar banco ou Redis pode reduzir contenção. Por exemplo, se a importação de produtos usa muita CPU e trava checkout, talvez a solução não seja apenas mais RAM. Pode ser fila assíncrona, ajuste de cron, separação de serviços e reindexação fora do horário de pico.

Também pense no armazenamento de mídia. Uma loja com 20 mil produtos e várias imagens por SKU pode crescer rápido. Se cada produto tiver 5 imagens de 400 KB otimizadas, são cerca de 40 GB só de mídia. Some cache, logs, banco, backups temporários e releases antigos. Uma VPS de 80 GB pode ficar apertada em poucos meses. Nesses casos, usar armazenamento objeto para mídia ou limpar releases antigos com rotina controlada evita emergência por disco cheio. Magento com disco em 95 por cento de uso tende a falhar de formas estranhas, do cache ao upload de imagem.

Recomendações por perfil

Dev solo ou freelancer

Para dev solo, o melhor caminho é começar simples, mas não frágil. Uma VPS com 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe dá espaço para Magento, banco local, Redis e ambiente de deploy sem transformar cada ajuste em crise. Use Ubuntu LTS, Nginx, PHP-FPM, MariaDB, Redis e Git. Configure firewall, acesso SSH por chave e backup externo desde o primeiro dia. Se o projeto ainda está em desenvolvimento, uma instância menor pode servir para staging, mas produção deve ter margem. Documente comandos de deploy e restauração. Quando o cliente pedir uma extensão nova ou importação de catálogo, você vai precisar saber exatamente onde está o limite.

Time de e-commerce em crescimento

Para um time interno ou agência que cuida de uma loja em crescimento, a prioridade é previsibilidade. Pense em 8 vCPUs, 16 GB de RAM e NVMe para a aplicação, com Redis bem configurado e Varnish quando o tráfego público justificar. Se o banco começa a competir com PHP, avalie separar MariaDB ou MySQL em outra instância na mesma região. Crie ambientes distintos para produção e homologação, mesmo que a homologação seja menor. Integrações de ERP, antifraude, frete e marketplaces devem rodar com filas e logs claros. Antes de campanhas, faça teste de carga com cenários reais: home, categoria, produto, busca, carrinho e checkout. Não teste só a página inicial.

Operação em produção com faturamento relevante

Quando a loja depende do Magento para faturamento diário relevante, a VPS deixa de ser apenas custo técnico e vira risco operacional. Use arquitetura com separação de serviços: aplicação em uma ou mais instâncias, banco dedicado, Redis, Varnish, backup externo e monitoramento. Uma base inicial pode ter 8 a 16 vCPUs para aplicação, 32 GB de RAM no conjunto e storage NVMe, mas o desenho final precisa vir de métricas. Configure alertas para CPU sustentada, swap, disco, erro 500, fila de cron, replicação de backup e tempo de resposta. Tenha plano de rollback para deploys e teste restauração em ambiente isolado. Se uma hora de loja fora do ar custa mais que meses de infraestrutura, economizar no servidor pode sair caro.

Lojista não técnico com agência parceira

Se você é lojista e depende de agência, peça uma proposta que explique recursos, rotina de backup, prazo de restauração e responsabilidade de cada parte. Não basta receber uma linha dizendo VPS 8 GB. Pergunte se o backup inclui banco e mídia, se existe snapshot antes de deploy, quem monitora disco, quem aplica atualização de segurança e como é feito rollback. Peça também um relatório mensal simples com consumo de CPU, RAM, disco, erros e crescimento do banco. Isso evita surpresa em datas como Black Friday, Dia das Mães ou campanhas com influenciadores. Você não precisa operar Linux, mas precisa entender o risco que está comprando.

Caminho de evolução recomendado

Um caminho saudável é começar com VPS bem configurada, medir por 30 a 60 dias e evoluir por gargalo real. Primeiro, ajuste cache, PHP-FPM, banco, imagens e cron. Depois, aumente CPU e RAM se as métricas mostrarem necessidade. Em seguida, separe Redis, banco ou mídia quando houver ganho claro. Por fim, considere balanceamento, múltiplas instâncias ou serviços gerenciados se a operação justificar. Essa ordem evita gastar com complexidade antes de resolver o básico. Magento recompensa infraestrutura bem cuidada, mas pune improviso: disco cheio, backup não testado, extensão pesada e cron atrasado aparecem rápido no caixa da loja.