Quanto de RAM e CPU sua VPS realmente precisa? Guia de dimensionamento por tipo de projeto

Escolher VPS olhando só o preço é o jeito mais rápido de tomar dor de cabeça depois

Ou você paga por um monte de recurso que nunca usa, ou aperta tanto que o servidor começa a travar no primeiro pico de acesso

O ponto é que RAM e CPU para VPS não se escolhem por chute, e muito menos pelo número que parece "bonito" no plano

Se dimensionam pela CARGA do seu projeto: um site estático não pede o mesmo que uma loja WooCommerce, e uma automação no n8n tem um gargalo totalmente diferente de um app Node com SSR

Então bora fazer isso do jeito certo, tipo de projeto por tipo de projeto, usando números reais em vez de achismo =)

Tabela de dimensionamento por tipo de projeto

Antes de entrar no detalhe, se liga nessa referência rápida pra bater o olho e já ter um ponto de partida

Hospedagem recomendada

Hospedagem que aguenta seu projeto crescer

Hospedagem rápida, painel simples, backups automáticos e suporte 24/7 em português.

Ver oferta

Essa tabela é o resumo

Agora vem o porquê de cada linha, que é onde tu realmente decide o plano sem desperdiçar nem criar gargalo

Dimensionamento detalhado por tipo de projeto

Site estático: 1 vCPU e 1 GB e tá ótimo

Se o teu projeto é HTML/CSS puro ou saiu de um gerador de site estático, relaxa

Esse tipo de site roda tranquilo com 1 vCPU e 1 GB de RAM

O motivo é simples: não tem PHP processando a cada visita, não tem banco de dados sendo consultado o tempo todo, o servidor só entrega arquivo pronto

É a carga mais leve que existe, e gastar mais que isso aqui é jogar dinheiro fora

WordPress: começa em 1 GB, mas mira 2 GB

Aqui a conversa muda, porque o WordPress processa PHP e conversa com banco a cada requisição não cacheada

O mínimo pra ele rodar é 1 GB de RAM

Porém "rodar" e "rodar bem" são coisas diferentes: com vários plugins ativos ou mais usuários simultâneos, o recomendado é pelo menos 2 GB

Um site institucional/padrão fica confortável com cerca de 2 GB de RAM

Se tu usa page builder pesado (aqueles de arrastar e soltar) ou monta site de membros, aí pede mais ainda

Agora, se tu já quer sair com folga em vez de ficar no osso, aplica a regra de dobrar (que eu explico mais pra frente): como a necessidade real de um WordPress gira em torno de 2 GB, um ponto de partida bem razoável em 2026 pra ele ou pra um app pequeno com tráfego moderado é 2 vCPUs e 4 GB de RAM

Repara que esses 4 GB não são uma necessidade nova, são a mesma necessidade de 2 GB com respiro por cima

No armazenamento, o mínimo recomendado é 10 GB SSD, mas eu miraria 20 GB SSD pra crescer sem apertar depois

WooCommerce: loja é outra fera

Colocar loja em cima do WordPress muda o jogo de novo, e pra pior no quesito recurso

Uma loja pequena precisa de pelo menos 2 GB de RAM

O recomendado pra loja rápida é de 2 a 4 GB, e lojas maiores pedem de 4 a 8 GB

E por que loja pesa tanto mais que um blog? Se liga nisso: o WooCommerce faz de 3 a 5 vezes mais transações de banco que um blog comum

Pior ainda, as páginas de carrinho e checkout NÃO podem ser cacheadas

Cada cliente que abre o carrinho bate direto em PHP + MySQL real, sem atalho de cache pra salvar

É por isso que loja que "funciona" com 2 GB no teste começa a engasgar quando cai gente de verdade comprando ao mesmo tempo

n8n e automações: RAM é o gargalo, ponto

Se o teu projeto é automação com n8n, muda o jeito de pensar

O n8n exige no mínimo 2 GB de RAM, mas o recomendado é começar já com 4 GB

