Shared hosting ou VPS: qual escolher para seu site?

Shared hosting vs VPS: resposta curta

Shared hosting vs VPS não é uma questão de velocidade. No shared hosting, você aluga uma conta numa máquina que outra pessoa configura, atualiza e compartilha entre clientes. Num VPS (virtual private server) não gerido, você aluga um sistema operativo completo com acesso root. Assim, instala o que quiser e também corrige o que quebrar.

Há três diferenças principais. Você tem acesso root ou não tem. A memória atribuída e as garantias dependem do plano. E, quando o servidor deixa de responder à meia-noite, ou o fornecedor corrige o problema ou você corrige. Tudo o que aparece numa tabela de funcionalidades resulta desses três pontos.

Se o seu site é composto por páginas, imagens e um formulário de contacto, o shared hosting é a opção correta para muitos sites. Se o seu site precisa de um programa que continue em execução quando ninguém o está a visitar, confirme se o seu fornecedor de shared hosting suporta serviços persistentes antes de escolher um VPS.

O que o alojamento partilhado oferece na prática

Um único servidor Linux executa muitas contas de clientes ao mesmo tempo. 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 alojados no servidor. Tem acesso a um painel de controlo e alguns fornecedores também disponibilizam uma shell. Não tem acesso a root, mas alguns fornecedores permitem instalar software no diretório pessoal, utilizar portas autorizadas e executar serviços em segundo plano.

Muitos fornecedores de alojamento partilhado utilizam CloudLinux, que coloca cada conta no seu próprio contentor leve, com limites para o tempo de processador, a memória, a E/S de disco, o número de processos e o número de processos de entrada. Cada limite manifesta-se de forma diferente. Atingir o limite de processador ou de E/S torna o site mais lento; não o interrompe. Atingir o limite de memória ou de processos normalmente provoca erros 500 e 503. Com Apache, a página de erro intitulada 508 Resource Limit Reached resulta do limite de processos de entrada; o LiteSpeed gere os processos de entrada de forma diferente. Em todos os casos, é a sua própria conta que atingiu o limite, não um vizinho a consumir a sua quota.

A troca é deliberada. Abdica de controlo e, em contrapartida, o fornecedor aplica correções ao kernel e mantém o software suportado; a renovação dos certificados e os calendários de cópias de segurança dependem do plano. Para muitos sites, essa é uma troca vantajosa.

O que um VPS realmente oferece

Um VPS é uma máquina virtual executada num servidor anfitrião. Com KVM, 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. Num VPS Linux não gerido com acesso root, sudo funciona. Numa instalação Debian ou Ubuntu, apt install funciona. Um programa iniciado através do systemd continua em execução depois de terminar a sessão e, com a configuração adequada de reinício e arranque, é reiniciado depois de uma falha 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. Ninguém a monitoriza por si. A variedade de coisas que as pessoas executam num VPS é grande precisamente por esta razão: a máquina faz tudo o que um servidor Linux consegue fazer.

Diferença 1: acesso root e o que ele permite

root dá-lhe controlo sobre o sistema operativo. Com root, pode instalar qualquer pacote da distribuição, associar qualquer porta, escrever uma unidade systemd, ler todos os logs da máquina e alterar as definições do kernel com sysctl. Sem root, o painel nem sempre define o limite: a alwaysdata permite instalar extensões PHP adicionais com ad_install_pecl.

Num VPS, pode sempre pedir à máquina que indique o que está a escutar:

ss -ltnp

Cada linha do socket mostra um listener TCP. Os detalhes do processo dependem das suas permissões. Por isso, se um serviço que deveria escutar em TCP não iniciar, ele aparece como uma linha em falta. Num alojamento partilhado, o acesso às informações dos sockets e a permissão para executar os seus próprios listeners dependem do fornecedor, embora o anfitrião controle as portas 80 e 443.

Diferença 2: memória atribuída versus memória emprestada

O alojamento partilhado é vendido com base na suposição de que poucas contas estarão ocupadas ao mesmo tempo. A memória da máquina é um conjunto partilhado, e a parte atribuída à sua conta é um limite, não uma reserva. No CloudLinux, atingir o limite de memória física termina os processos, e os visitantes podem receber um erro 500 ou 503.

