Shared hosting ou VPS: qual escolher para seu site?
Shared hosting ou VPS? A diferença real é ter acesso root e quem corrige o servidor. Veja quando o shared hosting basta e os quatro sinais para migrar.
Shared hosting vs VPS: resposta curta
Shared hosting vs VPS não é uma questão de velocidade. No shared hosting, você aluga uma conta num servidor que outra pessoa configura, atualiza e partilha entre centenas de clientes. Num VPS (virtual private server), você aluga um sistema operativo completo com acesso root. Assim, instala o que quiser e também corrige os problemas que causar.
Há três diferenças principais. Ou você tem acesso root, ou não tem. A memória é atribuída a você ou é emprestada de um pool. E, quando o servidor deixa de responder à meia-noite, o fornecedor corrige o problema ou você corrige. Todas as características de uma tabela comparativa resultam desses três pontos.
Se o seu site é composto por páginas, imagens e um formulário de contacto, shared hosting é a escolha correta e custa menos. Se o seu site precisa de um programa que continue em execução quando não há visitantes, você precisa de um VPS.
O que o alojamento partilhado oferece realmente
Um único servidor Linux executa várias contas de clientes em simultâneo. Cada conta tem um diretório pessoal com uma raiz de documentos, uma base de dados e uma caixa de correio. Um único servidor Web, normalmente Apache ou LiteSpeed, serve todos os sites nesse servidor. Em vez de uma shell, utiliza um painel de controlo. Não tem acesso root. Por isso, não pode instalar pacotes, abrir portas nem iniciar serviços em segundo plano.
A maioria dos serviços de alojamento partilhado utiliza CloudLinux. Este sistema coloca cada conta no seu próprio contentor, com limites rígidos para o tempo de processador e para o número de processos que pode executar em simultâneo. Exceder o limite de processos não torna o site lento. Faz com que o servidor devolva uma página de erro com o texto 508 Resource Limit Is Reached. Essa página indica que a sua própria conta atingiu o limite. Não indica que outro cliente esteja a consumir a sua quota.
Esta troca é deliberada. Abdica do controlo e, em contrapartida, o fornecedor atualiza o kernel, atualiza o PHP, renova o certificado e mantém uma cópia de segurança noturna. Para muitos sites, esta é uma boa troca.
O que um VPS realmente fornece
Um VPS é uma máquina virtual em execução num servidor anfitrião. No KVM, o hypervisor por detrás da maioria dos planos VPS Linux, a sua instância arranca o seu próprio kernel e tem o seu próprio endereço IP, a sua própria firewall e o seu próprio sistema init. sudo funciona. apt install funciona. Um programa iniciado através do systemd continua em execução depois de terminar a sessão, reinicia depois de falhar e volta a arrancar depois de um reboot.
Esse mesmo acesso root é a razão pela qual a segurança da máquina passa a ser da sua responsabilidade. Não há outra pessoa a monitorizá-la. A variedade de serviços executados num VPS é ampla precisamente por esta razão: a máquina pode fazer tudo o que um servidor Linux consegue fazer.
Diferença 1: acesso root e o que ele permite
O acesso root é a diferença que origina todas as outras. Com ele, pode instalar qualquer pacote da distribuição, associar qualquer porta, criar uma unidade systemd, ler todos os logs da máquina e alterar as definições do kernel com sysctl. Sem ele, fica limitado à lista disponibilizada pelo painel: um seletor de versão do PHP, um conjunto fixo de extensões e um formulário para tarefas cron.
Num VPS, pode sempre consultar o próprio sistema para saber o que está a escutar:
ss -ltnpCada linha representa um socket aberto e o processo que o possui. Por isso, um serviço que falhou ao iniciar aparece como uma linha em falta. No alojamento partilhado, esta pergunta não tem resposta, porque as portas 80 e 443 pertencem ao servidor web do host e nada que escreva pode ocupar uma delas.
Diferença 2: memória atribuída e memória emprestada
O alojamento partilhado é vendido com base na ideia de que poucas contas estarão ocupadas ao mesmo tempo. A memória da máquina é um conjunto comum, e a parcela da sua conta é um limite, não uma reserva. Quando essa parcela se esgota, os processos PHP são terminados e os visitantes recebem um erro 500 ou 508.
Num VPS, a memória incluída no seu plano pertence à sua instância. free -m apresenta essa informação, e nenhum processo fora da sua máquina virtual pode retirá-la.
O tempo de processador é a exceção. A maioria dos planos VPS partilha os núcleos físicos entre os diferentes clientes, e pode medir isso diretamente:
vmstat 1 5A coluna st mostra o steal time: a percentagem de tempo durante a qual o seu processador virtual estava pronto para executar, mas o núcleo físico foi atribuído a outro cliente. Um valor estável de alguns por cento é normal. Um valor de dois dígitos mantido ao longo do tempo significa que o host está sobrecarregado, e é um dado que pode incluir num pedido de suporte. No alojamento partilhado não existe uma leitura equivalente, porque todas as ferramentas que a apresentariam precisam de root. O armazenamento funciona da mesma forma. Por isso, o tipo de disco usado por um plano VPS é importante e vale a pena medir pessoalmente um VPS novo durante a primeira semana, em vez de confiar na página comercial.
Diferença 3: quem é responsável quando algo falha
Na hospedagem partilhada, o fornecedor é responsável pelo sistema operativo, pelo servidor Web, pela compilação do PHP, pelos certificados e pelo backup noturno. Quando a máquina deixa de responder, abre um ticket e alguém já está a trabalhar no problema. O custo dessa comodidade é o outro lado da mesma regra: não pode pedir a instalação de algo que o fornecedor não suporta.
Num VPS não gerido, o fornecedor é responsável pelo hypervisor, pela rede e pela alimentação elétrica. Tudo a partir do kernel é da sua responsabilidade. As atualizações de segurança, a firewall, os backups, a renovação dos certificados e a monitorização ficam a seu cargo, e o suporte não iniciará sessão para depurar a configuração do servidor Web. Planeie isso desde o primeiro dia: os primeiros dez minutos num VPS novo, depois uma firewall que compreenda, atualizações de segurança automáticas e backups que tenha restaurado pelo menos uma vez.
Quando o shared hosting é a escolha certa
Um site institucional é o caso mais claro: algumas páginas, imagens, um formulário de contacto, talvez WordPress com um plugin de cache e alguns milhares de visitas por dia. Não há tarefas em segundo plano. Não há nenhum runtime invulgar. Nada precisa de permanecer na memória entre pedidos. O shared hosting serve bem esse site, custa menos do que qualquer VPS e transfere a manutenção para profissionais que fazem esse trabalho a tempo inteiro. Migrá-lo para um VPS não traz benefícios e acrescenta uma tarefa que antes não existia.
Há um segundo caso que recebe menos atenção. Se ninguém da sua equipa quiser ler um ficheiro de log ou executar apt upgrade, o shared hosting é a opção mais segura. Um VPS sem patches e com uma porta de base de dados aberta é um resultado pior do que uma conta de shared hosting mantida atualizada por um profissional. O controlo só é uma vantagem quando alguém o utiliza.
Sinal 1: precisa de um programa que continue em execução
Um daemon é um programa que permanece na memória e aguarda trabalho: uma API, um chatbot, um worker de fila ou um servidor de jogos. O alojamento partilhado executa o seu código apenas quando chega um pedido. Além disso, qualquer processo que deixe em execução numa sessão SSH (secure shell) é terminado, porque um processo de longa duração conta para o limite de processos da conta.
Num VPS, o mesmo programa torna-se uma unidade do systemd:
sudo systemctl enable --now myapp
systemctl status myappsystemctl status deve apresentar Active: active (running) com um ID de processo. Se apresentar Active: failed (Result: exit-code), o motivo está em journalctl -u myapp -n 50, que mostra a saída do próprio programa no momento em que parou. Restart=always no ficheiro da unidade volta a iniciá-lo depois de uma falha, e enable volta a iniciá-lo depois de um reboot. Escrever serviços e timers do systemd é a primeira competência de VPS que vale a pena aprender corretamente.
Sinal 2: precisa de um runtime que o painel não disponibiliza
O painel apresenta uma lista. Se a sua aplicação precisar de uma versão da linguagem que não esteja nessa lista, de uma biblioteca que tenha de ser compilada, de ffmpeg, de um navegador headless ou de uma base de dados que não seja MySQL, o alojamento partilhado não terá onde instalar esses componentes. A instalação de software requer root, e a conta não tem compilador nem cabeçalhos de desenvolvimento. Por isso, a compilação falha antes de produzir qualquer resultado.
Num VPS, instale o componente com apt install ou execute-o num contentor para manter o host limpo. Docker Compose num VPS é a opção habitual quando a aplicação passa a ter mais do que um componente.
Sinal 3: a tarefa cron tem de ser executada no horário previsto
Os alojamentos partilhados aceitam tarefas cron através de um formulário e definem um intervalo mínimo, normalmente de cinco ou quinze minutos. Uma tarefa que ultrapasse o limite de CPU da conta é terminada a meio da execução e falha silenciosamente, porque nada escreve num log que possa consultar.
Num VPS, crontab -e aceita qualquer agendamento que defina, e um temporizador systemd é ainda melhor:
systemctl list-timers
journalctl -u cron -n 20list-timers mostra a próxima execução e o último resultado de cada temporizador, e o log do cron mostra cada comando quando é executado. Quando uma tarefa não é executada, pode determinar se nunca foi iniciada ou se foi iniciada e falhou. Essa distinção constitui a maior parte da depuração de uma tarefa agendada.
Sinal 4: os seus vizinhos estão a aumentar o tempo de resposta
O sintoma é específico. A mesma página, sem qualquer alteração no código, responde rapidamente à noite e lentamente às sete da tarde. Faça a medição a partir da sua própria máquina antes de culpar alguém:
for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; donetime_starttransfer é o tempo até ao primeiro byte da resposta, em segundos. Se os vinte valores estiverem próximos, o servidor não é o problema e a correção está no seu código ou nas consultas à base de dados. Se forem consistentes às 3am e variarem várias centenas de milissegundos nas horas de maior utilização, está a partilhar uma máquina ocupada com contas que não consegue ver. Esse é o único fator que não pode corrigir com código melhor, porque a causa está do outro lado do limite da conta.
O que a mudança realmente custa
Estes são preços anunciados típicos em agosto de 2026 para o plano mais pequeno de cada categoria. Use-os como referência, não como uma cotação, e confirme o preço atual antes de comprar.
The data behind this chart
[
{
"plan": "Shared hosting",
"first_term_usd": 3,
"renewal_usd": 12
},
{
"plan": "VPS, 1 vCPU 1 GB",
"first_term_usd": 5,
"renewal_usd": 6
},
{
"plan": "VPS, 2 vCPU 4 GB",
"first_term_usd": 12,
"renewal_usd": 15
},
{
"plan": "Managed VPS, 2 vCPU 4 GB",
"first_term_usd": 25,
"renewal_usd": 30
}
]A diferença inicial vai de 3 a 5 dólares americanos por mês, mas esse não é o valor que determina a decisão. O alojamento partilhado anuncia uma tarifa inicial que normalmente exige o pagamento antecipado de um a três anos e é renovada por cerca de 12 dólares. Compare os preços de renovação entre si e o cenário muda: 12 dólares pela conta de alojamento partilhado contra 6 dólares por um VPS de entrada.
Tenha cuidado com essa comparação, porque as dimensões não são iguais. Um VPS com 1 vCPU e 1 GB executa o servidor web e a base de dados na mesma máquina pequena, o que é insuficiente para WordPress quando chega tráfego real. A comparação equivalente mais justa com um plano partilhado renovado é a opção com 2 vCPU e 4 GB, por cerca de 15 dólares. Assim, o custo adicional real é de alguns dólares por mês, não um múltiplo.
O custo maior nunca aparece na fatura. Um VPS acrescenta uma hora de configuração, alguns minutos por mês para atualizações e a noite que passará a resolver o problema quando algo falhar pela primeira vez. Calcule esse tempo com o seu próprio valor por hora e a diferença diminui rapidamente. O custo de um VPS na prática detalha melhor os diferentes tamanhos.
Mover um site de alojamento partilhado sem perder tráfego
- Um dia antes, reduza o TTL (time to live) do DNS (domain name system) do domínio para 300 segundos. Assim, a alteração aplica-se em minutos, e não em horas.
- Prepare o novo servidor e faça o site funcionar através do respetivo endereço IP antes de alterar o DNS.
- Copie os ficheiros. Depois, faça um dump da base de dados e restaure-o no novo servidor.
- Teste através do ficheiro hosts do seu portátil. Esse ficheiro aponta o domínio para o novo IP apenas no seu computador.
- Emita o certificado TLS (transport layer security) no novo servidor, altere o registo A e mantenha a conta de alojamento partilhado ativa durante uma semana.
dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sqldig apresenta o TTL na segunda coluna da resposta. Assim, pode confirmar que o valor reduzido está ativo antes de alterar qualquer coisa. --single-transaction cria um snapshot consistente sem bloquear as tabelas. Isto é importante se o site antigo continuar a receber encomendas enquanto trabalha. No novo servidor, configure os certificados no mesmo dia: Let's Encrypt no Ubuntu com nginx demora alguns minutos quando o registo DNS aponta para o servidor.
Recursos sem a responsabilidade
Se os quatro sinais descrevem o seu site, mas não quer tratar da manutenção, a opção intermédia é um VPS gerido. Mantém a memória atribuída e a capacidade ao nível de root, enquanto o fornecedor trata das atualizações, da monitorização e, normalmente, de um painel. O gráfico acima estima esse custo em cerca de 30 dólares, contra 15 para um VPS não gerido do mesmo tamanho. A diferença paga a atenção de outra pessoa quando o servidor deixa de responder durante a noite.
A decisão entre VPS gerido e não gerido é a próxima leitura indicada se esta situação lhe for familiar. Se já gere um VPS com muita carga e o tempo de CPU roubado continuar elevado nas horas de pico, o passo seguinte é um servidor dedicado sem vizinhos.
FAQ
Um VPS é mais rápido do que o alojamento partilhado?
Não automaticamente. Um servidor partilhado com pouca carga pode ser mais rápido do que um VPS com 1 vCPU ao servir uma única página WordPress. O que um VPS oferece é consistência: a memória incluída no seu plano é sua, por isso o tempo de resposta depende do seu código e não da conta mais ocupada da máquina. Se as páginas forem lentas às 3am e também às 7pm, a causa está no código ou nas consultas à base de dados, e mover o mesmo código para um VPS leva o problema consigo.
Posso executar uma aplicação Node.js ou Python num alojamento partilhado?
Às vezes, mas apenas dentro de limites restritos. Alguns painéis iniciam uma aplicação através do Passenger, que é executada quando chega um pedido. Não pode associar a aplicação à sua própria porta, porque o servidor Web do fornecedor controla as portas 80 e 443. Também não pode manter um worker em memória entre pedidos, porque o limite de processos da conta termina qualquer processo de longa duração. Um bot, um worker de fila ou um servidor websocket precisa de um VPS.
Preciso de saber Linux para gerir um VPS?
Para um VPS não gerido, sim. Precisa de chaves SSH, uma firewall, atualizações, backups e do hábito de consultar os logs. Reserve uma hora para a configuração inicial e alguns minutos por mês depois disso. Se não quiser assumir esse trabalho, um plano gerido mantém os recursos atribuídos e transfere a manutenção para o fornecedor. Essa é a diferença abordada em alojamento VPS gerido e não gerido.
O meu site ficará indisponível enquanto o transfiro do alojamento partilhado para um VPS?
Não, se reduzir primeiro o TTL do DNS e mantiver as duas contas ativas. Defina o TTL para 300 segundos com um dia de antecedência, copie os ficheiros e a base de dados, teste o novo servidor através do ficheiro hosts do seu portátil e altere depois o registo A. Durante alguns minutos, alguns visitantes chegarão ao servidor antigo e outros ao novo, por isso mantenha a conta de alojamento partilhado ativa durante uma semana. Coloque o site em modo só de leitura durante o dump final da base de dados ou aceite perder os dados gravados nesse intervalo.