De qual plano de VPS eu preciso para o que executo?

Você já escolheu o app. Agora há quatro cards de planos na sua frente, com rótulos como Para apps leves e projetos individuais e Para apps em produção, enquanto a documentação do seu app fala em gigabytes e núcleos, e uma coisa não se encaixa sozinha na outra. O Immich, por exemplo, pede no mínimo 6 GB de memória, o que descarta o Stack 4 e seus 4 GB antes mesmo de você instalar qualquer coisa.

Cada linha abaixo coloca o que os desenvolvedores do app publicam ao lado do plano adequado. É uma estimativa nossa com base na documentação de cada fornecedor, consultada em 2 de outubro de 2026. Não rodamos esses apps em servidores da DreamHost, mas rodamos uma dupla comum na nossa própria máquina de teste, mais abaixo. Quando um fornecedor não publica nenhum número, a linha informa isso.

O que cada plano inclui

Os quatro planos incluem acesso root completo, o sistema operacional Linux de sua escolha, Docker e a biblioteca de apps com instalação em um clique. A diferença está nos núcleos, na memória e no disco:

Olhe a coluna de vCPU antes da memória. O Stack 8 dobra a memória e o disco do Stack 4, mas mantém as mesmas 2 vCPU, então um app com pouca CPU precisa pular para o Stack 16, o primeiro plano com mais núcleos. O Stack 32 dobra de novo, para 8.

Encontre seu app na tabela de dimensionamento

Encontre a linha mais próxima do que você roda. Comece pelo plano da última coluna. A coluna do meio mostra o que os desenvolvedores do app publicam, com links nas fontes abaixo. A página de Hospedagem VPS de cada app tem link abaixo da tabela.

Páginas de Hospedagem VPS de cada app da tabela: LAMP Stack, Node.js, PostgreSQL, Docker e Portainer, Dokploy, n8n, GitLab, Supabase, Immich, Pelican Panel, OpenClaw, Hermes Agent, Paperclip, Ghost, Umami, Uptime Kuma.

O mínimo do Immich é 6 GB, por isso o Stack 4 não aparece na linha dele, embora o Immich diga que um sistema de 4 GB consegue rodar com o aprendizado de máquina desativado.

Você não vai encontrar número de usuários na maioria das linhas, porque o GitLab é o único fornecedor aqui que publica um: a configuração dele para pouca memória foi pensada para até cinco desenvolvedores.

Apps no mesmo servidor dividem a memória dele, então some as linhas de cada um e deixe espaço para o sistema operacional. Coloque o n8n ao lado do Immich e os mínimos somam 10 GB antes de o sistema operacional pegar a parte dele, que foi de cerca de 300 MiB na nossa VM de teste com Ubuntu 24.04 recém-instalado. Isso é mais do que o Stack 8 oferece, então a dupla começa no Stack 16.

Quanto essa dupla usou na nossa VM de teste

Rodamos essa dupla em 22 de outubro de 2026, em uma VM de teste com 2 vCPU e 8 GB de memória, o formato do Stack 8. Era o Immich v3.3.5, na configuração de release do Immich, com aprendizado de máquina ativado e sem fotos, ao lado do n8n 2.44.5 com PostgreSQL, usando os arquivos Docker Compose do próprio n8n, sem workflows. A VM rodou em um Mac arm64, então é a nossa máquina de teste, não um servidor da DreamHost.

Em repouso, a dupla usou menos de 2 GB, bem abaixo dos 10 GB da soma dos mínimos. Mas o repouso não é o limite. Em uma execução separada, em uma máquina do mesmo tamanho, o Immich sozinho chegou a cerca de 6 GB enquanto processava uma importação de apenas 300 fotos. Somando os 0,4 GB do n8n em repouso a esse pico, chegamos a cerca de 6,4 GB, um cálculo nosso, já que não rodamos os dois sob carga ao mesmo tempo. Isso deixa pouca folga em 8 GB, e é por isso que ainda começamos a dupla no Stack 16. Rodamos cada configuração uma única vez, em instalações novas e sem usuários, então trate esses números como pisos, não como mínimos de dimensionamento.

