Todos os produtos 
KVM ou OpenVZ: o que escolher
Em 2026 quase sempre vale escolher KVM: ele custa no máximo uns dois dólares por mês a mais que o OpenVZ, mas nele tudo funciona, do Docker ao Windows. O OpenVZ só se justifica num caso estreito, e abaixo você vê qual; no final estão os comandos para conferir o seu servidor em um minuto.
Resposta curta: escolha KVM. Nele você tem um kernel próprio, e o servidor se comporta como um computador comum: dá para instalar Docker, Windows e qualquer versão de Linux, e funcionam firewall próprio e swap. O OpenVZ é um contêiner que divide o kernel com os vizinhos da mesma máquina física. Ele é mais barato e mais leve, mas parte dos programas de sempre não roda nele, e normalmente você só descobre isso depois de pagar.
O OpenVZ só faz sentido se a tarefa é simples, roda em Linux sem Docker e a diferença de preço pesa para você. A seguir mostro quanto essa diferença é na prática e o que exatamente quebra num contêiner.
Quanto o OpenVZ é mais barato de verdade
Menos do que parece. Comparei planos com a mesma quantidade de memória no mesmo provedor: peguei o KVM mais barato e o OpenVZ mais barato e vi a diferença. Assim foi possível comparar de 15 a 29 provedores, conforme a quantidade de memória, com dados do catálogo da accsly de 27 de outubro de 2026. Os valores foram convertidos e arredondados.
Com 2 GB de memória, o KVM fica, na mediana da amostra, cerca de US$ 0,75 por mês mais caro (uns R$ 4), ou seja, cerca de 16%. Com 4 GB a diferença é maior, em torno de US$ 2,25 (uns R$ 12), ou 30%. Em um ano, isso dá de US$ 9 a US$ 27 (R$ 50 a R$ 150). E em um terço dos provedores que vendem os dois tipos, o KVM com a mesma memória custa o mesmo ou até menos, então o primeiro passo é simplesmente comparar os planos dentro do mesmo provedor.
Escolher OpenVZ, além disso, reduz muito as opções. Dos 26.640 planos do catálogo, 501 rodam em OpenVZ, ou 1,9%, vendidos por 84 dos 2.175 provedores. Em KVM estão 93,5% de todos os planos (incluí aqui os planos em que o provedor não informou a virtualização: hoje o padrão é quase sempre KVM). O resto é VMware, Hyper-V, Xen e contêineres LXC, e para você, como usuário, os três primeiros se comportam como KVM.
No fim, a economia com OpenVZ equivale mais ou menos a um cafezinho por mês, e você paga por ela com limitações. Para um trabalho que você não quer perder, eu não faria essa troca.
O que não funciona num contêiner OpenVZ
Tudo o que exige um kernel próprio. No contêiner o kernel é um só para toda a máquina física, e só o provedor pode mudar as configurações dele. Na prática, fica assim.
O Docker muitas vezes não instala ou funciona com erros. Muitos provedores dizem com todas as letras nos termos que não suportam Docker em OpenVZ. No OpenVZ 7 ele às vezes roda, se o provedor ativou os recursos necessários no contêiner, mas isso precisa ser confirmado antes de pagar. Se o projeto é baseado em Docker ou você pretende usar n8n, GitLab Runner ou Kubernetes, olhe só para KVM ou para a seleção VPS para Docker.
O Windows não roda de jeito nenhum. O contêiner usa o kernel Linux do host, então outro sistema é impossível. No catálogo não há nenhum plano OpenVZ com Windows, enquanto entre os KVM o Windows está disponível em cerca de metade. Seleção: VPS com Windows.
O kernel é antigo e não pode ser atualizado. O OpenVZ 7 usa o kernel 3.10, e o obsoleto OpenVZ 6, o 2.6.32. As distribuições recentes são feitas para kernels mais novos, então o provedor pode não ter o template da versão do Ubuntu que você precisa. Também não funciona nada que tenha chegado ao kernel depois: por exemplo, o algoritmo BBR, que acelera o envio de arquivos a longas distâncias, exige kernel 4.9 ou mais novo. Isso pesa para quem atende o Brasil a partir de um data center nos Estados Unidos ou na Europa.
Não dá para carregar módulos de kernel próprios. Isso inclui, por exemplo, o WireGuard no kernel para uma rede privada entre o escritório e o servidor. Ele pode ser substituído por uma versão que funciona sem módulo, mas só se o provedor ativou o dispositivo de rede TUN no contêiner. Como montar essa rede num KVM comum está no artigo rede corporativa numa VPS.
Não dá para adicionar swap. O comando swapon não funciona no contêiner, então, quando falta memória, o processo simplesmente é encerrado. No KVM você cria um arquivo de swap de 1–2 GB em um minuto e aguenta um pico de carga.
A memória é contada de outro jeito. Os planos OpenVZ costumam dizer algo como «1 GB garantido, até 2 GB», e o número maior só está disponível enquanto estiver livre no host. Conte com o menor.
Quando o OpenVZ é, sim, uma escolha razoável
Quando a tarefa é pequena, em Linux e sem Docker. Digamos que você precisa de um servidor para um bot simples em Python, um site estático, monitoramento de outros sites ou testes que você não se importa de perder. Nesse caso o contêiner dá conta, e em um ano você economiza uns US$ 12 (cerca de R$ 70).
Outra vantagem do contêiner é que ele quase não tem overhead. O sistema inicia em segundos, e a virtualização não consome nada da memória do plano. Em planos com 512 MB isso se nota: no KVM, o kernel e os serviços do sistema ocupam cerca de 100–150 MB disso, no contêiner menos.
Se essa opção serve para você, os planos estão na seleção VPS com OpenVZ. O LXC, um contêiner parecido, é mais raro, cerca de 0,6% dos planos, e as limitações são quase as mesmas: VPS com LXC.
E o KVM é sempre mais honesto?
Nem sempre. O KVM por si só não garante que o processador não seja dividido com uma dezena de vizinhos: nos planos baratos os núcleos continuam compartilhados. A diferença é que no KVM a venda acima da capacidade é mais fácil de enxergar: o sistema mostra o tempo que os vizinhos tiraram da sua máquina. Mostro como conferir mais abaixo. Se o processador vai ficar ocupado o tempo todo, procure planos com núcleos dedicados e, para threads únicas rápidas, VPS com processador de alta frequência.
O que escolher para a sua tarefa
Site em WordPress, Magento ou Laravel com banco de dados: KVM. O site se beneficia de swap para os picos e de uma versão recente do PHP, e não faz sentido ficar preso a um kernel antigo para economizar menos de um dólar por mês. Seleção: VPS para site.
Tudo o que roda em Docker, incluindo n8n, GitLab e Kubernetes: só KVM, aqui não há alternativa. Windows e programas para ele, como um ERP ou um sistema de gestão desktop: também só KVM ou Hyper-V.
Bot do Telegram em Python ou Node.js sem Docker, monitoramento, ambiente de testes: o OpenVZ também serve, se no mesmo provedor ele for bem mais barato. Se a diferença for menor que US$ 1,50 por mês (uns R$ 8), eu escolheria KVM mesmo assim: quando você migrar para Docker ou para uma versão nova do sistema, não vai precisar trocar de servidor.
Como os dois tipos funcionam e a tabela de diferenças estão no artigo VPS ou VDS; aqui vamos à prática.
Como descobrir em que o seu servidor roda
Os provedores nem sempre informam a virtualização no plano, e às vezes informam errado. Dá para conferir em um minuto conectando ao servidor por SSH. O comando mais simples existe em qualquer Linux moderno:
systemd-detect-virtEle mostra uma única palavra. kvm significa KVM, openvz é um contêiner OpenVZ ou Virtuozzo, lxc é um contêiner LXC, vmware e microsoft são VMware e Hyper-V, xen é Xen. Se a saída for none, você recebeu uma máquina física sem virtualização. O mesmo aparece em hostnamectl, na linha Virtualization.
Se não houver systemd ou se você quiser confirmar a resposta, há três sinais indiretos:
ls /proc/user_beancounters /proc/vz 2>/dev/null # esses arquivos só existem no OpenVZ
uname -r # versão do kernel
lscpu | grep -i hypervisor # no KVM: Hypervisor vendor: KVMSe o primeiro comando mostrar algo, você está num contêiner OpenVZ. Uma versão de kernel no formato 2.6.32-042stab… indica OpenVZ 6, e com vz7 no nome, OpenVZ 7. Há também o utilitário virt-what, instalado com apt install virt-what e executado como root; ele reconhece mais casos raros.
Como saber se os vizinhos estão apertando o seu servidor
No KVM, observe o indicador steal, ou seja, o tempo que o hipervisor deu a outras máquinas enquanto a sua pedia processador:
vmstat 1 10Você precisa da coluna st, à direita. Se ela mostra 0–2, está tudo certo. Se sob carga fica acima de 5–10 de forma constante, os vizinhos estão levando uma parte visível do processador, e o servidor vai render menos do que o plano promete. O mesmo indicador aparece no top como st, na linha %Cpu.
No OpenVZ o steal geralmente não aparece, mas existe um contador próprio de limites atingidos:
cat /proc/user_beancountersOlhe a última coluna, failcnt. Um valor diferente de zero na linha privvmpages ou physpages significa que faltou memória ao contêiner e que alguns pedidos foram recusados. Se os números crescem, o plano é pequeno para a sua tarefa, mesmo que o free mostre memória livre.
Faça essa verificação nos primeiros dias depois do pagamento, enquanto vale o reembolso. Os planos com essa opção estão nas seleções VPS com reembolso e com período de teste.