Recomendações para escolher VPS
Recomendações de VPS para desenvolvimento e testes (2026): como escolher sem cair em armadilhas? Configuração, regiões, cobrança e checklist ao receber
Um VPS para desenvolvimento e testes não precisa ser "o mais potente", precisa ser "o mais tranquilo": cobrança por hora, snapshots, escalonamento a qualquer momento, rede estável e reinstalação quando quiser. Este artigo detalha por cenários reais de desenvolvimento (CI Runner, ambientes temporários, colaboração entre várias pessoas, depuração de API no exterior) e traz um checklist de seleção + passos de inicialização de 30 minutos ao receber, além de 5 links internos relacionados.
No assunto de VPS para desenvolvimento e testes, muita gente escolhe a direção errada logo de cara:
- Estoura o orçamento comprando "a configuração mais potente"
- Depois descobre que só usa duas vezes por semana
- Ou compra algo barato que não suporta snapshots ou cuja reinstalação é trabalhosa, e no fim tudo depende de aguentar na raça
A necessidade central de desenvolvimento/testes não é "configuração topo de linha", mas sim:
- Ligar e desligar a qualquer momento (de preferência com cobrança por hora)
- Reinstalar e reverter a qualquer momento (snapshots/backups)
- Rede que não seja absurda (sem perda de pacotes ou rotas indiretas o tempo todo)
Este artigo detalha por cenários reais: seguindo o checklist, você basicamente não cai em grandes armadilhas.
Desenvolvimento e testes costumam se encaixar nestas categorias:
- Rodar uma API / demo temporária
- Subir um banco de dados/Redis para testes de integração
- Testar uma configuração de Nginx/Caddy
Características: uso fragmentado, ciclo de vida curto.
- Runner do GitHub Actions / runner do GitLab auto-hospedado
- Compilar imagens, rodar testes unitários, rodar lint
Características: CPU e IO de disco importam mais que "largura de banda".
- Você precisa chamar serviços estrangeiros, fazer origin pull ou testar acesso do exterior
Características: escolher bem a região é mais importante que a configuração.
Muitos casos de "paguei caro / comprei errado" acontecem por não mapear o cenário aos recursos.
| Cenário | Configuração recomendada (inicial) | Armadilhas a observar |
|---|---|---|
| API / demo temporária | 1-2 vCPU / 1-2GB / 20-40GB SSD | O maior medo é não desligar; a cobrança por hora vira mensalidade |
| Docker + BD leve | 2 vCPU / 2-4GB / 40GB+ SSD | Imagens/logs enchem o disco com facilidade |
| CI Runner (máquina de build) | 2-4 vCPU / 4GB+ / 80GB+ SSD | O cache de build consome muito disco; IO importa mais que largura de banda |
| Programar remotamente (code-server) | 2 vCPU / 2GB+ / 40GB+ SSD | A experiência depende muito da instabilidade da rede (o teclado fica "travando") |
| Colaboração entre várias pessoas / vários serviços permanentes | 4 vCPU / 8GB+ / 80GB+ SSD | Sem segurança e backup, um único incidente já é bem chato |
Você pode tratar como uma regra:
- Sensível a "velocidade de resposta/interatividade": valorize mais estabilidade e instabilidade
- Sensível a "build/compilação": valorize mais CPU + disco
O que um ambiente de desenvolvimento mais teme é "quebrar a instalação".
- Reinstalação com um clique: você tem coragem de mexer
- Reversão por snapshot: você não teme que uma atualização dê errado
Ambientes temporários realmente não são usados por um mês inteiro.
- Hoje você sobe um para testar algo
- Amanhã você exclui
A cobrança por hora reduz o custo ao mínimo.
Em ambientes de desenvolvimento, muitas vezes não se trata de baixar arquivos grandes, mas da interatividade de SSH/HTTP.
O que você deve observar:
- Perda de pacotes
- Instabilidade de latência
Se você não tem familiaridade com diagnóstico de rede, salve este artigo primeiro:
Muitas armadilhas não são "você não sabe configurar", mas "o nó que você comprou não é adequado para você".
Execute este conjunto de comandos no VPS e você saberá rapidamente: se os recursos estão inflados, se o disco é pequeno demais, se a rede oscila e se o IPv6 funciona.
# 系统与资源
uname -a
uptime
free -h
df -hT
# 网卡与路由
ip a
ip r
# DNS 与基础连通
ping -c 3 1.1.1.1
# IPv4/IPv6 出站（有 IPv6 的机器建议测一下）
curl -4 -s https://api.ipify.org && echo
curl -6 -s https://api64.ipify.org && echo
Se você achar que "não entende essas saídas", não tem problema: pelo menos guarde os resultados para poder comparar rapidamente quando surgirem problemas depois.
Você não precisa testar todos os provedores.
Já existem pontos de entrada disponíveis no site (use links curtos de vendor conforme as regras):
- Vultr: cobrança por hora, ligar/desligar prático, adequado para ambientes temporários
- Racknerd: barato, adequado para testes/criação de sites em que "só precisa funcionar"
- Contabo: voltado à linha de discos grandes, adequado para quem prioriza recursos (mas não o trate como solução de baixa latência)
Como escolher? Em uma frase:
- Ambientes temporários/reconstrução frequente: priorize uma boa experiência de "ligar/desligar, snapshots, cobrança"
- Quem prioriza recursos/vários serviços permanentes: escolha "mais recursos pelo mesmo preço"
- Voltado à experiência de usuários na China continental: não olhe só o preço; veja primeiro a região/rota
No mínimo faça duas coisas:
- Permitir apenas login por chave
- Instalar Fail2Ban / firewall
Siga diretamente este artigo:
Para rodar serviços, Docker é o mais rápido.
O ambiente de desenvolvimento também se torna "semi-produção": arquivos de configuração, scripts, imagens privadas e até dados.
O desperdício de dinheiro que mais vi é: o ambiente já não é usado, mas a máquina continua rodando.
Você pode usar estas regras simples para controlar custos:
- Ambientes temporários: exclua a instância ao terminar (não deixe guardada)
- Ambientes permanentes: pelo menos pense bem na "política de retenção de disco/snapshots"
- Usuários intensivos de Docker: limpe periodicamente imagens/cache de build (não estoure o disco)
Limpar o Docker (atenção: remove recursos não utilizados, não use de qualquer jeito em máquinas de produção):
docker system df
# 确认没问题再执行
docker system prune -af
Se você troca de computador com frequência ou quer abrir o ambiente a qualquer momento, o Code-server é ótimo:
Se você ainda está em dúvida sobre "qual comprar", sugiro uma estratégia bem prática:
- Primeiro compre/subа um "o mais barato possível, mas que suporte snapshots/reinstalação"
- Rode seu fluxo de trabalho real (Docker, build, SSH, testes de integração de API)
- Decida em uma semana se vai atualizar a configuração ou trocar de região
O VPS para desenvolvimento e testes é, essencialmente, uma ferramenta.
O valor de uma ferramenta não é "ter especificações bonitas", mas sim ser tranquilo de usar.