O disco pode acabar antes da memória. Uma biblioteca de fotos ou um servidor Git pode enchê-lo enquanto a memória ainda parece normal.

Se você vai migrar uma biblioteca de fotos, meça o tamanho dela primeiro e acrescente a margem do Immich antes de comparar com o disco do plano. O número do GitLab cobre apenas a aplicação e, além disso, ele pede armazenamento para repositórios pelo menos do tamanho de todos os seus repositórios somados.

Apps cujos criadores pedem mais que o Stack 8

GitLab

O GitLab é o caso difícil. As próprias páginas dele indicam pisos diferentes. A página de requisitos do GitLab define 8 vCPU e 16 GB como configuração de referência para uma instalação em um único nó, e só o Stack 32 tem 8 vCPU. O Stack 16 tem os 16 GB, com metade dos núcleos. A mesma página diz que o GitLab consegue rodar com pelo menos 8 GB quando a memória é limitada, e esse é o único número de CPU ou memória da página que o Stack 8 atende. O guia para memória limitada vai ainda mais baixo: 2 GB mais 1 GB de swap para até cinco desenvolvedores cujos repositórios fiquem abaixo de 100 MB.

As duas páginas também divergem sobre o swap. Em uma instalação padrão, o GitLab orienta desativar o swap ou provisionar memória suficiente para que ele nunca seja usado, enquanto a configuração para pouca memória espera que o servidor use swap na operação normal. Para o servidor GitLab de uma equipe pequena, nossa orientação é o Stack 16, que oferece a memória de referência e 4 dos 8 núcleos, ou seja, fica abaixo da referência do GitLab, e um teste precisa mostrar que ele dá conta. O GitLab recomenda rodar os runners de CI em uma máquina separada da que roda o próprio GitLab. Planeje um segundo servidor para seus pipelines. Uma equipe que precisa da configuração de referência completa vai para o Stack 32. A Hospedagem VPS para GitLab inclui o GitLab CE em todos os planos Stack.

Supabase

A documentação de auto-hospedagem do Supabase considera o mínimo de 4 GB, 2 núcleos e 40 GB de SSD adequado para desenvolvimento e cargas de produção de pequeno a médio porte, e tanto o Stack 4 quanto o Stack 8 atendem a ele. A especificação recomendada pede 4 núcleos ou mais e, como o Stack 16 é o nosso menor plano com 4, é nele que rodaríamos um projeto de produção movimentado.

Immich

O Stack 8 atende à recomendação de 8 GB de memória do Immich com os 2 núcleos mínimos. O Stack 16 atende às duas recomendações. Os 250 GB de disco dele também comportam uma biblioteca maior do que os 150 GB do Stack 8, o que pode pesar tanto quanto a memória quando você importa anos de fotos de família e vídeos do celular.

Palworld e outros servidores de jogos

O guia de servidor do Palworld indica 16 GB de memória e recomenda 4 núcleos, então o Stack 16 atende ao requisito. O guia diz que um servidor de 8 GB inicializa, mas tem mais chance de travar quando a memória acaba, e é por isso que o Stack 8 não aparece na linha do Palworld. O guia também recomenda mais de 32 GB. O Stack 32 tem exatamente 32 GB e é o maior plano Stack, então um servidor de Palworld que precise da memória recomendada deve ficar em uma máquina dedicada.

O custo de começar grande demais

Se você começar pequeno demais, a solução é trocar de plano: você escolhe o plano maior no panel e seu ambiente vai junto. Para quem começa grande demais, não existe uma solução equivalente. A Central de Ajuda da DreamHost informa que, no momento, não é possível migrar para um plano Stack menor. Por isso, o caminho indicado é verificar se seus dados cabem, provisionar um novo servidor no plano menor, migrar tudo, confirmar que funciona e cancelar o original.

