VPS para desenvolvedores: ambientes de teste
O ambiente de testes existe para que o erro seja encontrado por você, e não pelos clientes. Ele deve ser parecido com a produção em software e configurações, mas pode ter metade dos recursos e durar poucos dias. Veja como deixar o ambiente barato, como manter várias versões num mesmo servidor e como evitar que a cópia do site apareça nos buscadores ou mande e-mails para clientes de verdade.
No desenvolvimento costuma haver três ambientes. Na máquina local, o programador escreve o código. No ambiente de testes (staging), a versão pronta é verificada em condições próximas às reais: o cliente vê a nova funcionalidade, o testador percorre os cenários, as migrações do banco de dados são conferidas. O servidor de produção (production) atende os usuários de verdade. Às vezes se acrescentam ambientes temporários para cada branch: neles se mostra uma única tarefa, e depois do merge eles são apagados.
O que no ambiente de testes deve coincidir com a produção
- Versões do software. O mesmo sistema operacional, as mesmas versões de PHP, Node.js, Python, banco de dados e servidor web. Erros que só aparecem em outra versão são as surpresas mais comuns na publicação.
- Configurações. A configuração do servidor web, o cache, os limites de upload, o fuso horário e as variáveis de ambiente, exceto senhas e chaves.
- Forma de publicação. O ambiente de testes é atualizado pelo mesmo script ou pipeline que a produção. Assim se testa também a própria publicação, e não só o código. Como montar esse pipeline está no artigo CI/CD na sua própria VPS.
O que pode ser diferente. Os recursos: para um ambiente com um ou dois usuários bastam 1–2 núcleos e 2–4 GB de memória, mesmo que a produção precise de 8 núcleos. O volume de dados: uma amostra anonimizada em vez do banco completo. Medir desempenho sob carga num ambiente reduzido não faz sentido: para isso é preciso um servidor com a mesma configuração da produção. Como fazer esse teste está explicado em Teste de carga do site antes do lançamento.
Ambientes curtos: cobrança por hora e snapshots
Um ambiente para mostrar uma tarefa ou testar uma atualização é necessário por alguns dias. Não é obrigatório pagar o mês por ele: com cobrança por hora, o valor é debitado enquanto o servidor existe, e depois que ele é apagado as cobranças param. Pelo catálogo da accsly.io em novembro de 2026, 173 dos 2.248 provedores com planos de VPS oferecem cobrança por hora. Neles, um plano com 1 núcleo e 2 GB de memória custa na mediana US$ 11 por mês, cerca de US$ 0,015 por hora, e uma semana de ambiente sai por uns US$ 2,60. Um ambiente com 2 núcleos e 4 GB custa US$ 24 por mês, cerca de US$ 0,033 por hora; três dias, uns US$ 2,30. Os preços estão em rublos no catálogo; aqui foram convertidos pelo câmbio de 7 de novembro de 2026 e arredondados. A conta de quando compensa e as armadilhas estão no artigo Cobrança por hora: quando ela compensa; os planos, na seleção VPS com cobrança por hora.
O snapshot do disco acelera a criação do ambiente. Configure o servidor uma vez, tire um snapshot e crie os novos ambientes a partir dele em minutos. Antes de apagar um ambiente que ainda será útil, tire um snapshot e apague o servidor: guardar o snapshot costuma ser mais barato que manter o servidor ligado, mas também custa. Um snapshot no mesmo provedor não substitui o backup; a diferença está explicada no artigo Backups de VPS: estratégias e ferramentas.
Se o provedor é novo para você, o ambiente de testes é um jeito prático de avaliá-lo antes de migrar o site de produção. Pelo catálogo da accsly.io em novembro de 2026, 247 provedores oferecem período de teste gratuito; as condições e limitações desses períodos estão no artigo Período de teste e reembolso.
Vários ambientes num servidor com Docker Compose
Se os ambientes são necessários o tempo todo, sai mais barato manter um servidor maior e rodar nele várias versões em contêineres. Por padrão, o Docker Compose lê compose.yaml e compose.override.yaml, e com a opção -f combina vários arquivos na ordem indicada (documentação do Docker). A parte comum é descrita uma vez, e no compose.staging.yaml ficam as diferenças do ambiente de testes: outras portas, limites de memória menores, variáveis de teste.
Cada ambiente sobe com um nome de projeto próprio: docker compose -p feature-123 -f compose.yaml -f compose.staging.yaml up -d. Projetos com nomes diferentes têm contêineres, redes e volumes próprios, então os ambientes não se atrapalham. Do lado de fora, um único servidor web ou proxy reverso os separa por subdomínio: feature-123.stage.example.com. Como preparar o servidor para o Docker e não lotar o disco com imagens está no artigo Docker em VPS: por onde começar.
Quantos recursos contratar: para cada ambiente com banco de dados, reserve 1–2 GB de memória e 5–10 GB de disco. Um servidor com 2 núcleos e 4 GB comporta dois ou três ambientes pequenos. Pelo catálogo da accsly.io em novembro de 2026, um plano assim custa na mediana US$ 21 por mês, e um quarto dos planos sai por menos de US$ 12,50. Um plano com 1 núcleo e 2 GB para um único ambiente custa US$ 11, e um quarto, menos de US$ 7. Seleções: VPS para ambiente de testes e VPS para Docker.
Como impedir que os buscadores indexem o ambiente
Uma cópia do site nos buscadores significa páginas duplicadas que concorrem com o site de produção e o vazamento do que ainda não foi publicado. Os métodos, do menos ao mais confiável:
- O robots.txt não protege. O Google diz claramente que o bloqueio no robots.txt não é uma forma de tirar uma página da busca: um endereço que recebe links pode aparecer nos resultados mesmo que o robô nunca o tenha visitado.
- noindex. A meta tag
<meta name="robots" content="noindex">ou o cabeçalhoX-Robots-Tag: noindexproíbem a indexação; o cabeçalho é mais fácil de aplicar ao ambiente inteiro na configuração do servidor web. Google e Bing o respeitam. O robô precisa ver essa proibição, por isso não se pode bloquear o ambiente no robots.txt ao mesmo tempo (documentação do Google). - Senha: a opção mais confiável. A autenticação básica no nginx é ativada com duas diretivas,
auth_basiceauth_basic_user_file, e o arquivo de senhas é criado com o utilitáriohtpasswd(documentação do nginx). A diretivasatisfy anylibera sem senha os endereços do escritório e pede senha aos demais. O robô não verá nenhuma página.
O nome do ambiente não é segredo. O Let's Encrypt publica cada certificado emitido nos logs públicos de Certificate Transparency, e neles aparecem todos os subdomínios para os quais houve certificado. Um certificado para *.stage.example.com esconde os nomes dos ambientes individuais, mas não substitui a proteção por senha. Como emitir esses certificados e configurar os subdomínios está nos artigos Certificados SSL: gratuitos e pagos e Domínios e DNS para quem tem servidor.
Dados e efeitos colaterais
- Não copie o banco de produção como está. Ele contém dados pessoais dos clientes, e o ambiente de testes é menos protegido que a produção. Anonimize nomes, telefones, e-mails e dados de pagamento ou monte um conjunto de teste. Pela LGPD e pelo RGPD, uma cópia com dados reais continua sendo tratamento de dados pessoais, com as mesmas obrigações; mais no artigo GDPR e a escolha de hospedagem.
- Desative o envio de e-mails e SMS. Um ambiente com cópia do banco pode mandar notificações a clientes de verdade. Direcione o e-mail de saída para uma caixa de captura de testes ou desligue-o.
- Pagamentos, só em modo de teste. Os meios de pagamento têm chaves e cartões de teste; as chaves de produção não são necessárias no ambiente de testes.
- Confira as tarefas agendadas. Exportações para marketplaces, sincronização com o CRM e chamadas a APIs externas pelo cron do ambiente de testes devem ir para ambientes de teste ou ficar desligadas.
- Chaves e senhas próprias. Prestadores de serviço e testadores recebem acesso ao ambiente de testes; nenhuma chave dele deve abrir o servidor de produção.
Ambientes esquecidos
Um ambiente esquecido custa dinheiro todo mês e, com o tempo, vira o ponto mais vulnerável: ninguém instala atualizações nele, as senhas são antigas, e a cópia do banco continua aberta para prestadores que saíram há muito tempo. Algumas regras ajudam a evitar isso:
- cada ambiente tem um responsável e uma data de remoção, registrados no nome ou numa etiqueta no painel do provedor;
- os ambientes temporários de branches são apagados pelo mesmo pipeline que os criou, depois do merge da branch;
- o ambiente permanente é atualizado junto com a produção e protegido da mesma forma: login só por chave, firewall, atualizações de segurança (Primeiros 10 passos depois de comprar uma VPS);
- uma vez por mês, compare a lista de servidores no painel do provedor com a lista de ambientes necessários e apague os que sobram.