Sair da hospedagem compartilhada: sinais e plano de migração

Resposta direta: Sair da hospedagem compartilhada: sinais e plano de migração funciona melhor quando você usa Linux, Nginx, PHP-FPM e banco da aplicação, mantém 80 e 443 sob controle e dimensiona o servidor para 4 GB de RAM, 4 vCPUs e 80 GB NVMe para um site WordPress inicial. Este guia mostra o procedimento, os limites e o critério para escolher uma VPS, indicado para sites que enfrentam lentidão, limites de processo ou indisponibilidade.

Veja a infraestrutura: VPS para WordPress no Brasil para colocar este projeto no ar.

O ponto mais importante é separar o que foi observado na configuração de referência do que precisa ser medido no seu ambiente. A prática operacional começa com um inventário de versões, portas, volumes e dependências. Não trate uma imagem de container, um comando copiado ou um preço como prova de que toda carga será igual.

O que você precisa preparar para Sair da hospedagem compartilhada

Resposta curta: prepare uma VPS Linux, acesso SSH, domínio quando houver tráfego HTTP e uma política de backup. A configuração de referência usa Linux, Nginx, PHP-FPM e banco da aplicação e reserva 4 GB de RAM, 4 vCPUs e 80 GB NVMe para um site WordPress inicial; se a aplicação dividir dados entre banco, fila e proxy, some os componentes antes de comparar planos.

Versões, portas e permissões

Fixe versões sempre que o serviço suportar essa prática e anote a data da instalação. As portas de referência são 80 e 443. A aplicação pública deve ficar atrás de HTTPS quando atender usuários ou receber credenciais. Banco e fila não precisam ser publicados para a internet apenas porque a aplicação precisa acessá-los.

Dimensionamento pelo servidor inteiro

O erro mais comum é olhar somente o consumo ocioso da aplicação. Em produção, o servidor também precisa manter o sistema operacional, o proxy, o banco, filas, logs e margem para picos. Para este artigo, a recomendação central é VPS Brasil Básico, com R$ 99/mês e 4 GB RAM e 4 vCPUs; em uma carga diferente, use métricas para confirmar o ajuste.

Como funciona a arquitetura e onde está o ganho de informação

Resposta curta: a arquitetura deve ter fronteiras claras entre entrada, processo, persistência e observabilidade. O ganho prático de diagnóstico antes da compra, staging e cutover reversível é tornar cada falha verificável: você consegue saber se o problema está no proxy, no processo, na fila, no banco ou no armazenamento, em vez de reiniciar tudo sem diagnóstico.

O fluxo de uma requisição

Quando uma requisição chega, o proxy ou a porta de entrada valida o caminho e encaminha para o serviço. O processo usa CPU e memória, o banco grava dados e a fila absorve tarefas que não precisam bloquear a resposta. Esse desenho facilita manutenção, mas cria dependências: o serviço pode estar “up” e ainda assim incapaz de processar um trabalho se o banco ou a fila estiverem saturados.

Limitação real que não aparece na propaganda

Uma VPS com mais recursos não corrige automaticamente uma consulta lenta, uma regra de firewall errada ou um volume sem backup. O procedimento deve registrar o limite conhecido e uma ação de retorno. Na operação, uma mudança pequena — como abrir uma porta extra ou atualizar uma imagem sem testar — pode criar um problema maior do que a falta de CPU.

Passo a passo para instalar e verificar

Resposta curta: atualize o sistema, instale os componentes, configure variáveis fora do código, suba a stack, valide o estado e só depois publique o domínio. Os comandos abaixo são uma base copiável; substitua valores marcados e revise-os antes de executar.

1. Preparar o sistema

1. Crie um usuário administrativo sem trabalhar como root o tempo todo.
2. Aplique atualizações e habilite o firewall com uma regra explícita para SSH.
3. Crie diretórios para volumes, logs e backups, com permissões mínimas.

sudo ufw allow 22/tcp
sudo ufw --force enable
sudo systemctl --failed