Ambiente de produção pra valer pede 4+ núcleos e de 8 a 16 GB de RAM rodando com PostgreSQL

O detalhe mais importante aqui: no n8n o gargalo principal é a RAM, não a CPU nem o disco

Cada execução ativa segura o payload inteiro em memória

Um único workflow disparado por webhook com um JSON grande pode consumir sozinho de 150 a 300 MB

Agora imagina vários rodando junto… a memória some rápido

Se tu quer entrar fundo em quando aumentar CPU, RAM, SSD e IOPS, dá uma olhada nesse guia de dimensionamento de VPS para n8n que destrincha caso a caso

Apps Node: conta por processo

Com app Node a lógica é somar por processo, e o número depende MUITO do que tu roda

Um app Express básico usa de 50 a 150 MB de memória, bem enxuto

Já um app Next.js com SSR usa muito mais por causa da renderização React: de 200 a 500 MB POR processo

E aqui mora a pegadinha do PM2

No modo cluster do PM2 é criado um processo por núcleo de CPU

Então a RAM total não é a de um processo só, é a memória por processo multiplicada pela quantidade de núcleos

Ou seja: se cada processo Next.js segura uns 400 MB e tu tem 4 núcleos no cluster, são uns 1,6 GB só do app, sem contar o resto do sistema

Calcula isso ANTES de escolher o plano, senão o cluster que era pra dar performance vira estouro de memória

Servidor lento ou travando: quando faltou RAM

Agora o sintoma clássico: teu servidor tava voando e, sob carga, começou a ficar lento, instável, às vezes derruba tudo

Na maioria das vezes isso não é "CPU fraca"

É falta de RAM

A causa: quando a memória acaba, o servidor recorre ao swap em disco pra não morrer de vez

E o swap degrada MUITO o desempenho, porque o acesso a disco é de 100 a 1000 vezes mais lento que a RAM

É literalmente o servidor tentando usar o HD como se fosse memória, e travando no processo

Por isso jogar mais vCPU no problema costuma não resolver

Pra cargas majoritariamente I/O-bound (aquelas que ficam esperando uma query de banco ou uma chamada de API externa), adicionar vCPU dá retorno decrescente

A RAM é o gargalo típico de app web, e é nela que tu deve olhar primeiro

Como prevenir: some os componentes do teu stack em vez de chutar

Olha esse cálculo de memória de um WordPress como exemplo:

• SO: 300 MB
• Nginx: 50 MB
• 4 workers PHP-FPM: 300 MB
• Buffer do MySQL: 512 MB
• Redis: 256 MB
• Mais uns 20% de folga por cima

Isso dá cerca de 1,7 GB, que cabe confortável num plano de 2 GB

Viu como o número aparece da conta, e não do "acho que dá"?

E tem a regra de folga que eu sigo religiosamente: se tu precisa de 2 GB hoje, escolhe 4 GB

Se precisa de 4 GB, escolhe 8 GB

Começar pequeno demais custa tempo e estabilidade, e migrar depois no aperto é sempre pior

Pra fechar o ciclo e não ficar no escuro, vale acompanhar o consumo real: dá pra medir a performance do n8n na VPS olhando CPU, RAM, concorrência e filas, e a mesma lógica de monitorar antes de reajustar serve pra qualquer stack

Conclusão

No fim das contas, dimensionar RAM e CPU para VPS é sobre a CARGA real do teu projeto, não sobre o preço nem sobre o número que parece grande

Site estático vive com 1 vCPU e 1 GB, WordPress institucional pede uns 2 GB, WooCommerce escala de 2 a 8 GB conforme a loja, e automação no n8n começa em 2 GB mirando 4 GB

Na dúvida entre CPU e memória, prioriza RAM: é ela que vira gargalo e joga teu servidor pro swap quando aperta

O próximo passo prático é bem direto: estima os componentes do teu stack somando um por um, escolhe o plano com folga (dobrando a necessidade atual) e monitora o uso pra reajustar quando o projeto crescer

Assim tu não paga pelo que não usa, nem trava no primeiro pico

até o próximo post!