Recomendações para escolher VPS
Recomendações de VPS grátis (2026): guia aprofundado de servidores em nuvem gratuitos permanentes e de teste (com checklist de aceitação de 7 dias e migração)
A verdadeira dificuldade de um VPS grátis não está em "conseguir ou não", mas em "conseguir rodar de forma estável pelo período que você precisa". Este artigo decompõe o gratuito permanente e os testes por tempo limitado em uma árvore de decisão executável: primeiro avalie por cenário, depois filtre por orçamento de risco, em seguida valide com um script de aceitação de 7 dias e, por fim, cubra com um plano de migração. Ao terminar, você saberá quais cargas de trabalho podem ficar na camada gratuita e quais precisam migrar para a camada paga o quanto antes.
Começo pela conclusão:
Um VPS grátis pode ser usado, mas apenas como "camada de validação", nunca como "camada de entrega".
Já vi muita gente tratar uma máquina gratuita diretamente como host online. As duas primeiras semanas são ótimas, mas a partir da terceira começam a sofrer com cotas, controles de risco e oscilações de rede, e no fim a migração sai mais cara e mais bagunçada do que comprar desde o início um VPS pago de baixo custo.
Este artigo não traz rankings esotéricos; entrega diretamente um framework executável:
- Como distinguir "grátis permanente" de "teste por tempo limitado"
- Como julgar se a camada gratuita realmente combina com você
- Como fazer uma aceitação de 7 dias para evitar o "parece que roda"
- Quando migrar decididamente para um VPS pago
Muita gente junta todos os recursos gratuitos em uma única categoria. Esse é o primeiro erro.
| Tipo | Forma comum | Uso típico | Maior risco |
|---|---|---|---|
| Cota gratuita permanente (Always Free) | Instâncias/armazenamento/cota de funções de especificações pequenas fixas | Aprender Linux, scripts leves, PoC | Especificações pequenas, restrições regionais, escassez de capacidade imprevisível |
| Créditos de teste por tempo limitado (Trial Credits) | Crédito de 30-90 dias | Testes de carga de curto prazo, projetos de curso, validação técnica | Termina ao vencer; interrupção se você não migrou |
| Recursos educacionais/para estudantes | Cota ou benefícios de ferramentas após verificação de estudante | Projetos de estudantes, experimentos de curso | Há barreiras de verificação e renovação; os benefícios podem mudar |
| Brindes da comunidade/campanhas de marketing | Crédito de teste único | Demonstrações temporárias | Regras que mudam rápido, baixa sustentabilidade |
Se o seu objetivo é "rodar a longo prazo um blog/API/serviço principal", assuma por padrão: a camada gratuita é apenas uma transição, não a meta.
2) Primeiro avalie o cenário: quais cargas de trabalho podem ficar na camada gratuita e quais não podem?
Esta etapa importa mais do que "qual provedor escolher".
| Cenário de carga de trabalho | A camada gratuita é razoável? | Motivo | Sugestão |
|---|---|---|---|
| Aprender Linux, praticar comandos | Razoável | Alta tolerância a interrupções | A camada gratuita basta |
| Tarefas de curso, demo de projeto de conclusão | Razoável (com plano de migração) | Duração controlável | Primeiro grátis, depois pago |
| Ambiente de teste temporário | Razoável | Necessidade de curto prazo | Vincular backups automáticos |
| Blog pessoal (pouco tráfego) | Mal viável | Requisitos de disponibilidade médios | Melhor preparar uma alternativa paga de baixo custo |
| API de produção voltada a usuários | Não recomendado | Altos requisitos de disponibilidade e estabilidade | Direto para a camada paga |
| Site comercial/negócio de clientes | Não recomendado | O custo do risco supera em muito o custo da máquina | Pago + monitoramento + backups |
Minha própria experiência: assim que você começa a se preocupar com SLA, janelas de falha e tempo de recuperação, a camada gratuita deve ir para segundo plano.
O que mais engana no "grátis" é que a cobrança e a estabilidade não estão na mesma dimensão.
- Cobrança após ultrapassar a cota de tráfego de saída (egress)
- Armazenamento de snapshots/backups cobrado à parte
- Logs, monitoramento, NAT e IP elástico podem gerar cobranças extras
- Após o vencimento dos créditos de teste, os recursos que continuam rodando passam a ser cobrados por uso
- As especificações gratuitas podem ter oferta apertada em regiões populares
- Quando os controles de risco da conta são acionados, as instâncias podem ser congeladas ou restringidas
- Nos horários de pico a disputa por CPU é evidente; a oscilação é maior do que você imagina
- Sem plano de migração, no dia em que o teste termina você fica "forçado a cair"
- Sem backup, a configuração se perde ao reconstruir a instância
- Mudanças de IP público bagunçam as listas de permissão e o DNS
Desses três tipos de risco, o realmente fatal é o operacional, porque ele explode quando você está mais ocupado.
Você pode executar exatamente assim.
uname -a
nproc
free -h
df -h
ip -br a
curl -4 ifconfig.co || true
curl -6 ifconfig.co || true
Objetivo: confirmar as especificações da máquina, o disco disponível e a situação de IPv4/IPv6.
# 本机 -> VPS
traceroute -n <VPS_IP> | head -n 20
mtr -rwzc 200 <VPS_IP>
Objetivo: registrar a latência média, o percentil 99 e a perda de pacotes; não olhe apenas um resultado.
Se você não sabe interpretar esses resultados, comece por:
- Testes de carga em horários fixos (dia + pico da noite)
- Observe se CPU, memória e IO de disco apresentam picos prolongados
- Registre a proporção de "falhas recuperáveis" e "falhas não recuperáveis"
No mínimo faça:
- Login SSH por chave
- Desativar login direto de root e login por senha
- UFW com o mínimo de portas abertas
- Bloqueio básico com Fail2Ban
Se você nunca fez isso, pode seguir diretamente este artigo:
Você precisa verificar duas coisas:
- Se o backup pode ser restaurado
- Se você consegue migrar para um novo host em 30-60 minutos
Se você não consegue fazer essas duas coisas, a camada gratuita não é "economia" para você, mas sim "adiamento de dívida".
No mínimo mantenha:
- Inventário de serviços (portas, dependências, variáveis de ambiente)
- Scripts de implantação (Docker Compose / Ansible / Shell)
- Scripts de backup e de restauração de dados
- Passos de troca de DNS (TTL, ponto de reversão)
5.2 Linhas vermelhas que disparam a migração (recomendado colar diretamente na sua documentação de operações)
Migre se qualquer uma for atendida:
- Oscilação evidente no pico da noite por 2 dias consecutivos
- Os custos de tráfego de saída começam a ficar incontroláveis
- Os controles de risco da conta são acionados com frequência
- Os picos de tráfego do negócio já ultrapassam as especificações gratuitas
Primeiro busque uma camada paga estável e de baixo custo; não parta direto para especificações altas:
Se você não tem certeza do limite de orçamento, comece por:
- Recomendações de VPS baratos (2026): como escolher por menos de $3 por mês?
- Análise do custo real de um VPS (2026)
P1: O seu negócio permite 1-2 interrupções?
- Sim -> vá para P2
- Não -> diretamente VPS pago
P2: Você consegue concluir a migração em 1 hora?
- Sim -> a camada gratuita é utilizável (curto prazo)
- Não -> primeiro complete o plano de migração e depois coloque no ar
P3: Você vai gerar tráfego público continuamente?
- Sim -> fique de olho principalmente no custo de egress
- Não -> a camada gratuita pode continuar em observação
P4: O seu negócio é voltado a usuários reais?
- Sim -> migre para a camada paga o quanto antes
- Não -> a camada gratuita continua como camada de experimentação
Se você quer começar hoje, sugiro esta ordem:
- Primeiro pegue a camada gratuita para uma validação de 7 dias
- Configure a segurança e os backups ao mesmo tempo
- Faça um ensaio de migração no dia 7
- Quando houver usuários acessando, priorize a migração para uma camada paga de baixo custo
Assim você aproveita o benefício do "teste e erro grátis" sem entregar o destino do seu negócio à incerteza.
A forma correta de usar um VPS grátis não é "aproveitar até o fim", mas sim "validação de baixo custo + migração controlável".