Como escolher a configuração de uma VPS (2026): o que 1 núcleo/1 GB, 2 núcleos/2 GB e 2 núcleos/4 GB conseguem rodar de fato

O que segue é uma recomendação de planejamento de capacidade, não uma promessa de desempenho do fornecedor. Modelo de CPU, nível de overselling, I/O de disco, rota de rede e configuração de software alteram o resultado.

Se você não quer fazer nenhuma estimativa de recursos, comece projetos pessoais diretamente com 2 núcleos/2 GB; se pretende rodar WordPress + banco de dados + Redis, ou cerca de 5 contêineres leves, 2 núcleos/4 GB costuma dar menos dor de cabeça.

Os "5 contêineres" aqui não são uma métrica rígida. Um contêiner Caddy ocioso e um serviço de busca Java podem diferir em consumo de recursos dezenas de vezes. O que realmente importa é o programa dentro do contêiner, não a quantidade de contêineres.

Muitos artigos gostam de escrever "WordPress mínimo 1 GB" ou "Docker mínimo 2 GB", que parecem certos, mas muitas vezes não são declarações oficiais.

1 GB de memória é mais adequado a projetos com "tarefa única, poucos serviços e dados pequenos".

Eu usaria para:

• Sites estáticos Nginx/Caddy;
• Páginas de navegação pessoal, páginas de status;
• Monitoramento leve como Uptime Kuma, sem muitos monitores;
• Pequenos bots de Telegram/Discord;
• Nós pessoais de WireGuard;
• Tarefas temporárias de desenvolvimento e linha de comando;
• Gateways de API leves que apenas encaminham requisições e não rodam modelos localmente.

Não recomendado para rodar simultaneamente em 1 GB:

• BaoTa/1Panel + WordPress + MySQL;
• Múltiplas tarefas de automação que exigem Chromium;
• Aplicações Java;
• GitLab, um conjunto completo de monitoramento ou uma plataforma de IA multisserviço;
• Ambientes Docker sem limite de tamanho de logs.

Se você já comprou 1 GB, pode usar ZRAM ou Swap para dar um buffer à memória de pico, mas eles não são memória grátis. A troca contínua vai deixar o disco mais lento e, no fim, você ainda precisará reduzir serviços ou fazer upgrade. Para a configuração específica, consulte: Como otimizar uma VPS de pouca memória com ZRAM e Swap (2026).

O sentido de 2 GB não é "o dobro de desempenho", mas que o sistema operacional, os logs, o banco de dados e as aplicações não precisam mais se espremer nos últimos cem MB.

Este nível é mais adequado para:

• Um único WordPress de baixo tráfego;
• Blogs pessoais como Typecho, Ghost;
• Caddy/Nginx + aplicação + banco de dados pequeno;
• 2–4 serviços Docker leves;
• Tarefas pequenas de Git, Webhook, automação;
• Ambientes de desenvolvimento e teste.

Ao rodar WordPress, eu limitaria a quantidade de plugins, ativaria o OPcache, limitaria os processos filhos do PHP-FPM e configuraria caches do MySQL adequados a uma máquina de pouca memória. À medida que o tráfego cresce, primeiro olhe as consultas lentas, as filas do PHP-FPM e a taxa de acerto do cache; não adicione núcleos às cegas assim que ficar lento.

Se você já está com 2 GB mas o WordPress continua lento, consulte: O que fazer quando o WordPress está lento em uma VPS (2026).

4 GB não vão deixar um site mais rápido automaticamente, mas abrem espaço para caches de banco de dados, Redis, tarefas de build e reinícios de contêineres.

Os usos comuns incluem:

• WordPress + MySQL/MariaDB + Redis + Caddy;
• 5–10 contêineres de baixa carga;
• Dois ou três sites com pouco tráfego;
• API Node.js/Python + PostgreSQL;
• Combinações como n8n, Directus, Uptime Kuma;
• Ambientes de teste de equipes pequenas.

