Hospedagem: Compartilhada, VPS ou Cloud, Qual Serve para Você

Hospedagem é o item que mais gera arrependimento silencioso num projeto de site. Ninguém pensa nela na hora de decidir, todo mundo pega a mais barata, e o assunto só volta à mesa quando o site cai numa segunda-feira de manhã ou quando o desenvolvedor diz que não consegue instalar o que precisa.

A escolha não é difícil. O que atrapalha é o vocabulário de marketing das empresas do setor, que vende "cloud ilimitado" e "SSD turbo" sem explicar a única coisa que importa: quanta máquina você está alugando e quanto controle tem sobre ela.

O que você realmente compra quando contrata hospedagem

Você está alugando quatro coisas ao mesmo tempo, e planos diferentes trocam uma pela outra:

1. Recursos computacionais. CPU, memória, disco e banda. É o que determina quantos visitantes simultâneos o site aguenta antes de ficar lento.
2. Controle. Que versões de linguagem você escolhe, que serviços pode instalar, se você tem acesso de administrador ao sistema.
3. Responsabilidade. Quem atualiza o sistema operacional, quem configura o firewall, quem renova o certificado, quem acorda de madrugada quando cai.
4. Isolamento. O quanto o comportamento de outros clientes afeta o seu site.

Toda a diferença entre compartilhada, VPS e cloud está em como esses quatro itens são distribuídos. Mais controle sempre vem acompanhado de mais responsabilidade. Não existe plano que dê poder total e cuidado total pelo mesmo preço.

Um ponto que quase ninguém verifica antes de assinar: em cujo nome está a conta. Se a hospedagem, o domínio e o repositório estão todos na conta de terceiros, você tem um problema de propriedade, não de infraestrutura, assunto que vale ler em de quem é o seu site.

Compartilhada: quando basta e quando começa a doer

Na hospedagem compartilhada, dezenas ou centenas de sites dividem o mesmo servidor físico. Você recebe um painel, uma pasta, um banco de dados e um limite. O provedor cuida de tudo abaixo disso.

Ela é ótima em três situações: site institucional com tráfego previsível e moderado, site estático ou quase estático, e orçamento apertado. Para uma boa parte dos sites de pequenos negócios brasileiros, compartilhada resolve o ano inteiro sem nenhum drama.

Começa a doer quando você encontra algum destes sinais:

• Lentidão sem causa aparente. Seu site está igual, mas ficou lento em horários específicos. Normalmente é "vizinho barulhento": outro cliente no mesmo servidor consumindo recursos.
• Limites que você não controla. Número máximo de processos, de conexões simultâneas ao banco, de execuções por minuto. Você bate no teto e o provedor responde com upgrade de plano.
• Versão de linguagem travada. Você precisa de uma versão de PHP ou Node que o painel não oferece.
• Falta de acesso. Sem terminal, sem instalar serviço, sem configurar cron do jeito que você precisa, sem ajustar o servidor web.
• Deploy manual. Se o único caminho é FTP, você não tem pipeline, não tem rollback fácil e depende de alguém arrastar arquivo.

Nenhum desses sinais isolado exige mudança. Dois ou três juntos, sim.

VPS: o ponto de virada

Um VPS é uma fatia virtual de um servidor físico, com recursos reservados para você e um sistema operacional inteiro sob seu comando. É a primeira vez que você tem acesso de administrador de verdade.

O que muda na prática:

• Você escolhe versões, instala o que quiser, configura o servidor web do seu jeito.
• Os recursos são seus. O vizinho barulhento deixa de ser problema.
• Deploy automatizado a partir do repositório vira trivial.
• Você consegue rodar cache, fila, worker, banco próprio, coisas que compartilhada não permite.

E o que passa a ser seu problema: atualizações de segurança do sistema, firewall, configuração de SSH, renovação de certificados, monitoramento e backup. Um VPS mal cuidado é menos seguro do que uma hospedagem compartilhada bem administrada, porque na compartilhada alguém está cuidando disso por você.

Existe o meio-termo: VPS gerenciado. Você paga mais e o provedor mantém o sistema atualizado e monitorado. Para quem não tem alguém técnico à disposição, costuma ser a opção com melhor relação entre risco e custo.

Independentemente do modelo, o mínimo de higiene é o mesmo: HTTPS bem configurado com headers de segurança, assunto detalhado em HTTPS, HSTS e headers de segurança.

Cloud e serverless: quando faz sentido

"Cloud" virou palavra de marketing e muita hospedagem compartilhada se vende como cloud. O que caracteriza cloud de verdade é a elasticidade: a capacidade de subir e descer recursos em minutos, pagando pelo que usa, com serviços gerenciados prontos para banco, arquivo, fila e distribuição de conteúdo.