rsync -aHAX --info=progress2 ./site/ root@NOVO_IP:/var/www/site/
mysql -h NOVO_IP -u usuario -p banco < backup.sql
curl -I --resolve exemplo.com.br:443:NOVO_IP https://exemplo.com.br

2. Validar antes de abrir para o público

1. Confira o status dos processos e se as portas locais estão escutando.
2. Teste a rota pelo loopback ou por uma rede privada antes do DNS.
3. Leia os logs recentes procurando erro de credencial, migração ou conexão.
4. Faça um backup e registre o comando de restauração.

sudo ss -lntup
free -h
df -h
docker compose ps

O resultado esperado não é apenas uma tela carregando. Confirme que a persistência sobrevive a um restart, que o serviço não está reiniciando em loop e que o monitoramento consegue detectar uma falha. Se a aplicação tem worker ou webhook, teste também o caminho assíncrono.

Comparação de opções para Sair da hospedagem compartilhada

Resposta curta: escolha a opção que deixa explícitos controle, custo e responsabilidade operacional. A tabela abaixo resume o trade-off central de diagnóstico antes da compra, staging e cutover reversível; ela não substitui um teste da sua carga.

Como decidir sem escolher pelo menor número

Primeiro, defina o caso central: desenvolvimento, produção inicial ou múltiplos serviços. Depois compare RAM, vCPU, armazenamento, localização, suporte e preço de renovação. A decisão deve ser repetível: se a carga crescer, saiba qual métrica indica upgrade e qual plano atende a próxima etapa.

O que a tabela não resolve sozinha

Preço e especificação são apenas parte da decisão. Você ainda precisa avaliar backup, acesso, atualização, recuperação e caminho de suporte. A experiência prática mostra que a configuração que parece econômica no primeiro dia pode ficar cara se cada falha exige intervenção manual ou se não existe uma restauração testada.

Erros comuns e sinais de alerta

Resposta curta: os erros mais caros são expor componentes internos, ignorar logs, usar variáveis padrão, não reservar disco para dados e confundir “processo ativo” com “serviço saudável”. Corrija uma causa por vez e conserve uma forma de voltar à configuração anterior.

Falhas que parecem aplicação, mas são operação

• DNS aponta para o IP antigo ou ainda está em cache.
• Proxy encaminha para a porta errada ou não preserva o host.
• Volume não foi montado e o serviço iniciou com dados vazios.
• Memória acabou e o kernel encerrou um processo.
• Backup foi criado, mas nunca foi restaurado.

Uma dica de operação que costuma passar despercebida

Antes de alterar a stack, salve a configuração efetiva e a lista de imagens. Depois da mudança, compare o estado, os logs e o uso de recursos. Essa pequena trilha de evidência torna o rollback rápido e evita atribuir ao provedor um problema que nasceu de uma variável, uma permissão ou um arquivo de Compose diferente do esperado.

Perguntas relacionadas

Qual é o primeiro teste depois do deploy?

Verifique processo, porta, log e persistência. Em seguida faça uma requisição real e confirme que a resposta vem do serviço correto.

Preciso expor o banco ou a fila?

Normalmente não. Mantenha esses componentes em rede privada e permita acesso somente da aplicação.

Quando fazer upgrade?

Quando métricas de CPU, memória, disco, fila ou tempo de resposta mostrarem saturação recorrente, antes de a indisponibilidade virar rotina.

Como documentar a configuração?

Registre versões, portas, volumes, variáveis não secretas, backup e procedimento de retorno em um documento revisado.

Próximo passo: escolher a VPS adequada

Para o caso central deste artigo, a recomendação é o VPS Brasil Básico (R$ 99/mês, 4 GB RAM e 4 vCPUs). Ela é coerente com 4 GB de RAM, 4 vCPUs e 80 GB NVMe para um site WordPress inicial e deve ser reavaliada quando a carga, o número de usuários ou a retenção de dados mudar. Se o seu ambiente ainda estiver em teste, valide primeiro com dados não sensíveis.

Veja também testar a latência real de uma VPS e o restante do Blog You Secure para comparar práticas de operação. VPS Brasil Básico — escolher minha VPS por R$ 99/mês