Como escolher seu primeiro plano de VPS (sem pagar demais)

Comece pela carga de trabalho, não pelas specs

Antes de comparar vCPUs e gigabytes, anote o que o servidor vai realmente rodar. Um site pessoal e um reverse proxy? Uma API em Node ou Python? Um bot do Telegram? Alguns cron jobs? Cada um desses usos tem uma pegada muito diferente, e é essa lista — não a página de preços — que deve orientar sua escolha.

Seja honesto também sobre a concorrência. Um blog lido por algumas centenas de pessoas por dia e uma API consultada a cada segundo por um app mobile são bichos bem diferentes, mesmo que ambos pareçam 'projetos pequenos'. Quando a carga de trabalho fica clara, o plano certo costuma se escolher sozinho.

A RAM costuma ser a restrição de verdade

Em servidores pequenos, a RAM quase sempre acaba muito antes da CPU. Cargas web passam a maior parte da vida esperando a rede, mas cada processo que você roda segura sua memória o tempo todo. Quando a RAM acaba, o kernel começa a matar processos — e é assim que um ₹ economizado no plano vira uma queda às 2 da manhã.

Você não precisa de números exatos, só de estimativas honestas. Estas regras práticas cobrem a maioria dos primeiros servidores:

• Um site estático ou reverse proxy fica satisfeito com ~512MB–1GB
• Uma API em Node ou Python normalmente pede 1–2GB
• Um banco de dados pequeno na mesma máquina soma pelo menos mais 1GB
• Docker tem sobrecarga própria — reserve RAM extra por contêiner, não só por aplicação

CPU e comportamento em rajadas

vCPUs compartilhadas assustam mais do que deveriam. A maioria das cargas web funciona em rajadas: uma requisição chega, a CPU dispara por alguns milissegundos e volta a ficar ociosa. Núcleos compartilhados foram feitos exatamente para esse padrão, e para a imensa maioria dos sites, APIs e bots eles são indistinguíveis de núcleos dedicados — por uma fração do preço.

O que vale a pena vigiar é a carga sustentada. Se o seu trabalho prende um núcleo por minutos seguidos — codificação de vídeo, builds pesados, geração de relatórios grandes — uma vCPU compartilhada vai parecer limitada. Olhe os gráficos de CPU depois do lançamento: picos ocasionais são normais; uma linha reta perto de 100% significa que chegou a hora de mais núcleos.

Disco, banda e as coisas que todo mundo esquece

O disco enche de formas que ninguém planeja. Logs da aplicação crescem em silêncio por meses, backups se acumulam ao lado dos dados que protegem, e uploads de imagens dos usuários só aumentam. Um disco de 25GB que parecia generoso no primeiro dia pode estar cheio no sexto mês — então configure a rotação de logs cedo e saiba onde ficam seus diretórios grandes.

A melhor solução é tirar os arquivos volumosos e estáticos do VPS por completo. Mova imagens, uploads e backups para um armazenamento de objetos como o Nest Storage: os buckets crescem sem reparticionar nada, seu disco fica enxuto e a banda usada para servir mídia deixa de competir com o app. Seu VPS deve guardar código e dados quentes — não a sua biblioteca de mídia.

Comece pequeno, redimensione depois

Aqui está a parte que economiza dinheiro: na Anested Cloud você redimensiona um VPS no lugar, então fazer upgrade depois é melhor do que comprar demais agora. Pegar um plano grande 'por via das dúvidas' significa pagar todo mês por RAM que fica vazia. Começar pequeno significa pagar pelo que usa e subir de plano no dia em que os gráficos pedirem.

Então comece no nível gratuito ou no menor plano, faça o deploy da sua carga real e meça por uma ou duas semanas. Se a memória ficar confortavelmente abaixo do limite e a CPU só der picos, pronto — você achou seu plano. Se não, redimensione em dois cliques e volte a construir. Esse é o framework inteiro: carga primeiro, RAM com honestidade, medir, redimensionar.