Num VPS, free -m apresenta a memória visível para o seu sistema convidado, não uma prova de que existe uma reserva irrevogável de memória física. Um host pode recuperar memória do sistema convidado através de ballooning; as garantias de recursos do fornecedor determinam se isso é permitido no seu plano.

O tempo de processador é outro recurso partilhado nos planos de VPS com CPU partilhada, e pode medir o steal time diretamente:

vmstat 1 5

A coluna st indica o steal time: a percentagem de tempo em que o processador virtual estava pronto para executar, enquanto o núcleo físico era atribuído a outro sistema convidado. Não existe uma percentagem normal ou um limiar universal que prove uma sobrealocação; um steal time persistente é um valor que pode incluir num pedido de suporte. vmstat precisa de acesso aos ficheiros /proc relevantes, mas não precisa de root para as leituras normais, e um host partilhado pode restringir essa visibilidade. O armazenamento também é um recurso que deve verificar. Por isso, o tipo de disco usado por trás de um plano VPS é importante, assim como medir um VPS novo por sua conta na primeira semana, em vez de confiar na página de vendas.

Diferença 3: quem é responsável quando algo falha

No alojamento partilhado, o fornecedor gere o sistema operativo, o servidor web e as versões de PHP suportadas; a cobertura de certificados e cópias de segurança depende do plano. Quando a máquina deixa de responder, abre um pedido de suporte; o tempo de resposta depende das condições de suporte do fornecedor. O custo dessa abordagem é o outro lado da mesma regra: o software fora do ambiente suportado tem de ser compatível com as políticas de instalação e de serviço do fornecedor.

Num VPS não gerido, o fornecedor é responsável pelo hipervisor, pela rede e pela alimentação elétrica. Tudo a partir do kernel é da sua responsabilidade. As atualizações de segurança, a firewall, as cópias de segurança, a renovação de certificados e a monitorização ficam a seu cargo, e o suporte não iniciará sessão para depurar a configuração do seu 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 cópias de segurança 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 tráfego dentro dos limites de recursos do plano. Não há tarefas em segundo plano. Não há um runtime incomum. Nada precisa de permanecer em memória entre pedidos. O shared hosting atende bem esse site e deixa a manutenção do servidor a cargo de profissionais que fazem esse trabalho a tempo inteiro; compare os preços, porque ele não custa menos do que todos os VPS. 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 escolha mais segura. Um VPS sem patches, 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: você 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. As regras da hospedagem compartilhada variam: a DreamHost proíbe processos persistentes nos planos compartilhados, enquanto a alwaysdata oferece serviços personalizados supervisionados nos planos pagos.

Em um VPS, o mesmo programa se torna uma unidade do systemd:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status deve exibir Active: active (running) com um ID de processo. Se exibir Active: failed (Result: exit-code), o motivo estará em journalctl -u myapp -n 50, que mostra a própria saída do programa no momento em que ele parou. Restart=always no arquivo da unidade faz o programa voltar após uma falha, e enable faz isso após um reboot. Escrever serviços e timers do systemd é a primeira habilidade de VPS que vale a pena aprender corretamente.

Sinal 2: precisa de um runtime que o painel não oferece

O painel fornece uma lista. Se a 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 browser headless ou de uma base de dados que o painel não ofereça (o cPanel inclui MySQL e, quando o fornecedor o ativa, PostgreSQL), consulte as regras de instalação do fornecedor. Instalar software no seu diretório pessoal não exige root em todos os casos: a DreamHost documenta a compilação de zlib e a instalação de uma versão personalizada do Python em servidores partilhados.

Num VPS, instale-o com apt install ou execute-o num contentor para manter o sistema anfitrião limpo. Docker Compose num VPS é o caminho habitual quando a aplicação tem mais do que um componente.

Sinal 3: o seu cron job tem de ser executado a tempo