"5–10" ainda é apenas uma faixa de planejamento para serviços leves. Quando os contêineres incluem navegadores, Elasticsearch, inferência de modelos ou grandes volumes de tarefas concorrentes, 4 GB também podem se esgotar rapidamente.

Este nível é adequado para quem não quer migrar toda vez que adiciona um serviço. Quando a diferença de preço mensal é aceitável, prefiro deixar cerca de 25% de folga de memória a ter a máquina rodando a 95% o ano todo.

O Docker Compose em produção também deve limitar os recursos por contêiner, para evitar que uma tarefa anômala derrube a máquina inteira: Como configurar o Docker Compose para produção em uma VPS (2026).

Ao chegar a 8 GB ou até 16 GB, a questão deixa de ser apenas "comprar maior".

Se a aplicação, o banco de dados, o armazenamento de objetos e os backups estiverem todos em uma única máquina, qualquer falha do sistema vai derrubar tudo junto. Quando o negócio começa a importar, considere:

• Separar aplicação e banco de dados;
• Colocar arquivos grandes em armazenamento de objetos;
• Colocar backups em outro provedor ou região;
• Usar instâncias por hora separadas para tarefas de build;
• Deixar um nó pequeno independente para monitoramento e páginas de status.

Escalar uma única máquina tem as vantagens da simplicidade e da baixa latência de rede interna; dividir tem as vantagens de limites de falha claros e escalonamento mais flexível. Projetos pequenos não precisam adotar um cluster complexo antecipadamente por "correção arquitetural", mas quando o banco de dados já consome metade da memória, é hora de fazer as contas com seriedade.

"4 núcleos" só indica quantos vCPUs foram alocados, não quão rápido é cada núcleo nem por quanto tempo você pode ocupá-los continuamente.

Antes de comprar, confirme pelo menos:

• Modelo e geração da CPU;
• CPU compartilhada ou dedicada;
• Se é possível ver steal time evidente;
• Se o fornecedor limita uso contínuo alto de CPU;
• ARM ou x86, e se o software é compatível.

2 núcleos de uma CPU nova de alta frequência podem compilar e responder a PHP com mais tranquilidade do que 4 núcleos compartilhados de uma plataforma antiga. Se a carga não muda no horário de pico da noite mas o desempenho cai visivelmente, verifique overselling e disputa com vizinhos: Como julgar o overselling de uma VPS (2026).

Planos ARM costumam ter preços atraentes, mas painéis de código fechado, imagens antigas e softwares que só distribuem binários amd64 podem não ser compatíveis. Antes de comprar, consulte: Vale a pena comprar uma VPS ARM? (2026).

20 GB parecem suficientes para o sistema e um site, mas imagens Docker, caches de build, bancos de dados, backups e logs vão consumindo isso aos poucos.

Eu reservaria:

• Sistema, pacotes e logs básicos: pelo menos 8–12 GB;
• Imagens Docker e camadas de contêineres: 10–30 GB adicionais conforme a aplicação;
• Banco de dados: planejar 2–3 vezes o volume atual de dados para crescimento e espaço temporário;
• Backups locais: não guardar apenas uma cópia, e muito menos tratá-la como backup externo.

Para bancos de dados e ambientes de contêineres, prefira SSD/NVMe. Com a mesma capacidade nominal, a escrita sustentada e a E/S aleatória podem diferir muito; após contratar para um negócio importante, você deve rodar fio, mas não faça testes destrutivos no horário de pico da produção.

Uma porta de 1 Gbps não significa dados ilimitados por mês. A porta é o limite instantâneo; o pacote de tráfego determina quanto pode ser transferido em um mês.

Uma estimativa simples:

月出站流量 ≈ 页面平均大小 × 月页面浏览量 × 未命中 CDN 的比例