Até lá, você paga todo mês por memória e núcleos que seu app não usa. A Central de Ajuda da DreamHost diz que a VPS não inclui garantia de reembolso de 30 dias, então não há prazo de reembolso para recorrer. Comece pelo menor plano que atenda ao mínimo do seu app e troque de plano quando as verificações abaixo mostrarem que ele está ficando curto.

Como saber se seu plano ficou pequeno

Antes de pagar por um plano maior, descubra se o que está faltando é memória, CPU ou disco, porque cada um aponta para um upgrade diferente. A Central de Ajuda da DreamHost diz que os painéis Performance e Logs existem só na VPS gerenciada, então, em uma VPS, você verifica pela linha de comando enquanto o app está sob carga. Estes comandos fazem as verificações rápidas:

free -h
cat /proc/pressure/memory
uptime
df -h

1. Verifique a memória disponível

   Execute free -h durante o uso normal. A coluna available estima quanta memória novos programas conseguem obter sem usar swap. Se ela ficar perto de zero, ou se o uso de swap continuar subindo, o app provavelmente está com pouca memória. Os logs do app também mostram isso: o n8n registra JavaScript heap out of memory quando um workflow fica sem memória.

2. Verifique a pressão de memória

   Execute cat /proc/pressure/memory. A linha full mostra a fração do tempo em que todas as tarefas em execução esperaram por memória ao mesmo tempo, e a documentação do kernel diz que uma carga de trabalho que passa muito tempo nesse estado está em thrashing. Se for o seu caso, mude para o próximo plano para ter mais memória: do Stack 4 para o Stack 8, do 8 para o 16 ou do 16 para o 32.

3. Compare a carga com seus núcleos

   Execute uptime e leia o terceiro número, a média de carga dos últimos 15 minutos. A carga não é ajustada ao número de núcleos, então compare-a com as vCPUs do seu plano: 2 no Stack 4 e no Stack 8, 4 no Stack 16 e 8 no Stack 32. Como regra prática, consideramos que uma carga de 15 minutos que fica acima desse número por dias é sinal de que falta CPU. A partir do Stack 4 ou do Stack 8, isso indica o Stack 16.

4. Observe o tempo roubado (steal time)

   Execute vmstat 5 e observe a coluna st, que mostra o tempo que o hipervisor tirou do seu servidor. Como regra prática, se o steal ficar acima de alguns por cento, fale com o suporte antes de pagar por um plano maior.

5. Verifique o espaço em disco
   Execute df -h para ver o quanto cada sistema de arquivos está ocupado.
6. Faça o upgrade no panel

   A Central de Ajuda da DreamHost indica estes passos: acesse Manage Account, encontre sua VPS em Active Plans, clique em Manage, depois em Select Plan, na seção Change Plan, e em Submit Order.

O aumento do uso de swap também pode ser um alerta precoce. Como um comentarista do Hacker News observou, monitorar o uso de swap pode avisar que algo está errado antes de o kernel começar a encerrar processos por falta de memória.

Se um pico de tráfego estiver por trás da carga, leia sobre como lidar com um pico de tráfego antes de mudar de plano.

Quando outro produto da DreamHost é mais adequado

Se você prefere que nós gerenciemos o servidor, DreamPress, VPS gerenciada ou hospedagem de servidor dedicado gerenciado podem ser mais adequados. Se você não tem certeza se precisa mesmo de um servidor, comece por você precisa mesmo de uma VPS?.

O servidor dedicado gerenciado oferece um servidor gerenciado com root, e o plano Enhanced chega a 128 GB de memória. Por isso, leia quando um servidor dedicado é o próximo passo se o Stack 32 ficar pequeno para você. Para sites novos ou simples, a Hospedagem web é o ponto de partida, e o plano Launch comporta 25 sites e cerca de 40 mil visitas mensais estimadas. Se o que deixa lentos os sites da sua VPS gerenciada é um banco de dados MySQL, o complemento MySQL VPS oferece a ele recursos de banco de dados isolados, como um serviço separado.

Perguntas frequentes sobre dimensionamento de VPS