Os alojamentos partilhados aceitam cron jobs através de um formulário, e o fornecedor pode definir um intervalo mínimo próprio. No CloudLinux, um job que atinge o limite de CPU da conta é colocado em execução mais lenta em vez de ser terminado. Por isso, um job demorado ainda pode estar em execução quando chega a hora do seguinte. Se a conta já tiver atingido o limite de processos, o job não consegue iniciar novos processos. Pode consultar parte destas informações: a definição Cron Email do cPanel envia por email a saída de cada job e, nos alojamentos CloudLinux que disponibilizam essa opção, a página Resource Usage do painel indica o limite atingido pela conta e contabiliza as falhas. O acesso aos logs do sistema e a autorização para aumentar os limites continuam a depender do fornecedor, mas alguns disponibilizam logs das tarefas com as horas de início e de fim.

Num VPS, crontab -e aceita os agendamentos suportados pela implementação de cron instalada, mas um temporizador systemd é uma opção ainda melhor:

systemctl list-timers
journalctl -u cron -n 20

list-timers apresenta as próximas e as últimas horas de acionamento dos temporizadores atualmente carregados na memória, não os resultados da execução dos respetivos serviços. O journal do cron depende do serviço cron instalado e da configuração de logging. Quando um job não é executado, consulte o estado e os logs do respetivo serviço para determinar se nunca foi iniciado ou se foi iniciado e falhou. Esta distinção corresponde à maior parte do diagnóstico 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 noite. Meça 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; done

time_starttransfer é o tempo até ao primeiro byte da resposta, em segundos. Se os vinte valores estiverem próximos, isso indica um tempo consistente, mas não mostra se a causa está no servidor, no código ou na base de dados. Se forem estáveis às 3am e variarem várias centenas de milissegundos nas horas de pico, compare a utilização de recursos da conta, o volume de pedidos e os logs do servidor antes de culpar contas vizinhas. Estes tempos incluem a configuração da ligação e o processamento no servidor, pelo que não determinam a causa por si só.

O custo real da migração

Estes são exemplos anunciados e verificados em 4 de novembro de 2026, não médias de toda a categoria nem os planos mais baratos disponíveis. Os exemplos de alojamento partilhado, VPS de 4 GB e serviço gerido são, respetivamente, o Web Hosting Launch, o Stack 4 e o Managed VPS Business da DreamHost, com faturação anual; o VPS de 1 GiB é o Basic Droplet normal da DigitalOcean, no limite mensal. Confirme o preço atual antes de comprar.