Por exemplo, com tamanho médio de página de 1 MB e 100.000 visualizações por mês, tudo servido diretamente pela origem, são cerca de 100 GB. Se as imagens passarem por CDN e houver acertos de cache do navegador, o tráfego da origem será bem menor; vídeo, downloads e backups vão amplificar rapidamente o tráfego.

Quando o tráfego estiver apertado, monitore primeiro; não espere o e-mail de suspensão chegar: Monitoramento de tráfego de VPS e alertas de excesso de cota (2026).

A seguir está um snapshot da biblioteca de planos do Directus em 18 de julho de 2026, usado apenas para mostrar como os níveis de 1 GB, 2 GB e 4 GB se comparam, e não como aval de desempenho. Preços, estoque, rotas de rede e regras de renovação mudam; antes de pedir, prevalece a página de checkout.

Em planos baratos, preste ainda mais atenção à virtualização, reembolsos, renovações, data center e política de uso de CPU. Antes de comprar uma máquina anual pela primeira vez, é aconselhável procurar primeiro um plano mensal ou IP de teste para verificar a rota de rede; não importa quão barata seja a máquina, dados importantes precisam ter backups externos.

Não decida fazer upgrade com base em "está lento". Primeiro observe continuamente por vários dias, incluindo o horário de pico do negócio.

# 内存、可用内存和 Swap
free -h

# 每秒观察运行队列、换页和 CPU 等待
vmstat 1

# Docker 容器实时资源占用
docker stats

# 磁盘空间与文件系统
df -h

# 磁盘延迟、队列和利用率，需要安装 sysstat
iostat -xz 1

# 最近是否发生 OOM
journalctl -k --since "24 hours ago" | grep -i -E "oom|out of memory|killed process"

Os sinais de que você precisa fazer upgrade geralmente são:

• A memória disponível fica muito baixa nos horários de pico, com Swap in/out contínuo;
• Aparece OOM Kill nos logs;
• A CPU fica no máximo por longos períodos e a fila de execução permanece acima do número de vCPUs;
• iowait e a latência de disco permanecem altas;
• O espaço livre em disco fica abaixo de 15%–20%;
• Os contêineres reiniciam repetidamente por limites de memória;
• Os recursos continuam insuficientes após otimizar código, cache e consultas.

Um pico isolado não significa que você precise fazer upgrade. Backups, atualizações, compressão de logs e tarefas agendadas podem elevar brevemente a carga; julgue pela duração e pelo impacto no negócio.

• A carga de trabalho precisa de x86 ou é compatível com ARM;
• A CPU é compartilhada ou dedicada, e há limite de uso contínuo;
• A memória inclui Swap utilizável, e é possível fazer upgrade depois sem perda;
• O armazenamento é NVMe, SSD ou HDD;
• O tráfego é unidirecional, bidirecional ou ilimitado com uso justo;
• A largura de banda da porta é compartilhada, e como o tráfego excedente é cobrado;
• O IPv4 está incluído, e como IPs extras são cobrados;
• Qual é a rota no horário de pico noturno do data center até os usuários-alvo;
• Regras de reembolso, renovação, migração e troca de IP;
• Há console, modo de resgate, snapshots e backups;
• Você já testou o mesmo data center antes de pagar anualmente;
• Dados importantes têm um plano de recuperação externo.

Para apenas sites estáticos, monitoramento ou ferramentas pequenas, eu compraria 1 GB, desde que o serviço seja único, os logs estejam controlados e os dados tenham backup.

Para blogs pessoais e WordPress de baixo tráfego, eu começaria com 2 núcleos/2 GB; se pretendo instalar painel, Redis, múltiplos contêineres, ou não quero migrar de novo em alguns meses, iria direto para 2 núcleos/4 GB.

Quando o negócio chega a 8 GB ou mais, eu não olharia apenas para "uma máquina única maior", mas avaliaria também se o banco de dados, o armazenamento de objetos, os backups e o monitoramento deveriam ser separados. Escolher a configuração certa não é comprar o maior de uma vez, mas dar folga à carga atual sem ficar preso para upgrades futuros.