Cloud faz sentido quando pelo menos uma destas coisas é verdade:

• Seu tráfego tem picos grandes e imprevisíveis, campanha, sazonalidade, lançamento.
• Você precisa de alta disponibilidade real, com redundância em mais de uma zona.
• Sua arquitetura tem várias peças que crescem em ritmos diferentes.
• Você tem alguém que sabe operar isso.

Esse último item é o que mais elimina candidatos. Cloud entrega poder e devolve complexidade: rede, permissões, faturamento por consumo. Conta de cloud mal configurada é a única que tem risco de surpresa desagradável no fim do mês.

Há um caso, porém, em que cloud é a escolha simples e barata: site estático. Se o seu site é gerado em build, HTML pronto, sem servidor renderizando a cada requisição, hospedar em uma plataforma de conteúdo estático com CDN global é rápido, resiliente e frequentemente custa quase nada. É a razão pela qual sites em React modernos são publicados com geração estática, como explicamos em por que um site em React não aparece no Google.

Comparando os três modelos

Localização do servidor e latência para o público brasileiro

A distância física entre o servidor e o visitante custa tempo. Cada requisição precisa ir e voltar, e a conexão segura ainda exige idas e vindas adicionais antes de o primeiro byte útil chegar.

Para um público majoritariamente brasileiro, um servidor no Brasil reduz de forma perceptível o tempo até o primeiro byte comparado a um servidor nos Estados Unidos ou na Europa. Não é o fator dominante de velocidade, imagem pesada e JavaScript demais pesam mais, mas é um custo fixo que aparece em toda requisição e afeta as métricas de carregamento discutidas em Core Web Vitals explicado.

Duas ressalvas úteis. Primeiro, se o seu site é estático e servido por CDN, a origem importa pouco: o conteúdo é entregue do nó mais próximo do visitante. Segundo, se o seu público é internacional, escolher o Brasil só piora a experiência de todo mundo. Decida pela audiência real, não pela sede da empresa.

Uptime, suporte e a letra miúda do contrato

Todo provedor anuncia disponibilidade alta. O que diferencia é o que está escrito abaixo do número.

• O que a garantia cobre. Costuma cobrir só indisponibilidade do servidor, não lentidão, não erro de aplicação, não janela de manutenção programada.
• Qual a compensação. Quase sempre é crédito proporcional, não devolução. Não cobre o prejuízo do dia em que o site ficou fora.
• Horário do suporte. Vinte e quatro horas por dia inclui domingo de madrugada? Em qual canal? Em português?
• Backup. Está incluso? Com que frequência? Retido por quantos dias? A restauração é cobrada à parte? Backup do provedor não substitui backup seu, como argumentamos em backup e continuidade quando o site sai do ar.
• Limites reais. "Ilimitado" sempre tem letra miúda em algum lugar: inodes, processos, uso justo.
• Saída. Você consegue exportar tudo, arquivos, banco, zona de DNS, sem depender de boa vontade? Se a resposta é não, o preço baixo é uma armadilha.

Como migrar sem tirar o site do ar

Migração dá medo porque quase todo mundo faz na ordem errada. A ordem certa é esta:

1. Reduza o TTL do DNS. Alguns dias antes, baixe o TTL dos registros para algo curto, como cinco minutos. Isso faz a troca propagar rápido quando chegar a hora.
2. Monte o ambiente novo por completo. Arquivos, banco, variáveis, certificado, cron. Tudo pronto e testado antes de apontar qualquer coisa.
3. Teste pelo IP ou por um subdomínio temporário. Navegue o site inteiro no servidor novo enquanto o antigo continua atendendo o público.
4. Congele alterações. Combine uma janela em que ninguém publica conteúdo nem recebe pedidos no formulário, para não perder dados escritos no servidor antigo depois da cópia final.
5. Sincronize os dados uma última vez e só então mude o DNS.
6. Mantenha o servidor antigo ligado por uma semana. Enquanto caches de DNS espalhados pelo mundo ainda apontarem para lá, ele vai receber visitas. Desligar cedo é a causa mais comum de "sumiu tudo" durante uma migração.
7. Verifique depois da troca: certificado válido, redirecionamentos funcionando, formulário enviando e-mail, e-mail do domínio ainda entregando, e o cadastro no Search Console sem novos erros.
8. Volte o TTL ao normal depois que tudo estabilizar.

Feito nessa ordem, a migração acontece sem que o visitante perceba. Feito na ordem inversa, apontar o DNS primeiro e configurar depois, você tem algumas horas de site quebrado e nenhum caminho fácil de volta.

Se você não sabe qual modelo o seu site precisa, ou quer migrar sem susto, fale com a ALB Seven.