[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

A diferença anunciada vai de 2.89 a 6 dólares americanos por mês, mas esse não é o valor que decide a escolha. O exemplo de alojamento partilhado exige o pagamento de um ano antecipadamente e renova por 10.99 dólares por mês. Compare os preços de renovação, e o cenário muda: 10.99 dólares pela conta partilhada contra 6 dólares por um VPS de entrada. Os dois valores da DigitalOcean são iguais porque este exemplo não tem desconto introdutório.

Tenha cuidado com essa comparação, porque os recursos 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 é limitado para o WordPress quando chega tráfego real. O exemplo com 2 vCPU e 4 GB renova por 11.99 dólares por mês, mas os limites de uma conta partilhada e a capacidade de um VPS não são diretamente comparáveis. Nestes exemplos, o custo de renovação adicional em relação ao alojamento partilhado é de um dólar por mês.

O maior custo nunca aparece na fatura. Um VPS acrescenta uma hora de configuração, alguns minutos por mês para atualizações e a noite que gastará na primeira vez que algo falhar. Atribua a esse tempo o seu próprio valor por hora e a diferença desaparece rapidamente. Quanto custa um VPS na prática analisa os diferentes tamanhos com mais detalhe.

Mover um site do alojamento partilhado sem perder tráfego

1. Um dia antes, reduza o TTL (time to live) do DNS (domain name system) do domínio para 300 segundos e aguarde a expiração do TTL anterior antes de mudar o registo. As caches locais podem continuar a demorar mais tempo a atualizar.
2. Prepare o novo servidor e faça o site funcionar no respetivo endereço IP antes de alterar o DNS.
3. Copie os ficheiros. Depois, faça um dump da base de dados e restaure-o no novo servidor.
4. Teste através do ficheiro hosts do seu portátil. Esse ficheiro aponta o domínio para o novo IP apenas na sua máquina.
5. Emita o certificado TLS (transport layer security) no novo servidor usando validação por DNS ou um certificado válido existente antes de alterar o registo A. 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.sql

dig apresenta o TTL na segunda coluna da resposta. Assim, pode confirmar que o valor reduzido está ativo antes de mudar qualquer configuração. --single-transaction cria um snapshot consistente das tabelas InnoDB sem as bloquear. As tabelas não transacionais e as alterações concorrentes ao esquema exigem cuidados adicionais. As encomendas posteriores não são incluídas nesse snapshot. No novo servidor, configure os certificados no mesmo dia: Let's Encrypt no Ubuntu com nginx demora alguns minutos depois de o registo DNS apontar 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. O fornecedor trata da manutenção acordada, mas o acesso root e a cobertura de gestão dependem do plano; o VPS gerido da DreamHost não inclui acesso root. O gráfico acima apresenta o exemplo gerido de 2 GB por 31.99 dólares, contra 11.99 no exemplo não gerido de 4 GB. Portanto, não é uma comparação entre configurações do mesmo tamanho. A diferença paga a disponibilidade de outra pessoa quando o servidor deixa de responder durante a noite.

A decisão entre um VPS gerido e um VPS não gerido é a próxima leitura indicada se essa for a sua situação. Se já gere um VPS ocupado e a perda de tempo continuar a ser elevada nas horas de pico, o passo seguinte é um servidor dedicado sem vizinhos no mesmo host.

FAQ

Um VPS é mais rápido do que um alojamento partilhado?

Não necessariamente. Um servidor partilhado pouco utilizado pode superar um VPS com 1 vCPU numa única página WordPress. A memória atribuída não elimina a contenção de CPU: num VPS com CPU partilhada, as instâncias vizinhas ainda podem afetar o tempo de resposta, e as garantias de memória dependem do fornecedor. Se as suas páginas forem lentas às 3am e também às 7pm, verifique o código, as consultas à base de dados e os limites de recursos do alojamento; a hora do dia não determina a causa.

Posso executar uma aplicação Node.js ou Python num alojamento partilhado?

Por vezes, dentro dos limites do fornecedor. Alguns painéis iniciam uma aplicação através do Passenger, que é executada quando chega um pedido. O facto de o fornecedor controlar as portas 80 e 443 não impede outros serviços autorizados a escutar: a alwaysdata permite serviços personalizados nas portas 8300 a 8499 através de IPv6 na sua Public Cloud. As regras para processos persistentes também variam entre fornecedores, por isso um bot, um worker de filas ou um servidor websocket precisa de um plano que ofereça explicitamente esse suporte, e não necessariamente de um VPS.

Preciso de saber Linux para gerir um VPS?

Num VPS não gerido, sim. Precisa de chaves SSH, uma firewall, atualizações, cópias de segurança e do hábito de ler logs. Reserve uma hora para a configuração inicial e alguns minutos por mês depois disso. Se não quiser realizar esse trabalho, um plano gerido transfere a manutenção acordada para o fornecedor. Essa é a diferença abordada em alojamento VPS gerido e não gerido.

O meu site ficará indisponível durante a migração de um alojamento partilhado para um VPS?

Reduzir o TTL do DNS e manter as duas contas ativas ajuda a evitar indisponibilidade, mas não garante uma migração sem interrupções. Defina o TTL como 300 segundos um dia antes e aguarde que o TTL anterior expire. Copie os ficheiros e a base de dados, teste o novo servidor através do ficheiro hosts do seu portátil e, em seguida, altere o registo A. Durante a alteração, alguns visitantes chegam ao servidor antigo e outros ao novo. As caches também podem demorar mais de cinco minutos a atualizar, por isso mantenha a conta partilhada ativa durante uma semana. Suspenda as escritas para o dump e o restore finais da base de dados. Mantenha o site antigo apenas para leitura ou encaminhe os pedidos para o novo servidor, para que as escritas posteriores não sejam perdidas.