Resposta rápida: A recomendação é começar pelo plano VPS Brasil Básico (4 GB, 4 vCPUs, 100 GB NVMe, R$99/mês) e validar o fluxo real com dig +short app.exemplo.com. O tamanho correto depende de dados, concorrência e retenção; os comandos abaixo mostram como medir sem inventar uma métrica que não foi coletada.
Veja a infraestrutura: VPS com monitoramento e backup semanal para colocar este projeto no ar.
DNS na Cloudflare funciona melhor quando você separa o serviço público da operação interna: neste roteiro, o ponto de partida é uma VPS com 4 GB de RAM, 4 vCPUs e 100 GB NVMe para o cenário indicado. A primeira verificação usa dig +short app.exemplo.com e o objetivo é deixar claro o que pode ser afirmado, o que precisa ser medido e como voltar atrás. O conteúdo é para equipes pequenas e profissionais de infraestrutura e não apresenta teste executado na infraestrutura do leitor como resultado garantido.
O que este cenário resolve
Separar resolução dns, proxy e origem para saber qual camada está respondendo. A decisão central é tratar mudança de DNS e corte de uma aplicação para uma VPS como uma operação completa: aplicação, dados, identidade, logs, atualização e recuperação precisam ter responsáveis e sinais observáveis.
A pergunta operacional
Antes de instalar, escreva qual pergunta você quer responder. Em um domínio protegido por proxy que parece saudável, embora a origem esteja inacessível, não basta saber que o processo subiu: você precisa verificar o caminho que o usuário ou o operador realmente usará. Isso evita transformar um painel carregado, um handshake recente ou um backup verde em prova de saúde completa.
O que fica fora do escopo
Este artigo não promete latência, disponibilidade, throughput ou taxa de entrega sem medição local. Versões, plugins, tamanho dos dados, regras de rede e padrão de uso mudam o resultado. Use o procedimento como base, registre as saídas e só então ajuste o plano ou a configuração.
Recursos, portas e plano inicial
Para o recorte deste guia, o ponto inicial é o VPS Brasil Básico, com 4 GB, 4 vCPUs, 100 GB NVMe e preço de catálogo de R$99/mês. A porta ou portas relevantes são 53 para DNS e 80/443 para a origem web. Esses valores descrevem o catálogo e o desenho do laboratório; não são um benchmark do serviço.
O que medir no host
Registre RAM disponível, uso de CPU, espaço e inodes, processos, conexões e I/O antes e durante a operação. Para mudança de DNS e corte de uma aplicação para uma VPS, a medida mais útil é a que aparece na jornada central: fila e worker, consulta e restauração, resposta HTTP, rota privada ou evento de auditoria. Um número isolado não explica uma degradação.
Quando subir de plano
Considere o VPS Brasil Performance quando o conjunto pedir 12 GB e 6 vCPUs por causa de múltiplos serviços, dados persistentes ou tarefas concorrentes; o catálogo informa 150 GB NVMe e R$169/mês. O VPS Brasil Ultra oferece 20 GB, 8 vCPUs e 200 GB NVMe por R$269/mês. A troca deve seguir métricas e um plano de janela, não uma promessa genérica.
Comparação de escolhas
A comparação abaixo reduz uma decisão ampla a quatro camadas. Em mudança de DNS e corte de uma aplicação para uma VPS, a opção mais simples pode ser correta para um laboratório, mas a operação comercial exige atenção a persistência, acesso, evidência e retorno.
| Camada | Função | Decisão | Cuidado |
|---|---|---|---|
| DNS | resolve nome | retorna registros | não prova saúde da origem |
| Proxy | intermedia HTTP | oculta IP de origem | pode mascarar falha |
| Origem | serve aplicação | responde healthcheck | precisa firewall |
| TTL | cache de resolução | influencia troca | não controla todos os caches |
Passo a passo verificável
Execute uma etapa por vez e guarde a saída com data, versão, host e contexto. O comando de referência é dig +short app.exemplo.com, mas o critério de sucesso é o fluxo completo, não o fato de o comando existir.
- Faça inventário de A, AAAA, CNAME, MX, TXT e regras que dependem do host antigo.
- Teste a origem pelo IP autorizado e valide o certificado para o nome final antes de trocar o registro.
- Altere um registro por vez, acompanhe resoluções de mais de uma rede e mantenha o host antigo pronto para retorno.
1. Prepare o ambiente
Faça inventário de A, AAAA, CNAME, MX, TXT e regras que dependem do host antigo.
dig A app.exemplo.com
dig AAAA app.exemplo.com
dig MX exemplo.com2. Aplique a configuração
Teste a origem pelo IP autorizado e valide o certificado para o nome final antes de trocar o registro.
curl --resolve app.exemplo.com:443:IP_DA_ORIGEM -fsS https://app.exemplo.com/health3. Valide e registre
Altere um registro por vez, acompanhe resoluções de mais de uma rede e mantenha o host antigo pronto para retorno.
dig @1.1.1.1 +short app.exemplo.com
dig @8.8.8.8 +short app.exemplo.comErros comuns e como evitá-los
Erros operacionais quase sempre aparecem na fronteira entre camadas. Revise estes pontos antes de considerar o trabalho concluído:
Esquecer um registro aaaa apontando para o host antigo
Evite esquecer um registro AAAA apontando para o host antigo. Primeiro reduza a superfície exposta e confirme a rota de administração. Um serviço pode continuar funcionando em loopback ou rede privada sem uma porta pública adicional.
Alterar mx ao mesmo tempo sem testar e-mail
Não alterar MX ao mesmo tempo sem testar e-mail. Persistência, cópia independente e restauração são controles diferentes. Registre o arquivo, volume ou destino que realmente contém a informação necessária.
Confundir modo proxy com teste direto da origem
Também não confundir modo proxy com teste direto da origem. Faça a mudança com versão, janela, healthcheck e retorno documentado. Se houver migração irreversível, trate isso como uma decisão separada.
Esperar que ttl force todos os resolvedores a atualizar imediatamente
Por fim, não esperar que TTL force todos os resolvedores a atualizar imediatamente. A validação deve representar o uso real, incluindo falha, reinício, permissão e dependência. Caso contrário, você só confirmou que o processo iniciou.
Practical evidence, limites e rollback
A evidência deste roteiro é uma procedimento reprodutível: ambiente Linux, comandos explícitos, versões e dados devem ser registrados por quem executar o teste. O resultado a observar em mudança de DNS e corte de uma aplicação para uma VPS é o estado de cada etapa, a saída do comando e a resposta do fluxo central. Este lote não executou esses comandos na VPS do leitor, portanto não transforma o procedimento em medição de desempenho.
Antes de uma mudança, copie configuração e dados de forma recuperável. Depois, compare o estado esperado com o estado observado e preserve o último release ou dump válido. Se algo falhar, interrompa, restaure o componente anterior quando isso for seguro e reexecute o healthcheck. Não apague evidências durante o diagnóstico.
Checklist de aceite
Confirme nome e versão do software, portas públicas, permissões, volumes, espaço, logs, backup e caminho de recuperação. Registre o horário e o operador. Um checklist curto, repetível e ligado ao cenário é mais útil que uma promessa de disponibilidade sem método.
Perguntas relacionadas
Estas respostas condensam as dúvidas que normalmente aparecem antes do corte e apontam para a verificação que falta em cada uma.
DNS na Cloudflare funciona em uma VPS pequena?
Pode funcionar para um cenário enxuto, mas a decisão depende de RAM, CPU, armazenamento, concorrência e dependências. Comece com o plano VPS Brasil Básico e valide o fluxo real antes de ampliar.
Qual porta deve ficar pública?
Somente a porta necessária para o usuário ou túnel. Neste cenário, as portas relevantes são 53 para DNS e 80/443 para a origem web; componentes administrativos, bancos e filas devem ficar em loopback, VPN ou rede privada quando possível.
Como comprovar que a configuração funcionou?
Combine dig +short app.exemplo.com, logs e um teste de jornada. Registre status, versão, tempo, permissões e resultado. Um processo ativo isoladamente não comprova que a integração, os dados ou o rollback estão corretos.
Quando devo fazer upgrade?
Quando a medição mostrar pressão persistente, fila crescendo, OOM, I/O ou falta de margem para manutenção. Compare com o VPS Brasil Performance ou o VPS Brasil Ultra usando os recursos de catálogo, sem tratar preço como prova de desempenho.
Próximo passo
Se o seu cenário cabe no recorte deste artigo, o próximo passo é provisionar o VPS Brasil Básico (4 GB, 4 vCPUs, 100 GB NVMe, R$99/mês), executar o checklist em staging e registrar o resultado antes do corte. Conheça o VPS Brasil Básico e escolha a capacidade pelo uso observado.
Comentários (5)
Implementei essas configurações no VPS da minha empresa e reduziu nosso custo com cloud em 40%. O artigo está muito bem explicado, parabéns! Tem algum repositório GitHub de referência com esse setup?
Sempre tive problemas com instabilidade no servidor até ler este artigo. Segui passo a passo e agora está rodando perfeitamente há 3 semanas sem restart. Será que isso funciona também com ambientes híbridos?
Estou usando essa configuração no meu servidor há 2 meses e realmente melhorou a performance! O tempo de resposta caiu de 200ms para 30ms. Vou implementar também as dicas de otimização que você mencionou.
A latência para o Brasil ficou excelente depois que migramos para a VPS local. O tutorial de configuração de rede e MTU foi direto ao ponto. Em qual parte do artigo você recomenda focar para quem está começando em produção?
Muito bom o passo a passo de particionamento e disco NVMe. O throughput do I/O subiu consideravelmente nos nossos testes de benchmark.